Introduction

This report is a follow up to https://www.horizon3.ai/vmware-vrealize-log-insight-vmsa-2023-0001-technical-deep-dive/.

Earlier this year we reported the technical details for VMSA-2023-0001 affecting VMware Aria Operations for Logs (formerly VMware vRealize Log Insight). In that report, we showed how an attacker could use three different CVEs to achieve remote code execution. During the course of that investigation, we noticed the fix provided by VMware was not sufficient to stop a motivated attacker. We reported this new issue to VMware and it was fixed in VMSA-2023-0021. This post will discuss the technical details of CVE-2023-34051, an authentication bypass that allows remote code execution as root.

The Original Fix

While searching for ways to exploit the vulnerabilities in VMSA-2023-0001, we examined the workaround scripts KB90635.sh and KB90635_validate.sh. These scripts modified iptables rules to block access to the incorrectly exposed Thrift ports. Later, we wanted to see how the patch worked and discovered that they used the same technique of modifying iptables rules to restrict access to the Thrift ports with a new ThriftPortManager class. However, this time the iptables rules specifically allow access from other VMware Aria Operations for Logs nodes by IP address.

Figure 1. Insufficient iptables patch for VMSA-2023-0001

Figure 2. ThriftPortManager class

Even though there were multiple separate CVEs required for an attack in VMSA-2023-0001, VMware only tried to fix the exposed Thrift ports issue. The other CVEs were left unpatched. It seems like the idea was that the other CVEs required access to the Thrift ports to work so if an attacker can’t reach the Thrift ports, the other CVEs would be unreachable as well.

Legitimate Use of Thrift Services

VMware Aria Operations for Logs has a distributed architecture that includes master and worker nodes. It appears these nodes communicate with each other using the previously vulnerable Thrift services. Since each node can exist on a different physical machine, the patch couldn’t simply block all access to the Thrift services.

Figure 3. Distributed Log Insight Deployment

The Attack

Since the patch only blocks access to Thrift services by IP and did not fix the other CVEs in VMSA-2023-0001, all an attacker needs to do is spoof their IP address and use the previous attack. For this attack to work we need:

• At least two instances of VMware vRealize Log Insight in a master / worker configuration.
• An attacker machine that uses the same source IP address as the worker node (if attacking the master).

This example can be followed using our POC at https://github.com/horizon3ai/CVE-2023-34051. In this environment we have three machines involved in the attack. All machines are on the 192.168.4.1/24 network. They are running in VMware workstation with bridged network interfaces.

• Attacker machine (Ubuntu 22.04):
  • ens33 192.168.4.60
  • ens37 192.168.4.137
• Worker machine:
  • eth0 192.168.4.137
• Master machine:
  • eth0 192.168.4.150

Notice that IP address for ens37 on the attacker machine and eth0 on the worker machine are the same.

Next, we verify the payload has the appropriate IP address and run the following commands to set the payload file permissions appropriately.

Figure 4. Update payload permissions

Next, we setup an nc listener on the attacker machine:

Figure 5. Setup a netcat listener

Finally, We run the exploit script with the following arguments on the attacker machine:

Figure 6. Trigger the exploit given our new IP address

and we receive a callback on the attacker machine’s nc listener:

Figure 7. netcat listener response

While this attack may seem simple – it does come with some challenges. It relies on the attacker having compromised an existing host in the environment and has the sufficient permissions add an additional static IP to an existing interface or add an additional interface. In our test environment, an additional interface was added and configured with a static IP address of the worker node. In your environment, you may have to configure your route metric or some other settings to get the attack script to use the correct IP address. You can check which IP address the attack script is using with Wireshark or a similar tool. Alternatively, you could modify the attack script to not run the HTTP server, and have the HTTP server run on one machine and the exploit script on another machine. This would absolve the attack machine from having two IP addresses on the 192.168.4.1/24 subnet and any routing issues.

Indicators of Compromise

The indicators of compromise for this vulnerability will be exactly the same as the issues resolved in VMSA-2023-0001. Those indicators can be found in our previous blog post for that issue.

Summary

This patch bypass would not be very difficult for an attacker to find. This attack highlights the importance of defense in depth. A defender can’t always trust that an official patch fully mitigates a vulnerability. Its important to have other mitigations in place to ensure a secure environment.