Apache Log4j Remote Code Execution Vulnerability
Overview:
Apache Log4j is a Java-based logging utility that can be configured through a configuration file or through Java code. Apache Log4j provides many features, such as reliability, extensibility, multiple configuration support including xml/json/yaml, excellent performance and more.
A JNDI Injection vulnerability has been reported in the JndiManager class of Apache Log4j. This vulnerability is due to improper handling of logged messages.
A remote, unauthenticated attacker who can control log message contents can exploit this vulnerability by sending a specially crafted parameter to the target application. Successful exploitation results in the information disclosure, or remote code execution.
CVE Reference:
This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-44228.
Common Vulnerability Scoring System (CVSS):
The overall CVSS score is 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:F/RL:O/RC:C).
Base score is 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), based on the following metrics:
- Attack vector is network.
- Attack complexity is low.
- Privileges required is none.
- Attack vector is network.
- Attack complexity is low.
- Privileges required is none.
- User interaction is none.
- Scope is changed.
- Impact of this vulnerability on data confidentiality is high.
- Impact of this vulnerability on data integrity is high.
- Impact of this vulnerability on data availability is high.
Temporal score is 9.3 (E:F/RL:O/RC:C), based on the following metrics:
- The exploit code maturity level of this vulnerability is functional.
- The remediation level of this vulnerability is official fix.
- The report confidence level of this vulnerability is confirmed.
Technical Overview:
The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that allows Java software clients to discover and look up data and resources (in the form of Java objects) via a name. JNDI support many services including Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS) and so on. Apache Log4j supports many performing lookups, including JNDI lookups.
The JNDI lookups feature on vulnerable version of Apache Log4j2.x allows it to add values at arbitrary places to Log4j configuration. Log4j is having a special syntax in the form ${lookup_name:key} (where lookup_name=one of the different lookups, key=attribute to be evaluated). When an attacker includes a string ${ in the request, the Log4j will attempt to write the same into the log data, while doing the same lookup method will be called which will find the strings after ${ and attempt to replace the strings with the actual values. For instance ${env:COMPUTERNAME} will become actual computer name(ex. TEST-PC) and ${env:AWS_ACCESS_KEY_ID} will become actual AWS SECRET KEY.
The JNDI lookups are enabled by default in the vulnerable versions of Log4j2.x and it does not sanitize the inputs, hence allowing attackers to send maliciously crafted requests to the web server or application which is using Log4j. The application will then respond with the evaluated strings.
Majority of attacks is using LDAP protocol as specified in the POCs available publicly, attackers are trying to leverage some other protocols as well, such as RMI, LDAPS, HTTP(S), DNS, IIOP, COBRA, NIS and NDS. Payloads are found in different section of HTTP request such as URI, parameters, headers such as User-Agent and Referrer and request body, as attackers trying to log the payload anyways so that it would be parsed by vulnerable Log4j.
This vulnerability becomes the worst exploited in the wild vulnerability in recent times, we are getting wide range of mutations in the payloads as attackers are trying to evade the protection or detection in place, for example, base64 encoded data. SonicWall has released multiple signatures to protect their customers.
Triggering the Problem:
- The target must be running a vulnerable version of the software.
- The attacker must have network connectivity to the vulnerable server.
Triggering Conditions:
The attacker sends a maliciously crafted parameter to the vulnerable server. The server logs the parameter using Log4j. The vulnerability is triggered when the server parses the JNDI lookup included in the log message.
SonicWall Capture Labs Threat Research is aware of vulnerability in Log4j Java-based logging library and has released the following IPS signature to detect the exploitation of threats related to CVE-2021-44228:
- IPS: 2307 Apache Log4j2 JNDI Log Messages Remote Code Execution
- IPS: 2067 Apache Log4j2 JNDI Log Messages Remote Code Execution LDAPS
- IPS: 15732 Apache Log4j2 JNDI Log Messages Remote Code Execution NIS
- IPS: 15733 Log4j2 JNDI Log Messages Remote Code Execution NDS
- IPS: 15734 Apache Log4j2 JNDI Log Messages Remote Code Execution COBRA
- IPS: 15735 Apache Log4j2 JNDI Log Messages Remote Code Execution RMI
- IPS: 15736 Apache Log4j2 JNDI Log Messages Remote Code Execution IIOP
- IPS: 15737 Apache Log4j2 JNDI Log Messages Remote Code Execution DNS 2
- IPS: 2311 Apache Log4j2 JNDI Log Messages Remote Code Execution HTTP
- IPS: 2315 Apache Log4j2 JNDI Log Messages Remote Code Execution DNS
- IPS: 2328 Apache Log4j2 JNDI Log Messages Remote Code Execution HTTPS
Please note that if your web service/server is accessible over HTTPS, then enabling of Server DPI-SSL is necessary for the above signature to detect exploits targeting this vulnerability.
SonicWall’s, (WAF) Web Application Firewall, provides protection against this threat:
- WAF: 1116 Apache Log4j2 JNDI Log Messages Remote Code Execution
Remediation Details:
The risks posed by this vulnerability can be mitigated or eliminated by:
- Enable above mentioned IPS signatures on SonicWall firewalls
- Enable Web Application Firewall signature above.
- Updating to a non-vulnerable version of the product or applying the vendor supplied patch.
- Removing the JndiLookup class from the classpath.
The vendor has released the following advisory regarding this vulnerability:
Vendor Advisory
