Log4Shell VMware vCenter Server (CVE-2022-44228)

[Roman Alex]

Log4Shell is a critical vulnerability with the highest possible CVSSv3 score of 10.0 that affects thousands of products running Apache Log4j and leaves millions of targets potentially vulnerable. CVE-2021-44228 affects log4j versions 2.0-beta9 to 2.14.1. Log4j is an incredibly popular logging library used in many different products and various Apache frameworks like Struts2, Kafka, and Druid. So far, many different commercial products have been confirmed vulnerable, including iCloud, Steam, Minecraft, AWS, VMware and many others.

The critical Log4J vulnerability was privately disclosed to the Apache Software Foundation by a security researcher who initially discovered the issue but got public when the popular video game Minecraft published an update to resolve a security issue that allowing hackers to take over the server. After further investigation by the security community, it turned out that the vulnerability resided in a common package; Log4j.

Minecraft server 18.1 uses a vulnerable version of Log4j.
The critical vulnerability resides in the JNDI lookup function of the Java log4j library, allowing an attacker to write malicious code in the form of a LDAP query to the log file. The malicious string is then interpreted as a command by the log4j library and executed. The JNDI directory service will then send the request to an attacker-controlled LDAP server. The LDAP server response can include Java classes that the target host then executes. When an attacker succeeds in injecting the LDAP query to the attacker-controlled server in the log file of a vulnerable target, this may result in remote command execution allowing the attacker to take control of the vulnerable server. Exploiting this vulnerability may also result in the exfiltration of sensitive data as this vulnerability can also be used to read server environment variables. Sensitive information that is possibly stored in environment variables, such as Git credentials or AWS keys, can result in further compromise. Any service, application or system that accepts user input logged with a vulnerable version of Log4j is susceptible to this vulnerability.

To better understand how this vulnerability is exploited, let’s have a look at the following 5 steps:

1. An attacker triggers the vulnerability by passing a malicious payload to an end point where it is logged by Log4J. This could be in a HTTP header on a login form, the chat of an application or any other endpoint that logs requests with user-supplied input.
2. The application logs the user-supplied input with Log4J.
3. The Log4j library executes the malicious payload and connects to a malicious LDAP server.
4. The malicious LDAP server responds with a remote class file that contains the malicious commands.
5. The application downloads and executes the remote Java class file.

Let’s elaborate this with a few examples seen in in the wild. An attacker could place a payload containing a malicious command in an HTTP header when requesting a login form running on a server running Log4j. The header contents are logged, interpreted by Log4j and the LDAP query is sent to the malicious LDAP server controlled by the attacker. The LDAP server responds with a remote Java class file that is then executed by the vulnerable server. Another good example seen in the wild is a vulnerable Minecraft server where payloads are typed in the game chat which are being logged by Log4j and eventually executed by the server. A proof-of-Concept exploit for the remote code execution vulnerability was published on December 9, 2021. Shortly thereafter, security researchers and threat intelligence specialists noted an increase in Log4J attack activity seeing more than 100 attacks a minute. However, it must be said that besides a number of confirmed attacks, a large part of these attacks come from security firms and researchers performing scans.