|
|
|
|
| CAPEC-6: Argument Injection |
 Description An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods. Likelihood Of Attack Typical Severity Execution Flow Explore Discovery of potential injection vectors: Using an automated tool or manual discovery, the attacker identifies services or methods with arguments that could potentially be used as injection vectors (OS, API, SQL procedures, etc.). | Techniques |
|---|
| Manually cover the application and record the possible places where arguments could be passed into external systems. | | Use a spider, for web applications, to create a list of URLs and associated inputs. |
Experiment 1. Attempt variations on argument content: Possibly using an automated tool, the attacker will perform injection variations of the arguments. | Techniques |
|---|
| Use a very large list of probe strings in order to detect if there is a positive result, and, what type of system has been targeted (if obscure). | | Use a proxy tool to record results, error messages and/or log if accessible. |
Exploit Abuse of the application: The attacker injects specific syntax into a particular argument in order to generate a specific malicious effect in the targeted application. | Techniques |
|---|
| Manually inject specific payload into targeted argument. |
Prerequisites
| Target software fails to strip all user-supplied input of any content that could cause the shell to perform unexpected actions. |
| Software must allow for unvalidated or unfiltered input to be executed on operating system shell, and, optionally, the system configuration must allow for output to be sent back to client. |
Skills Required
[Level: Medium] The attacker has to identify injection vector, identify the operating system-specific commands, and optionally collect the output. |
Resources Required
| Ability to communicate synchronously or asynchronously with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP. |
Consequences  This table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.| Scope | Impact | Likelihood |
|---|
Confidentiality Access Control Authorization | Gain Privileges | | Integrity | Modify Data | | Confidentiality | Read Data | |
Mitigations
| Design: Do not program input values directly on command shell, instead treat user input as guilty until proven innocent. Build a function that takes user input and converts it to applications specific types and values, stripping or filtering out all unauthorized commands and characters in the process. |
| Design: Limit program privileges, so if metacharacters or other methods circumvent program input validation routines and shell access is attained then it is not running under a privileged account. chroot jails create a sandbox for the application to execute in, making it more difficult for an attacker to elevate privilege even in the case that a compromise has occurred. |
| Implementation: Implement an audit log that is written to a separate host, in the event of a compromise the audit log may be able to provide evidence and details of the compromise. |
Example Instances
| A recent example instance of argument injection occurred against Java Web Start technology, which eases the client side deployment for Java programs. The JNLP files that are used to describe the properties for the program. The client side Java runtime used the arguments in the property setting to define execution parameters, but if the attacker appends commands to an otherwise legitimate property file, then these commands are sent to the client command shell. [REF-482] |
References
[REF-1] G. Hoglund and
G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02.
|
|
 Content History | Submissions |
|---|
| Submission Date | Submitter | Organization |
|---|
| 2014-06-23 (Version 2.6) | CAPEC Content Team | The MITRE Corporation | | | Modifications |
|---|
| Modification Date | Modifier | Organization |
|---|
| 2019-04-04 (Version 3.1) | CAPEC Content Team | The MITRE Corporation | | Updated Related_Weaknesses | | 2019-09-30 (Version 3.2) | CAPEC Content Team | The MITRE Corporation | | Updated Related_Attack_Patterns | | 2020-07-30 (Version 3.3) | CAPEC Content Team | The MITRE Corporation | | Updated Example_Instances | | 2021-06-24 (Version 3.5) | CAPEC Content Team | The MITRE Corporation | | Updated Related_Weaknesses |
More information is available — Please select a different filter.
|