Understanding CVE-2023–34048, A zero-day out-of-bound write in vCenter server

10 min readApr 25, 2024

by@Smartkeyss

Screenshots from the blog posts

PoC video

Summary

An out-of-bounds write vulnerability has been identified within vCenter Server’s DCERPC protocol implementation. This flaw could be exploited by a malicious actor who has network access to the server. If successfully triggered, it may lead to remote code execution. It’s imperative for users to apply available patches or updates to mitigate this risk.

Description

Introduction

On October 24, 2023, VMware reported the discovery of a zero-day vulnerability in the vCenter server. This vulnerability arises from an out-of-bound write in the vCenter server during the implementation of the DCERPC protocol which is present in VMWare vSphere and Cloud Foundation products. This vulnerability carries a CVSS score of 9.8, indicating its high-risk nature. It has the potential to result in denial of service and, in the worst-case scenario, remote code execution. VMware has acknowledged the presence of this vulnerability and has released the necessary patches to mitigate it.

Vulnerability details

CVSS 3.x Severity and Metrics

CNA: VMware

Base Score: 9.8 critical

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

- Attack Vector (AV): Network-based (N)

- Attack Complexity (AC): Low (L)

- Privileges Required (PR): None (N)

- User Interaction (UI): None (N)

- Scope (S): Unchanged (U)

- Confidentiality Impact ©: High (H)

- Integrity Impact (I): High (H)

- Availability Impact (A): High (H)

About vcentre server

vCenter Server is a centralized management software solution developed by VMware in December 5th, 2003 for managing VMware vSphere environments. It enables administrators to efficiently manage multiple ESXi hosts (a bare-metal hypervisor developed by VMware or it is a specialized operating system that allows you to run multiple virtual machines on a single physical server) and virtual machines from a single interface. Key features include resource pooling, high availability, performance monitoring, automation, security, scalability, and integration with other VMware products and third-party solutions. Overall, vCenter Server simplifies virtual infrastructure management, enhances efficiency, and ensures reliability for organizations of all sizes.

What is CVE-2023–34048

vCenter Server contains an out-of-bounds write vulnerability in the implementation of the DCERPC protocol. A malicious actor with network access to vCenter Server may trigger an out-of-bounds write potentially leading to remote code execution.

Reference: https://nvd.nist.gov/vuln/detail/CVE-2023-34048

Timeline

This vulnerability was discovered and reported on the 24th October, 2023
Exploitation started around late 2021 by a China espionage group called UNC3886.
The Vulnerability was patched in October, 2023 by VMware.

Impact

This vulnerability is found in the implementation of the DCERPC protocol. According to Censys, they observed approximately 3,451 hosts with the vCenter web service running. Out of those are 293 hosts (approximately 8.2%) had the DCERPC service running on the same public network interface on the default port (TCP/135).

According to Censys, below is the distribution of the top 10 VMWare vCenter Services by Autonomous System and Countries.

The exploitation of this vulnerability by UNC3886 was set to affect sectors like government devices, especially in the Asia-Pacific region and the United States by disrupting critical services and compromising sensitive information.

Vulnerable versions

Versions susceptible to the vulnerability encompass:

vCenter Server 4.0 (comprising updates and specific builds such as 4.0.0.10021, 4.0.0.12305)
vCenter Server 4.1 (encompassing updates 1 and 2, and specific builds like 4.1.0.12319, 4.1.0.14766, 4.1.0.17435)
vCenter Server 5.0 (encompassing beta, updates, and specific build 5.0.0.16964)
vCenter Server 5.5 (comprising updates and variants like 1, 1a, 1b, 1c, 2, 2b, 2d, 2e, 3, 3a, 3b, 3d, 3e, 3f, b, c, u1, u2, u3a, u3b)
vCenter Server 7.0 (including updates and variants like a, b, c, d, 1, 1a, 1c, 1d, 2, 2a, 2b, 2c, 2d, 3, 3a, 3c, 3d, 3e, 3f, 3g, 3h, 3i, 3j, 3k, 3l, 3m, 3n)
vCenter Server 8.0 (including updates and variants like a, b, c, 1, 1a, 1b, 1c)

Vulnerable Products

vCenter Server
vCenter Cloud Foundation

Flowchart of Attack

Reference: https://www.mandiant.com/resources/blog/chinese-vmware-exploitation-since-2021

About DCEPRC Protocol

DCERPC (Distributed Computing Environment Remote Procedure Call) is a protocol used for communication between different software processes within a distributed computing environment. It enables remote procedure calls (RPCs) to be made from one process to another across a network, allowing applications to invoke procedures or functions on remote systems as if they were local.

In simpler words, DCERPC is a way for different parts of a computer system to talk to each other over a network. It’s like a phone call between different computers, where one computer can ask another to do something for it, even if they’re far apart. However, sometimes bad actors try to take advantage of this system to do harmful things, so it’s important to make sure everything is secure.

DCE/RPC was developed under a “Request for Technology” by the Open Software Foundation, with contributions from key companies like Apollo Computer. Apollo introduced NCA (Network Computing Architecture), which later evolved into Network Computing System (NCS) and became a significant component of DCE/RPC.

Initially, the DCE source code was only accessible under a proprietary license. However, starting from January 12, 2005, it became available under an open-source license (LGPL). This change allowed a wider community to collaborate on the source code, enhancing its features and ensuring its relevance over time.

Technical Overview from SonicWall

In the analysis provided by SonicWall, the exploration of DCE/RPC begins with an overview of various packet types integral to the communication process. SonicWall identifies packet types 11 through 19 as particularly relevant in assessing the vulnerability. Each packet type serves a distinct purpose, ranging from connection establishment to error handling, as outlined in the analysis.

The provided text explains the significance of various packet types in the DCE/RPC (Distributed Computing Environment Remote Procedure Call) protocol, particularly in the context of assessing a vulnerability. It describes the purpose of packet types 11 through 19, highlighting their roles in managing RPC communication. These are:

1. RPC Bind (11): Initiates a connection between a client and a server, containing essential information about the requested interface, data representation, and optional authentication data.

2. RPC Bind Acknowledgement (12): Sent by the server to acknowledge and accept a Bind request from the client, providing confirmation or negotiation results.

3. RPC Bind NAK (Negative Acknowledgement) (13): Sent by the server to reject a Bind request, often accompanied by reasons for rejection.

4. RPC Alter Context (14): Modifies the context of an existing association between communication partners in an RPC session, commonly used for negotiating protocol data units or session parameters.

5. RPC Alter Context Response (15): Confirms, rejects, or modifies proposed context changes in response to an Alter Context request, ensuring agreement between communication partners.

6. RPC Auth3 (16): Part of the authentication process, typically occurring as the third step in establishing a secure and authenticated communication session.

7. RPC Shutdown (17): Notifies impending shutdown or termination of the association in the RPC session, allowing communication parties to handle the termination gracefully.

8. RPC Remote Alert (18): Signals alerts or notifications from a remote procedure call, indicating significant events or conditions requiring attention during RPC communication.

9. RPC Orphaned (19): Indicates that a remote procedure call has been abandoned by the client before the server completes processing, typically due to premature termination.

Further digging into the “libdcerpc.so” library, SonicWall emphasized the importance of understanding how vCenter Server manages RPC network communication. A group of functions within this library, are pivotal in regulating data flow, ensuring security, and maintaining communication integrity. SonicWall elaborates on each function’s role, emphasizing their collaborative efforts in managing network interaction effectively. These functions are:

Entry Point for Message Processing:

The function Receive_dispatch() acts as the gateway for handling incoming network messages. It oversees the reception and management of packets, directing them based on their types and the current connection state.

2. Packet Reception and Processing:

Receive_packet() is responsible for the actual receipt and processing of packets. It manages data fragments, handles buffer overflow situations, and ensures accurate data reconstruction, thereby maintaining the reliability of communication.

3. Packet Header Unpacking:

Rpc__cn_unpack_hdr() specializes in unpacking packet headers, adjusting fields based on data representation and byte order. This function ensures compatibility between different systems by correctly interpreting packet headers, crucial for proper data transmission.

4. Network Event Evaluation:

Rpc_cn_assoc_eval_network_event() processes network events related to an RPC association. It evaluates these events, with or without fragment buffers, to manage the association's state and ensure consistent network communication.

Expanding on foundational concepts, SonicWall explains the significance of pointer manipulation and structure memory layout. Pointer manipulation, both linear and vertical, is crucial for navigating memory addresses effectively. SonicWall provides detailed examples to illustrate how pointers traverse memory and manipulate data structures.

In examining the structure layout, SonicWall focuses on the “rpc_cn_fragbuf_s_t” structure, which manages fragment buffers in RPC communication. SonicWall breaks down the structure’s components, from linked list nodes to function pointers, highlighting their roles in managing data within the buffer. The analysis emphasizes alignment and memory optimization techniques employed to ensure compatibility across different systems and compilers.

POC by SonicWalls

In the analysis provided by SonicWall, the proof-of-concept (PoC) begins by delving into the intricacies of a vulnerability discovered in the code responsible for manipulating pointers and memory within a network packet structure. Specifically, the vulnerability centers around an RPC binding header, a critical component in network communication.

According to SonicWall’s analysis, the vulnerability was pinpointed to a particular segment of code, where pointers and memory addresses are manipulated to execute certain operations within the packet structure. The analysis sheds light on how variables such as “authlen” and “ppDealloc” are utilized to calculate offsets and pointers, thereby exerting control over memory management.

Furthermore, SonicWall’s investigation reveals the core of the vulnerability lies in a series of mathematical operations that result in a negative number, which, when added to the pkt_p pointer, causes unexpected memory behavior. This unexpected behavior, as outlined in the analysis, poses a significant risk to the security and integrity of the affected system.

Expanding on their findings, SonicWall meticulously explored the disassembly of the RPC communication process, disclosing a sequence of operations performed on the “rpc_cn_fragbuf_s_t" structure. Each step in the disassembly is precisely examined, from the retrieval of authentication and fragment lengths to the manipulation of pointers and byte order reversal.

In their comprehensive review, SonicWall underscores the severity of the vulnerability’s exploitation, particularly emphasizing its limitation in an attacker’s control over the byte-swapped base address. While the vulnerability may lead to a Denial of Service (DoS) condition, SonicWall stresses that it severely restricts the attacker’s ability to execute arbitrary code or manipulate server operations beyond causing disruption.

Finally, SonicWall presents a practical demonstration of the PoC’s impact, showcasing a crash or segmentation fault when an attack packet is directed toward the vulnerable version of VMWare vCenter Server 8.0U1c. This crash, SonicWall attributes to an invalid pointer stored within the rax register, resulting from the manipulation of the pointer in earlier stages of the PoC.

In this case, the code 'A' * 4069 (in python) likely represents a payload of 4069 characters filled with the letter 'A'. This payload is likely crafted to be larger than the expected buffer size or input length that the vulnerable component can handle. When this payload is sent to the vulnerable component, it can trigger an out-of-bounds write condition.

See the exploitation process here.

“The demo video above by SonicWall showcases the impact of exploiting the vulnerability using a crafted payload. In the Proof of Concept (PoC) video, a Python code 'A' * 4069 is used to generate a payload designed to trigger the vulnerability within the vCenter Server's DCERPC protocol implementation. When this payload is sent to the vulnerable version of VMWare vCenter Server 8.0U1c, it results in a crash(Denial of Service). The crash occurs specifically on a jmp rax instruction, indicating that the rax (a fundamental register in x86-64 architecture) register now contains an invalid pointer due to the effects of the Python payload." When the info registers are opened, there is an unexpected or invalid value in the rax from the out-of-bound write.

In summary, SonicWall’s analysis provides a comprehensive and meticulously researched review of the PoC, shedding light on the intricacies of the vulnerability, dissecting the disassembly of the RPC communication process, and demonstrating the practical implications of the vulnerability through a crash scenario.

Patch diffing

The vulnerability was discovered and was patched on 25th October, 2023 by VMware.

The patches that were released were;

vCenter server version 6.7U3
vCenter server version 6.5U3
vCenter server version VCF3.x
vCenter server version 8.0U1

In addition to that VMware also warned saying “VMware strongly recommend strict network perimeter access control to all management components and interfaces in vSphere and related components, such as storage and network components, as part of an overall effective security posture”.

Mitigation

Keeping vCenter Server updated with the latest patches.
Implementing network segmentation and firewall rules.
Enforcing strict access controls.
Deploying Intrusion Detection and Prevention Systems (IDPS).
Monitoring network traffic and system activities.
Providing security awareness training.
Developing an incident response plan.
Staying informed about VMware communications.
Conducting regular penetration testing and vulnerability scanning.

Conclusion

CVE-2023–34048 is critical vulnerability that was exploited by UNC3886, a China espionage group in late 2021 up till October 2023. A PoC was done by SonicWall explaining that the vulnerability is likely to cause a denial of service instead of remote code execution unless there there is a way to exploit the byte-swapped base address.

Patching the vulnerability is the only solution to mitigate this vulnerability.

It is also necessary to take the necessary mitigation and stay ahead of cyberattacks as it is revolving as years goes by.