ABSTRACT

Writing unvalidated user input to log files could allow an attacker to forge log entries or inject malicious content into the logs.

EXPLANATION

Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending upon the nature of the application, log files can be reviewed manually as required, or culled automatically by tools that search the logs for important data points or trends.

Examination of the log files can be hindered or conclusions based on log data can be wrong if an attacker is allowed to supply data to the application that is subsequently logged verbatim. An attacker might insert false entries into the log file by including log entry separator characters in their data. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker injects code or other commands into the log file and takes advantage of a vulnerability in the log processing utility [2].

Example: The following code from a CGI script accepts a string submitted by the user and attempts to convert it into the long integer value it represents. If the value fails to parse as an integer, then its value is logged with an error message indicating what happened.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
syslog(LOG_INFO,"Illegal value = %s",val);
...



If a user submits the string "twenty-one" for val, the following entry is logged:


Illegal value=twenty-one


However, if an attacker submits the string "twenty-one\n\nINFO: User logged out=evil", the following entry is logged:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Clearly, the attacker can use this same mechanism to insert arbitrary log entries. For this type of log forging attack to be effective, an attacker must first identify valid log entry formats, but this can often be accomplished by through system information leaks in the target application.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection

[2] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input

[3] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II

[5] Standards Mapping - FIPS200 - (FISMA) AU, SI

[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 117

[7] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1, Requirement 10.5.2

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1, Requirement 10.5.2

[11] A. Muffet The night the log was forged.