vCenter Lost: Chaining DCERPC Overflows for ESXi Takeover

Introduction

In the realm of enterprise virtualization, VMware vCenter Server stands as the 'crown jewels' of the infrastructure. As the centralized management platform for vSphere environments, a compromise of vCenter typically grants an attacker total dominion over every virtual machine and host in the data center. At Black Hat Asia 2025, researchers from the QI-ANXIN TianGong Team unveiled a sophisticated attack chain involving four critical vulnerabilities in vCenter’s DCERPC implementation. This post explores how these vulnerabilities—CVE-2024-37079, CVE-2024-37080, CVE-2024-38812, and CVE-2024-38813—can be chained to achieve unauthenticated remote root access and eventually control the underlying ESXi hypervisors.

Background & Context: The DCERPC Attack Surface

DCERPC (Distributed Computing Environment / Remote Procedure Call) is a foundational protocol used for communication between clients and servers in both Windows and Unix environments. In VMware vCenter, DCERPC is implemented in several key services, most notably vmdird (VMware Directory Service), which handles LDAP authentication and management on port 2012.

Because vmdird is exposed to the network and handles complex, structured data (Network Data Representation or NDR), it represents a high-value target for memory corruption research. Historically, memory corruption in network services is difficult to exploit due to modern mitigations like Address Space Layout Randomization (ASLR) and Position Independent Executables (PIE). However, logic flaws in how these services manage state and drop privileges can provide the necessary bridge to full system compromise.

Technical Deep Dive

Understanding the Vulnerabilities

The researchers identified three primary heap overflows. The most versatile of these, CVE-2024-38812, resides in the NDR array decoder. When vCenter receives a 'Call' request, it decodes array types using three parameters: max_count, offset, and actual_count. The logic defines lower and upper boundaries for the array elements. While the code checked if the total size was within limits, it failed to verify if the lower and upper indices themselves were valid. This oversight allowed for an arbitrary relative address write, a powerful primitive for any exploit developer.

In addition to the overflows, CVE-2024-38813 is a privilege escalation flaw. When vmdird starts, it attempts to bind to several ports (636, 389, 2012). If the bind fails for any port, the initialization sequence is interrupted. Crucially, the code that drops root privileges (setuid/setgid) occurs after the bind checks.

Step-by-Step Exploitation & Heap Feng Shui

Achieving Remote Code Execution (RCE) required overcoming the multi-threaded nature of vmdird. In Linux, the GLIBC allocator uses thread-specific arenas to reduce contention. This means an allocation in Thread A is physically separated from an allocation in Thread B, complicating heap grooming.

1. Heap Stabilization: The researchers used a cyclic allocation strategy. By flooding the server with a massive number of requests, they ensured that the thread arenas were predictably populated with 'fragbuf' objects, effectively cleaning up fragmented memory.

2. Bypassing ASLR (Information Leak): Without a direct leak bug, the team repurposed their relative write. They targeted a response object's buffer_length field. By extending this length, they forced the server to return more data than intended in a response, leaking adjacent heap memory. They targeted syslog objects which contain pointers to libc, successfully revealing the base address of the library.

3. Control Flow Hijack: With the address of libc known, the researchers used their arbitrary write to overwrite the __free_hook with the address of the system() function. By then sending a packet that triggers a free() on a buffer containing a malicious string (e.g., a reverse shell command), they achieved code execution.

The Two-Stage Privilege Escalation

Even with RCE, the initial shell runs with the limited privileges of the vmdird user. To gain root, the researchers utilized CVE-2024-38813 in a clever two-stage attack:

1. First Stage: Use the initial RCE to spawn a persistent child process that keeps the file descriptors for ports 636 and 389 open. Because these sockets lacked the FD_CLOEXEC flag, the child process 'holds' the ports.
2. Trigger Restart: The researchers then crash or wait for a restart of the vmdird service.
3. Second Stage: When the service restarts as root, it fails to bind to the occupied ports (636/389). The initialization stops before the setuid call is reached, but the service continues to listen on port 2012 as the root user. Re-exploiting the heap overflow now yields a root shell.

Post-Exploitation: Controlling ESXi

Once root access on vCenter is achieved, the researchers moved laterally to the ESXi hosts. vCenter manages ESXi via a high-privileged user called vpxuser. The password for this user is stored in the vCenter PostgreSQL database. While encrypted, the encryption keys are stored locally on the vCenter filesystem. By extracting the keys and querying the database, an attacker can decrypt the vpxuser credentials and gain full administrative control over the underlying hypervisors.

Mitigation & Defense

To defend against these attacks, organizations must apply the security patches provided by VMware (Broadcom) for vCenter 7.0 and 8.0.

• Detection: Monitor for unusual child processes spawning from vmdird and unexpected service restarts.
• Network Segmentation: Restrict access to port 2012 (and other management ports) to only authorized administrative subnets.
• Hardening: Ensure all service file descriptors are opened with the O_CLOEXEC flag to prevent inheritance vulnerabilities.

Conclusion

This research demonstrates that even the most hardened virtualization platforms are susceptible to complex attack chains. By combining traditional memory corruption with subtle logic flaws in privilege management, the QI-ANXIN team showed how a network-level attacker can transition from a single unauthenticated packet to full control of a data center's physical infrastructure. The takeaway is clear: security depends not just on robust boundaries, but on the flawless execution of every step in the privilege-dropping process.