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 even to perform further malicious actions. Log Injection attacks are just one of a number of Injection attacks, all of which are grouped under the ignominious first 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, and debugging. SIEM systems also 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.
Log Injection attacks differ to other injection attacks since their primary function is not to fully compromise and control the web application; this has potentially already occurred if indeed an attacker has reached the stage of tampering and forging logs. The primary aim is to cover the traces of an attack through the manipulation of the digital evidence. Thus, even if an internal team is able to recognize that they have been breached, the tainted data left behind by the attacker can potentially thwart incident forensics, thus adding a layer of protection to an attacker.
The OWASP Log Injection & Forging entry lists an anecdotal example of log forging, wherein the UNIX syslog facility is manipulated by a Computer Science student at a polytechnic to incorrectly implicate a fellow student of wrongdoing. This scenario describes a mischievous university prank; however, imagine if similar log forgery is employed to redirect the path of a criminal or even a national security investigation.
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.
The susceptibility of applications to this attack is highly dependent on the controls set in place over the writing of logs. A primary defence 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.
Verify that the application appropriately encodes user-supplied data to prevent log injection.
- OWASP ASVS: 7.3.1