A fully working exploit for the critical CVE-2021-22005 remote code-execution (RCE) vulnerability in VMware vCenter is now public and being exploited in the wild.
Released on Monday by Rapid7 security engineer William Vu (who goes by the Twitter handle wvu), this one’s different from the incomplete proof-of-concept (PoC) exploit that began making the rounds on Friday. This variant can be used to open a reverse shell on a vulnerable server, allowing remote attackers to execute arbitrary code.
The vulnerability can be exploited by unauthenticated, remote users and allows attackers to upload a file to the vCenter Server analytics service.
UPDATE: Indicators of Exploit
UPDATE: 092821 16:21 The attack team at the attack surface management firm Randori also has a working RCE exploit for CVE-2021-22005. Zero-day finder Aaron Portnoy detailed the exploit in his attack notes, which also include detection methods and indicators of exploit that defenders can use to determine whether or not they’ve been exploited by this bug.
Randori confirmed what VMware, CISA and everybody else is saying: Namely, that these vulnerabilities “are very serious issues,” and that affected organizations “should take immediate action to ensure the security of impacted devices.” As it is, Portnoy said, CISA has predicted a high likelihood that foreign actors will move quickly to exploit the vulnerability.
Portnoy also reiterated what VMware has already stressed: To wit, users should just assume that they’re already infected. “Organizations that have or had affected vCenter versions exposed to the Internet, since the vulnerability was made public on September 21, should assume that an adversary may have gained access to their network and review historical logs for anomalous behavior, such as abnormal usernames or source IP connections, and signs of compromise,” he wrote.
Below is Vu’s unredacted RCE proof-of-concept exploit against endpoints in servers that have the Customer Experience Improvement Program (CEIP) component enabled. Through CEIP, VMware collects technical information about customers’ use of its products. The CEIP is toggled on as a default setting in VMware Cloud Foundation.
Unredacted RCE PoC against VMware’s CEIP. Source: wvu.
Not that configurations matter with this vulnerability, VMware said last week. “This vulnerability can be used by anyone who can reach vCenter Server over the network to gain access, regardless of the configuration settings of vCenter Server,” said Bob Plankers, technical marketing architect at VMware, when VMware announced the vulnerability on Tuesday.
CERT/CC vulnerability analyst Will Dormann noted that a redacted PoC that Vu listed at the start of a thread that began on Friday didn’t require CEIP to be enabled. “Unclear if THAT one is being used in the wild now,” Dormann said.
According to Vu’s technical analysis, the full, unredacted PoC starts with a request to create a directory for path traversal and schedules the spawn of a reverse shell.
History of a Bad Bug
VMware announced CVE-2021-22005 a week ago, on Sept. 21, as part of a security update that included patches for 19 CVE-numbered vulnerabilities that affect the company’s vCenter Server virtualization management platform and its hybrid Cloud Foundation platform for managing VMs and orchestrating containers.
They were all serious, but CVE-2021-22005 – a critical arbitrary file upload vulnerability in the Analytics service – was assigned a CVSSv3 base score of 9.8 out of a maximum severity rating of 10. VMware urged users to declare an “emergency change” per ITIL definitions of change types and to patch as soon as possible.
Also, on Friday, the Cybersecurity and Infrastructure Security Agency (CISA) warned that VMware had confirmed that threat actors were exploiting the bug and that security researchers were reporting mass scanning for vulnerable vCenter servers and publicly available exploit code. CISA urged users with vulnerable systems to prioritize updating or to apply VMware’s workaround.
“Due to the availability of exploit code, CISA expects widespread exploitation of this vulnerability,” the advisory stated.
Know What Assets Need to Be Patched
In addition to prioritizing patching, it’s important to know about all the assets that need to be patched, according to Greg Fitzgerald, co-founder of the cybersecurity firm Sevco Security.
“We’ve found that the vast majority of enterprises have robust patch management tools that are extremely effective at what they’re designed to do: Applying patches to assets that security and IT teams know about,” he told Threatpost via email on Tuesday.
He continued: “Companies are not getting breached because their patch management tools aren’t good enough. They’re getting breached because it’s impossible to patch an asset you don’t know is there in the first place. Maintaining an accurate IT asset inventory in a dynamic environment is really hard to do. Threat actors figured that out a long time ago and work around the clock to exploit it. The first step to combating threats like this one is to establish a continuously updated, accurate inventory of all enterprise assets to serve as a foundational control for your security program.”
Rule #1 of Linux Security: No cybersecurity solution is viable if you don’t have the basics down. JOIN Threatpost and Linux security pros at Uptycs for a LIVE roundtable on the 4 Golden Rules of Linux Security. Your top takeaway will be a Linux roadmap to getting the basics right! REGISTER NOW and join the LIVE event on Sept. 29 at Noon EST. Joining Threatpost is Uptycs’ Ben Montour and Rishi Kant who will spell out Linux security best practices and take your most pressing questions in real time.
