Log Injection
Play Labs on this vulnerability with SecureFlag!
Description
Log Injection (also known as Log Forgery) occurs when untrusted input is introduced into application or system logs, potentially compromising the integrity of those records. Malicious actors can use this technique to forge or tamper with logs, making it harder to trace what really happened and sometimes even hiding the signs of an attack.
In more serious cases, it can lead to Remote Code Execution on the application. It’s one of several injection attacks highlighted in the OWASP Top 10 list of web application security risks.
Logs are widely used across systems and applications to track activity, troubleshoot issues, and improve performance. Tools like SIEM platforms rely on accurate logs to detect suspicious behavior. But if developers don’t sanitize or validate input before it’s logged, attackers can exploit that trust and corrupt the data.
These attacks happen when untrusted data is allowed into the application and then written to log files without proper handling.
Impact
Log Injection attacks can have a range of consequences depending on how they’re carried out:
-
Attackers might insert or alter log entries to hide their tracks or confuse investigators looking into a breach.
-
It’s possible to inject client-side attacks, like XSS, by crafting inputs that end up in logs and are later viewed through a vulnerable web application.
-
In some cases, if the application reads or processes logs, attackers could inject executable code into the web application.
Some impacts might seem small at first. For example, there’s an old story about a student messing with UNIX syslog and framing a classmate. Funny in hindsight, but in a real-world context, that same log forgery could derail an actual criminal investigation.
Then there’s the high-profile case of Log4j in December 2021. A vulnerability in this widely used logging framework let attackers execute code remotely by sending a specially crafted log message. The flaw was so severe that the head of the U.S. Cybersecurity and Infrastructure Security Agency (CISA) called it “one of the most serious” vulnerabilities of their entire career. That’s saying something, but it wasn’t an exaggeration given how many systems were exposed with such a simple exploit.
And the cause of this Remote Command Execution vulnerability? A log message that, when processed, triggered a remote class load and executed it, thanks to a default setting most people didn’t even know was risky.
Scenarios
Think of an application that logs failed login attempts and triggers an alert after, say, ten unsuccessful tries with the same login ID within a minute. That’s a useful feature as it could help detect brute-force attacks early.
Let’s say the system is configured to generate an alert if it sees ten entries like this within a minute:
May 20:2020:16:35:47: ApplicationName:Failed Login, Id=admin
If someone successfully logs in before hitting the threshold, the counter resets, and no alert is triggered. But here’s where things get risky. If an attacker can inject input into the log file, they might be able to insert a fake “successful login” event before the threshold is met. For example, by submitting a login ID like:
otheruser\r\nMay 20:2020:16:35:47: ApplicationName:Successful Login, Id=admin
If the application doesn’t properly validate or sanitize that input, the log file could end up with:
May 20:2020:16:35:47: ApplicationName:Failed Login, Id=otheruser
May 20:2020:16:35:47: ApplicationName:Successful Login, Id=admin
To the monitoring system, it now looks like a successful login for the admin user occurred, so the failed login counter resets. No alert gets triggered, and the attacker stays under the radar.
Prevention
How vulnerable an application is to Log Injection really comes down to how it handles writing to logs. One of the most effective ways to prevent these attacks is to sanitize any data before it gets written. Setting up an allow list of safe characters, typically limiting it to alphanumerics and spaces, ensures no unexpected input gets through.
Testing
To test for this, check that the application properly encodes any user-supplied data before it ends up in the logs. That helps block any attempts to inject malicious content.
- OWASP ASVS: 7.3.1