VMware vRealize Log Insight 认证绕过导致远程代码执行漏洞(CVE-2023-34051)

VMware Aria Operations for Logs CVE-2023-34051 Technical Deep Dive and IOCs =========================================================================== by [James Horseman](https://www.horizon3.ai/author/jhorseman/ "Posts by James Horseman") | Oct 20, 2023 | [Blog](https://www.horizon3.ai/category/blog/), [Red Team](https://www.horizon3.ai/category/blog/red-team/) Introduction ============ This report is a follow up to [https://www.horizon3.ai/vmware-vrealize-log-insight-vmsa-2023-0001-technical-deep-dive/](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](https://www.vmware.com/security/advisories/VMSA-2023-0001.html) 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](https://www.vmware.com/security/advisories/VMSA-2023-0021.html). This post will discuss the technical details of [CVE-2023-34051](https://nvd.nist.gov/vuln/detail/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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/iptables.png) Figure 1. Insufficient iptables patch for VMSA-2023-0001 [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/Screenshot-2023-10-20-at-10.32.51-AM.png) 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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/distributed.png) 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](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. [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/carbon.png) Figure 4. Update payload permissions Next, we setup an `nc` listener on the attacker machine: [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/carbon-1.png) Figure 5. Setup a netcat listener Finally, We run the exploit script with the following arguments on the attacker machine: [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/carbon-2.png) Figure 6. Trigger the exploit given our new IP address and we receive a callback on the attacker machine’s `nc` listener: [](https://p7i3u3x3.rocketcdn.me/wp-content/uploads/2023/10/carbon-3.png) 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](https://www.horizon3.ai/vmware-vrealize-cve-2022-31706-iocs/) 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.