Log injection attacks making speedy inroads in web vulnerabilities

Injections are among the oldest and most vicious attacks targeted on web applications. They can lead to stealing of data, loss of data integrity, service denial and compromise of the entire system. It usually takes place due to insufficient user input validation. 

Injection attacks involve a malicious code inserted in the network to draw all the information from the database to the attacker. They are considered a significant problem in web security and are perpetually listed on the OWASP Top 10 Web Application Vulnerabilities as the number one web application security risk. 

While SQL injection, command injection, template injection, X Path injection and cross-site scripting (XSS) attacks are common forms of injection attacks, log injection is equally risky but often overlooked. It is possible when user-controlled input is logged without sanitation, and it and can have several consequences, including remote code execution (RCE). This was the case with the recently disclosed  "log4shell" attack against log4j versions. Given the popularity of log4j for Java applications and the ability to execute arbitrary code, Apache gave this vulnerability the highest severity rating possible when it was disclosed. Many high-profile companies were affected by this vulnerability. 

So how can log injection lead to susceptibilities? 

A critical component of most applications and systems, logging allows developers and system administrators to verify whether software is working properly and identify the details when it is not. Log injection is not just a risk for the application and/or system itself. However, it is quite common for logs to be processed by other software, which could also be vulnerable to log injection attempts. Essentially, anything that writes to or reads from the log files could target log injection attacks. Even a person reading the logs can target some log injection attacks. Log forgery, denial of service, and malicious string injection are possible log injection attacks. 

Log forging

It involves constructing a payload to be logged that will create a legitimate-looking but fake log-line. This can be used to trick log analysis systems and people reading the logs manually into thinking an event happened that actually did not. 

Denial of service 

Such an attack involves a perpetrator overpowering the log file with large amounts of data. This can lead to memory exhaustion, clogging the disk space, or in the case of logs that are rolled based on size and only a subset of these file retained, log entries being prematurely deleted by the logging system. 

Malicious string injection

This can take on many forms and payloads, including remote code execution in the case of the recently disclosed log4j vulnerability. These malicious strings can exploit built-in features of either the logger or any software reading from the logs. In the issue of log4shell, an aspect of string substitution is exploited, specifically a feature that allows variables to be looked up and substituted into the log output using log4j's expression language.

While injection attacks may have several outcomes and risks, such as data leaks, Remote Code Execution (RCE) is one of the most severe vulnerabilities. It allows an attacker to execute code within an application (making it a part of it), gaining any possible access and privileges available to the application itself or even access to the host system itself through a reverse shell. This can result in data breaches, while a shell can create a starting point for an attacker to further penetrate a network and compromise systems and resources outside of what the application can access. Thus, if exploited, the log4shell attack can lead to serious implications for both data and network security.

Protection against log4shell

The best way to safeguard the data or a network against log4shell is to upgrade to standard version or greater to mitigate this specific RCE. If the standard version is being used, it should be verified that this flag hasn't been predominated to false anywhere in the application or command. This would re-enable the vulnerable functionality.

A firewall — whether network or web application — may potentially be able to block any outgoing traffic as an interim fix should upgrading require time to plan and execute. However, these measures only protect against this specific threat and not log injection in general.

Organisations should check any application using logging — even if it isn’t log4j or even Java, for possible injection attacks and proper data sanitization practices. This will mitigate possible vulnerabilities related to log injection that may exist. Sanitization may be less straightforward than just considering the application and logging system capabilities because anything reading from the logs could potentially introduce further, potentially different vulnerabilities. 

Since log injection can affect any system that reads from the logs, organisations can keep track of the techniques used for reading or processing the logs. This can help them in understanding specific risks that might be associated with logging. The security and development teams can narrow in on the specific programming, template, or expression languages the attackers might be able to control.

Tushar Richabadas

---

Tushar Richabadas is a Senior Product Marketing Manager, Applications and Cloud Security at Barracuda