Activity Feed

Indicated source as
1

@themrhagan definitely, will pass that info on to the team as well

2

@ccondon-r7 yea, its a very low likelihood of it triggering but it is still theoretically possible so I wanted to call it out. Again though, very low likelihood with the compounded effects of the race condition triggering with ASLR.

1

@themrhagan Thanks! I haven’t yet heard of (or seen) a working PoC for this, so regardless, I’m still not super concerned, but that is good context!

3

Hey, quick follow up as well – I think CVE-2024-6387 does affect 64-bit systems. The vulnerability, which is a signal handler race condition in OpenSSH, impacts both 32-bit and 64-bit architectures on glibc-based Linux distributions. While the proof-of-concept exploit was initially developed for 32-bit (x86) systems, it has been indicated that 64-bit (amd64) systems are theoretically vulnerable as well. Exploiting CVE-2024-6387 on 64-bit systems is less likely due to robust Address Space Layout Randomization (ASLR) and the increased complexity of memory allocation, which make precise timing and memory manipulation more challenging.

2

@s4mb4sh whoa, that blog is awesome.

Indicated sources as
3
Ratings
Technical Analysis

CVE-2024-37085, a vulnerability affecting domain-joined VMWare ESXi, was first published on June 25, 2024. It was reported to Broadcom by Microsoft, who published their own blog post on July 29, 2024 that stated it was being exploited in the wild to deploy ransomware. The premise of the vulnerability is that domain-joined ESXi will automatically check for a certain Active Directory group. If the group name exists, all members of that group will be granted admin privileges over the ESXi server. An attacker with the ability to create AD groups or change the name of an existing AD group can set up the group, resulting in all AD group members gaining administrator privileges over the ESXi server. Interestingly, a Broadcom KB entry documents this behavior as a feature.

Differing Messages

The original Broadcom advisory states that exploitation requires “re-creating the configured AD group (‘ESXi Admins’ by default) after it was deleted from AD.” This would indicate a non-standard configuration, since the administrators group would have to be intentionally deleted for ESXi to be vulnerable. However, Microsoft’s blog post on the vulnerability from July indicates the exact opposite.

Microsoft’s post from July 29. 2024 states that “VMware ESXi hypervisors joined to an Active Directory domain consider any member of a domain group named ‘ESX Admins’ to have full administrative access by default. This group is not a built-in group in Active Directory and does not exist by default.” Based on Microsoft’s statement, the vulnerability affects all domain-joined ESXi servers in the default configuration, since the “ESX Admins” group is not created by default.

Furthermore, as shown above, each vendor has stated a different group name targeted for exploitation. Broadcom documentation indicates that ESXi will grant admin access to any users in an Active Directory group called “ESXi Admins” (1, 2), while Microsoft makes no mention of “ESXi Admins” and instead advises to be on the lookout for “ESX Admins”.

Exploitation

To escalate to ESXi administrator privileges, an attacker must be able to create or rename an AD group. Depending on whether you’re referencing Broadcom’s information or Microsoft’s, the attacker will set an AD group name to either “ESXi Admins” or “ESX Admins”. All users in that group will then be elevated to administrator. Microsoft also states that existing administrators will remain elevated, even if an ESXi administrator modifies the name of the management group. According to Microsoft, this persistence vector is mitigated by initiating an ESXi Hypervisor Privileges refresh.

Summary

There’s a lot of mixed messaging here, so hopefully more clarity will arrive soon. As it stands, it’s likely best to assume that AD-joined ESXi is vulnerable out of the box and does not create the group by default. Defenders should also consider both the “ESX Admins” and “ESXi Admins” groups to potentially be valid avenues of exploitation until more information is shared by the vendor. In addition to remediating the vulnerability with the official Broadcom patches, defenders should check whether either of these two groups have been created and initiate an ESXi Privileges Refresh to ensure privileges are up to date.