ABSTRACT

Writing unvalidated user input to log files can 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 is 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 on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. 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 may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example: The following web application code attempts to read a value from an HTML form. The value then is logged.


...
01 LOGAREA.
05 VALHEADER PIC X(50) VALUE 'VAL: '.
05 VAL PIC X(50).
...

EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(VAL)
...
END-EXEC.

EXEC DLI
LOG
FROM(LOGAREA)
LENGTH(50)
END-EXEC.
...


If a user submits the string "FOO" for VAL, the following entry is logged:


VAL: FOO


However, if an attacker submits the string "FOO VAL: BAR", the following entry is logged:


VAL: FOO VAL: BAR


Clearly, attackers can use this same mechanism to insert arbitrary log entries.

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.