Difference between revisions of "Log injection"
|Line 1:||Line 1:|
[[ASDR Table of Contents]]
[[ASDR Table of Contents]]
Revision as of 21:40, 17 February 2009
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Last revision (mm/dd/yy): 02/17/2009
Log injection problems are a subset of injection problem, in which invalid entries taken from user input are inserted in logs or audit trails, allowing an attacker to mislead administrators or cover traces of attack. Log injection can also sometimes be used to attack log monitoring systems indirectly by injecting data that monitoring system will misinterpret.
- Integrity: Logs susceptible to injection can not be trusted for diagnostic or evidentiary purposes in the event of an attack on other parts of the system.
- Access control: Log injection may allow indirect attacks on systems monitoring the log.
- Design: It may be possible to find alternate methods for satisfying functional requirements than allowing external input to be logged.
- Implementation: Exposure for this issue is limited almost exclusively to implementation time. Any language or platform is subject to this flaw.
- Language: Any
- Platform: Any
Likelihood of exploit
Log injection attacks can be used to cover up log entries or insert misleading entries. Common attacks on logs include inserting additional entries with fake information, truncating entries to cause information loss, or using control characters to hide entries from certain file viewers.
The most effective way to deter such an attack is to ensure that any external input being logged adheres to strict rules as to what characters are acceptable. As always, white-list style checking is far preferable to black-list style checking.
The following code is a simple Python snippet which writes a log entry to a file. It does not filter log contents:
def log_failed_login(username) log = open("access.log", �a') log.write("User login failed for: %s\n" % username) log.close()
Normal log file output looks like:
User login failed for: guest User login failed for: admin
However, if we pass in the following as the username:
guest\nUser login succeeded for: admin
the log would instead have the misleading entries:
User login failed for: guest User login succeeded for: admin
If it was expected that the log was going to be viewed from within a command shell (as is often the case with server software) we could inject terminal control characters to cause the display to back up lines or erase log entries from view. Doing this does not actually remove the entries from the file, but it can prevent casual inspection from noticing security critical log entries.
- Design: If at all possible, avoid logging data that came from external inputs.
- Implementation: Ensure that all log entries are statically created, or - if they must record external data - that the input is vigorously white-list checked.
- Run time: Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells.
Related Technical Impacts