Threat Spotlight: Attempts to exploit new VMware vulnerabilities

Barracuda researchers analyzed the attacks and payloads detected by Barracuda systems between April to May and found a steady stream of attempts to exploit two recently uncovered VMware vulnerabilities: CVE-2022-22954 and CVE-2022-22960.

Here’s a closer look at one of these vulnerabilities (CVE-2022-22954), recent attack patterns, and solutions you can use to help protect against these types of attacks.

Highlighted Threat

New VMware vulnerabilities — On April 6, VMware published a security advisory that listed multiple security vulnerabilities. One of the most severe vulnerabilities in this advisory is a server-side template injection issue, CVE-2022-22954. This vulnerability has the effect of allowing an unauthenticated user with access to the web interface to execute any arbitrary shell command as the VMware user. The list of vulnerabilities also contained CVE-2022-22960, a local privilege escalation vulnerability in the affected products, which could possibly be chained by attackers.

VMware confirmed that exploitation of these vulnerabilities in the wild was already occurring. CVE-2022-22954 has a CVSS score of 9.8, and CVE-2022-22960 has a CVSS score of 7.8.

Barracuda researchers started seeing probes and exploit attempts for this vulnerability soon after the release of the advisory and the initial release of the proof of concept on GitHub. The attacks have been consistent over time, barring a few spikes, and the vast majority of them are what would be classified as probes rather than actual exploit attempts.



The vast majority of the attacks came in from the U.S. geographically, with most of them coming in from data centers and cloud providers. While the spikes are largely from these IP ranges, there are also consistent background attempts from known bad IPs in Russia. Some of these IPs perform scans for specific vulnerabilities at regular intervals, and it looks like the VMware vulnerabilities have been added to their usual rotating list of Laravel/Drupal/PHP probes.

The Details

The most common payload seen was this attempt at injecting “cat/etc/password”



Which decodes to:



The proof of concept for the vulnerability published on GitHub by sherlocksecurity was the next most popular one for probing. This string was discovered in various probes that were trying to check for exploitability:



Some of the payload strings using this script were:



(This is the default starting from the proof-of-concept script.)



There were also some attempts to use base64-encoded versions of the probes:



Which decoded to:



Among other probes, there were also many probes happening with callbacks. For example:



In terms of actual exploit attempts, the exploits were primarily from botnet operators.

One of the payloads seen was this:



Which decodes to:



The payload that was seen in this example is currently offline; however, the IP still seems to be hosting variants of the Mirai DDoS botnet malware on it currently.



Some Log4Shell exploit attempts were also seen in the data:





We also saw low levels of EnemyBot attempts in the data:

 

While this specific sample went offline quite soon, the IP used in this attack seems fairly prolific as evidenced in this GreyNoise entry:

How to protect against these types of attacks

As noted earlier, the interest levels on these vulnerabilities have stabilized. We’ll probably see low-level scanning and attempts to exploit them for some time, though. Even if scans and exploits remain steady, it’s important to take steps to protect your systems.

• Patching — The ideal time to patch is now, especially if the system is internet-facing in any way.


• Web application firewall —Place a web application firewall in front of such systems will add to defense in depth against zero-day attacks and other vulnerabilities, including Log4Shell.

E-book: The new ABCs of application security