Case VMware: Why Tracking Your External Attack Surface is Critical?
Management Interfaces Keep on Giving
Approximately a year ago, I published a write-up on the inherent danger of exposing management interfaces to the Internet and why limiting access to them on IP level is a good idea. In this write-up, I will focus on VMware virtualization products and how three distinct vulnerabilities have put the systems at risk for more than two years. I will also demonstrate how this could have been avoided, had the access to the management interfaces been properly implemented in the first place.
Up front, the best recommendation I have for mitigation is to continually assess your external attack surface and take corrective action based on your findings. Patch management simply is not enough, especially for interfaces which have not been implemented with the needs of the Internet in mind. The lack of basic cyber hygiene on the Internet means that business is booming for ransomware operators.
A Concise Timeline of Three Attack Vectors
On 2021-02-23, VMware published three vulnerabilities in their VMware ESXi and vCenter Server products affecting all the major versions ranging from 3.x to 7.0. Altogether, VMware has listed 63 vulnerable builds which suffer from these vulnerabilities. Below, we see the top ten countries with vulnerable VMware servers over the past three months.
Even if the figure above illustrates a single vulnerability, CVE-2021-21972, the same observations hold true for CVE-2021-21973 and CVE-2021-21974 as well. Why I have focused on the first is that it is directly exploitable RCE over port 443. What is interesting to note is that the trend in western countries such as France, USA or Germany is downwards, whereas for example in Russia, Iran or China it is not. Korea seems to be the only Asian country that exhibits a downward trend.
In terms of absolute numbers it is notable that Brazil has the biggest population of vulnerable servers and the biggest drop over the past three months has happened in France, most likely due to the ANSSI alert over ransomware operators actively exploiting one of the vulnerabilities (CVE-2021-21974) in Europe. Be as it may, the numbers are still significant even if globally they have dropped from 38k servers in 2023-02 to 28k servers in 2023-04.
At the time of writing, the total population of publicly exposed VMware platforms is slightly north of 69k.
CVE-2021-21972
On 2021-02-24, the MITRE corporation published a critical vulnerability in a server plugin of the vSphere Client as follows:
The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server.
The root cause for the vulnerability stemmed from two weaknesses:
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) Weakness ID: 22
- CWE-306: Missing Authentication for Critical Function
On 2021-03-01, Packet Storm Security published an exploit, which basically boils down to remote code execution via an arbitrary file upload functionality without authentication. This vulnerability actually encapsulates why patch management alone is not a sufficient security control for management interfaces over time. A directory traversal / arbitrary file upload vulnerability leading into remote code execution speaks volumes about the Internet-worthiness of this interface. You simply must firewall this stuff out of the reach of the whole Internet.
CVE-2021-21973
The second vulnerability in the batch relates to the same server side component which basically boils down to a weakness where the server does not validate that a request coming in has the intended destination, also known as SSRF:
The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure.
This weakness in turn is identified by MITRE as:
- CWE-918: Server-Side Request Forgery (SSRF)
Effectively, this vulnerability turns the vulnerable component into a proxy, which can be abused to access any resource not directly accessible to the Internet.
I haven’t seen much discussion over this vulnerability, but below I speculate that this vulnerability could be chained to bypass access controls to a vulnerable interface.
CVE-2021-21974
The last one of the published vulnerabilities, CVE-2021-21974, is a heap overflow vulnerability and needs access to the OpenSLP port on TCP/427:
OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.
On 2021-06-03, a PoC exploit was published on packet storm security. What is interesting, however, is that I have not seen anyone chaining the previous SSRF with this vulnerability to gain access to the SLP port – not at least based on a cursory review of the publicly available exploit code I read up on for this write-up.
As stated above, approximately two years later on 2023-02-03, CERT-FR published a bulletin urging the administrators to patch their servers since the flaw was being actively exploited by ransomware operators.
Some Thoughts on the Acute Need for External Attack Surface Management
I’ve often used the terms media hype cycle or the eye of Sauron to describe how information about vulnerabilities and exposures is handled by the press. The trend seems to be that there is a short buzz around the time a vulnerability is published, whereafter it is forgotten. A new buzz may emerge when exploit code for a given vulnerability is published. Nowadays, a new hype cycle is drummed up once ransomware operators pick up a venerable vulnerability and start exploiting it for their criminal purposes.
For this reason, understanding that especially management interfaces would not be subject to these calamities, if we just limited remote access to them properly. Surely, the vulnerabilities have to be patched in the same way and the system itself has to be properly configured, but so much headache could be avoided if organizations would continually explore and validate what their attack surface is and limit access to risky services such as management interfaces.
What seems to be really chronic in reporting is the fact that vulnerabilities are examined out of context. The bigger picture, which often boils down to public exposure of a management interface is not addressed at all.
Hypervisors Held for Ransom: an Update on 2023-05-11
Sentinel Labs published a write-up, where they claim to have identified 10 ransomware families exploiting VMware vulnerabilities. They did not, however, identify which specific vulnerabilities have been used in the recent attacks as the initial access vectors.
Give Us Feedback or Subscribe to Our Newsletter
If this post pushed your buttons one way or another, then please give us some feedback below. The easiest way to make sure that you will not miss a post is to subscribe to our monthly newsletter. We will not spam you with frivolous marketing messages either, nor share your contact details with nefarious marketing people. 😉