log injection attack

Threat Spotlight: Log injection attacks

Print Friendly, PDF & Email

Injection attacks are perpetually on the OWASP Top 10 Web Application Vulnerabilities. While SQL injection, command injection, and cross-site scripting (XSS) attacks are common forms of injection attacks that typically come to mind first, log injection can still present a risk and may often be overlooked.

Log injection can have a number of consequences, including remote code execution (RCE). This was the case with the recently disclosed CVE-2021-44228 a.k.a. “log4shell” attack against log4j versions prior to 2.16.0.

Highlighted Threat

Log4j log injection RCE — If an application using a vulnerable version of log4j logs a specially crafted string, the vulnerable library can be induced to execute code provided by an attacker. Given the popularity of log4j for Java applications as well as 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.

The Details

Logging is a critical component of most applications and systems because it allows developers and system administrators to verify that software is working properly and identify more specific details when it is not. Log injection is not just a risk for the application and/or system itself, however, since it is quite common for logs to be processed by other software, which could also be vulnerable to log injection attempts. Anything that writes to or reads from the log files could be a target of log injection attacks. Even a person reading the logs can be the target for some log injection attacks. Possible log injection attacks include log forgery, denial of service, and malicious string injection — which has several possible attacks in itself.

Log forging involves crafting a payload to be logged that will add in a legitimate-looking but fake log-line. This can be used to trick log analysis systems as well as people reading the logs manually (or reading from the logs through event systems) into thinking an event happened that actually did not, or to skew analytics of how often a particular event took place. Denial of service attacks involve an attacker overwhelming the log file with large amounts of data. This can lead to memory exhaustion, disk space becoming filled, 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. Both of these types of log injection attacks do not require taking advantage of any particular programming language or template engine.

Malicious string injection 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 case 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. If a template engine is used by any software displaying or processing logs, template injection may be possible using the syntax of the template engine being used. If the logs are being rendered to a web browser, in addition to template injection, it may be possible to inject code in the programming language being used by the web service, for example injecting PHP code into the logs to be executed when the logs are rendered to a user who doesn't necessarily even have to be the attacker. It may also be possible for an attack to write JavaScript to the log that will be rendered and executed when a user views the log entries through a web application, in other words a stored cross-site scripting attack.

While injection attacks may have various outcomes and risks such as data leaks, remote code execution (RCE) is one of the more severe outcomes of a vulnerability. RCE allows an attacker to execute code within an application as though it were intended to be part of the application, gaining any of the possible access and privileges available to the application itself. This could result in access to files available to the application, databases the application talks to, or even access to the host system itself through a reverse shell. File and database access 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 is able to access. Thus, the log4shell attack can have serious implications for both data and network security if exploited.

Offering too much functionality that could potentially lead to severe vulnerabilities such as log4shell might also be a topic maintainers should look at. Given that the functionality enabling this RCE was removed in 2.16.0, it seems that the log4j maintainers might have already realized this point.

How to protect against these types of attacks

The best way to protect against log4shell specifically is to upgrade to the latest version of log4j. Maintaining up-to-date software and libraries helps ensure that vulnerabilities are patched in a timely manner. Since log4j may be included in an application outside of being a direct dependency, the build system can likely be used to obtain a dependency tree to check for vulnerable version(s) of log4j as indirect dependencies. Maven and Gradle both include command-line tools to print dependency trees for a project.

A firewall — whether network or web application — may potentially be able to offer some level of protection as an interim fix should upgrading require time to plan and execute. A network firewall can be configured to block outgoing LDAP traffic that would result from exploiting this vulnerability. A web application firewall may be able to protect against the attack in the first place if it offers protection against template injection. Barracuda Web Application Firewall and WAF-as-a-Service protect against template and log injection attempts, including those related to log4shell. These measures only protect against this specific threat, however, and not log injection in general.

Considering what systems the logs might be processed by and what possible vulnerabilities might exist within them would make for a good assessment of risks logging might introduce, as well as potential remediation for future logging-related threats by development and security teams. Since log injection can affect any system that reads from the logs, keeping track of the systems that are reading or processing the logs can help with understanding specific risks that might be associated with logging. For the security and development teams, this can help identify specific aspects of logging that might require additional consideration.

Report: The state of application security in 2021

Scroll to top