CVE-2023-34048 (VMSA-2023-0023) is a VMWare vCenter vulnerability in their implementation of the DCERPC protocol, which is present in VMWare vSphere and Cloud Foundation products. There has not been much detail published about the actual vulnerability, but it has been reported that every single version of vSphere except the latest is vulnerable.
At the time of writing, there are no public exploits available, nor has there been a mass hacking campaign, but there has been a report by Mandiant stating that this vulnerability has been used in a targeted attack. They also state that an advanced espionage group from China has been utilizing this vulnerability since late 2021.
Censys Search Queries:
Censys ASM Queries:
- VMWare vCenter: host.services: (software.vendor: vmware and software.product: vcenter) or (web_entity.instances.software.vendor: vmware and web_entity.instances.software.product: center)
- VMWare vCenter with DCERPC: (host.services: (software.vendor: vmware and software.product: vcenter)) and host.services.service_name=DCERPC
“Analysis of the core dump of “vmdird” by both Mandiant and VMware Product Security showed that the process crashing is closely aligned with the exploitation of CVE-2023-34048, the out-of-bounds write vCenter vulnerability in the implementation of the DCE/RPC protocol patched in October 2023, which enables unauthenticated remote command execution on vulnerable systems.” – Mandiant
Note: “vmdird”, also known as the VMWare Directory Service, apparently directly interacts with the vulnerable DCERPC implementation in some manner. Though the details are currently unclear.
This group, codenamed UNC3886, was known to have been behind various attacks targeting VMWare ESXi in June of 2023, and it has become clear that they are now using a vulnerability that has not yet had a public proof of concept exploit released.
While Censys has insights into the hosts with VMWare vCenter running the web administration interface, the underlying issue is their implementation of DCERPC, a completely different protocol outside of HTTP, commonly found on TCP port 135.
At the time of writing, Censys has observed approximately 3,541 hosts with the vCenter web administration service running; of those, only 293 hosts (8.2%) had the DCERPC service running on the same public network interface on the default port (TCP/135).
It should be noted that just because DCERPC is running on the same host as the vCenter web interface, that does not mean that it is vulnerable to this attack. Censys does not have insights into the specific versions of the services that are running, nor do we know if the observed DCERPC implementation is the VMWare implementation (the vCenter interface may be sitting behind a proxy on a host running a different implementation of DCERPC; we have no way to differentiate these types of configurations).
On the other hand, if a host is running DCERPC publicly but does not have a vCenter web administration interface exposed to the internet, we cannot discern whether the DCERPC service interacts with an underlying VMWare system.
In the metrics above, we note that the usual suspects, like Amazon AWS and Microsoft Azure, are not even in the running. The exposures here seem isolated to telecom providers and SOHO ISPs like AT&T Internet. As alluded to previously, only a fraction of the hosts running the vCenter web interface also run a DCERPC service on TCP port 135.
In summary, if you are running a version of the VMWare vCenter server before or equal to 8.0.2 or 7.0 U3o, then the installation of vCenter must be patched. VMWare also notes in their FAQ that you are affected by this vulnerability if you are running any version of vSphere except the latest updates (6.5, 6.7, 7.0, or 8.0).
