| Attack Pattern ID | Pattern Abstraction: Standard 76 |
| Typical Severity | Very High |
| Description | Summary
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
|
| Attack Prerequisites |
Program must allow for user controlled variables to be applied directly to the filesystem
|
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | - Injection
- API Abuse
- Modification of Resources
|
| Examples-Instances | Description
An example of using path traversal to attack some set of resources on a web server is to use a standard HTTP request
http://example/../../../../../etc/passwd
From an attacker point of view, this may be sufficient to gain access to the password file on a poorly protected system. If the attacker can list directories of critical resources then read only access is not sufficient to protect the system.
|
| Attacker Skill or Knowledge Required |
Low → to identify file system entry point and execute against an overprivileged system interface
|
| Solutions and Mitigations |
Design: Enforce principle of least privilege.
Design: Ensure all input is validated, and does not contain file system commands
Design: Run server interfaces with a non-root account and/or utilize chroot jails or other configuration techniques to constrain privileges even if attacker gains some limited access to commands.
Design: For interactive user applications, consider if direct file system interface is necessary, instead consider having the application proxy communication.
Implementation: Perform testing such as pentesting and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables.
|
| Attack Motivation-Consequences | - Privilege Escalation
- Data Modification
|
| Context Description |
An attack of this type exploits a system's permissiveness in letting an end user specify filenames, paths, and other data. Many systems, especially multi user systems like servers, attempt to balance the tradeoffs between allowing the user access to rich functionality and limiting the access to the file system in some way. For web and ftp servers, it may be desirable for users to upload and manage content; in an enterprise workstation, there may be several users running programs on the same machine, so the policy may require a user to be constrained to their own working directory. Unfortunately, giving the end user direct access to the file system without proper validation of the input data, can result in unforeseen results. The user's ability to manipulate the file system, executing commands against the file system, can destroy the barrier between what the end user's privileges are designed to be, because they are executed in an unexpected locale (the file systems) where permissions may not be set correctly.
The outcome of this type of access can include:
Manipulate file metadata: alter the timestamp, filename, file permissions
Unauthorized duplication or destruction: attacker may copy, move, or delete files
System traversal: users with liberal permissions can traverse to other directories like /tmp and /etc to gain access to additional system configuration information and other sensitive information. The entry point directory is the starting point, with appending file system commands like ../ to escape out of the initial directory locale, for example:
/entrypoint directory/../targetfilename
Upload files: given too much access, the attacker can identify file system locations to upload tools, files, and other content to launch further attacks. It should be noted that even without the ability to upload, access to the file system by itself can be the only opening an attacker needs.
Systems have increasingly complex configurations, and the locations of directories, tools, and entry points by default are very similar across implementations. This allows attackers to scan many hosts to identify predictably located entry points for file system attacks.
“File system calls are very common in software applications. In many cases, user input is consumed to specify filenames and other data. WIthout proper security control this leads to a classic vulnerability whereby an attacker can pass various parameters into file system calls." [Hoglund and McGraw 04]
|
| Injection Vector |
Payload delivered through standard communication protocols and inputs.
|
| Payload |
File system commands and specifiers
|
| Activation Zone |
File system
|
| Payload Activation Impact |
File access or modification.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 23 | Relative Path Traversal | Targeted | | 22 | Path Traversal | Targeted | | 73 | External Control of File Name or Path | Targeted | | 77 | Failure to Sanitize Data into a Control Plane (aka 'Command Injection') | Targeted | | 346 | Origin Validation Error | Targeted | | 348 | Use of Less Trusted Source | Targeted | | 285 | Missing or Inconsistent Access Control | Secondary | | 264 | Permissions, Privileges, and Access Controls | Secondary | | 272 | Least Privilege Violation | Targeted | | 59 | Failure to Resolve Links Before File Access (aka 'Link Following') | Targeted | | 74 | Failure to Sanitize Data into a Different Plane (aka 'Injection') | Targeted | | 15 | External Control of System or Configuration Setting | Targeted |
|
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | Medium |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| All | All | All | All |
|
| References |
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-01-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Gunnar Peterson | Cigital, Inc | 2007-02-28 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-09 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name and Description | | Sean Barnum | Cigital, Inc | 2007-04-16 | Modified pattern content according to review and feedback |
|
