Log Injection
Play Labs on this vulnerability with SecureFlag!
Description
Log Injection (also known as Log Forgery) attacks result from untrusted input being introduced into application or system log files, compromising or convoluting the integrity of the data therein. Malicious actors deploying this technique can tamper or forge logs to mislead log audit processes, obfuscate application records to cover the traces of an attack, and in the most extreme cases, achieve Remote Code Execution on the application. Log Injection attacks are just one of many types of injection attacks that, as a group, ignominiously occupy a place on the OWASP Top 10 list of web application security risks.
Auditable, chronological lists of events and transactions are recorded by web applications, services, and the operating system itself and can be used for numerous benign purposes, such as; performance optimization, data collection, logging, and debugging. For example, SIEM systems ingest log files to identify patterns of behavior that may require flagging and alerting. Unfortunately, the benefit attached to the existence of this historical record can be nullified if developers don’t consider the risk of reading and writing application logs prior to effective sanitization and validation.
Attacks of this nature occur if untrusted data is allowed to enter the application or when data is written to such an application or its system log file.
Impact
Log Injection attacks come in different flavors, with several reasonably distinct outcomes:
-
Logs might be tampered with or added, perhaps as a means of sullying digital evidence of an attack should an investigation be performed down the track;
-
Client-side injection attacks, such as XSS attacks, could be crafted in such a way that they would be logged and viewed in the vulnerable web application;
-
If the application allows log records to be parsed, it might be possible to inject executable code into the web application.
Impacts may be relatively minor, with this anecdotal example of log forging illustrating the misadventures of a student, the UNIX syslog protocol, and the wrongful implication of a fellow pupil. However, imagine if similar log forgery is employed to redirect the path of a criminal or even a national security investigation.
Of course, log tampering is one thing, but in December 2021, a vulnerability affecting the Log4j framework was identified and disclosed to the Apache Foundation, responsible for maintaining open-source software integrated into countless entities’ core infrastructure worldwide. The head of the United States Cybersecurity and Infrastructure Security Agency (CISA) was quoted saying, “This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious”. Quite the claim indeed, although not an unreasonable one given the fact that literally hundreds of millions of applications were instantly vulnerable to such an easy-to-execute RCE.
And the cause of this Remote Command Execution vulnerability? A specially crafted log message triggering a remote class load, a message lookup, and the execution of content if a message lookup substitution option was enabled, which was the case by default.
Scenarios
Assume an application has a function to record failed login attempts and trigger alerts after a set amount of unsuccessful attempts with the same login identification are recorded; a useful function to alert analysts about possible brute-force attacks. Suppose that the configuration on the event management system is set to generate an alert if ten of the following entries appear with the same login within one minute:
May 20:2020:16:35:47: ApplicationName:Failed Login, Id=admin
If a successful login event takes place prior to reaching the alert threshold, the system resets. However, if a malicious actor is able to add input to the log file, she/he might be able to login with a forged ID purporting log entry:
otheruser\r\nMay 20:2020:16:35:47: ApplicationName:Successful Login, Id=admin
If the application fails to validate the login id of the incoming value and subsequently logs it, the log file would display two entries; the first unsuccessful, the second successful:
May 20:2020:16:35:47: ApplicationName:Failed Login, Id=otheruser
May 20:2020:16:35:47: ApplicationName:Successful Login, Id=admin
The forged record thus resets the monitor on failed login attempts for the ‘admin’ account, thereby preventing any alerts from being generated.
Prevention
The susceptibility of applications to this attack is highly dependent on the controls set in place over the writing of logs. A primary defense against Log Injection attacks is to strictly sanitize outbound log messages by implementing an allow list of characters. This may include the limitation of alphanumeric characters and spaces in all logs.
Testing
Verify that the application appropriately encodes user-supplied data to prevent log injection.
- OWASP ASVS: 7.3.1