A vulnerability chain discovered in Zoom's chat functionality can be exploited to allow zero-click remote code execution (RCE), threat hunters have revealed.
Google's Project Zero uncovered an attack path that would allow cyber adversaries to silently force a victim to connect to a man-in-the-middle (MitM) server — no user action needed. From there, attackers can intercept and modify client update requests and responses in order to send the victim a malicious update, which will automatically download and execute, thus allowing RCE.
The only capability needed to carry this off successfully is the ability to send messages to the victim over Zoom chat, Project Zero researcher Ivan Fratric noted in a posting
that was made public on Tuesday.
"With the massive popularity and broad reach of Zoom, any vulnerability that could allow a remote compromise like this is of concern," Mike Parkin, senior technical engineer at Vulcan Cyber, tells Dark Reading. "While an attack appears to require the threat actor to be on an active Zoom call with the target, the wide prevalence of the platform and the number of large group meetings means it shouldn’t be difficult for a malicious actor to find suitable victims."
XMPP "Stanza Smuggling" Bug
Zoom chat uses a messaging protocol based on XML called XMPP. Fratric explained that messages are exchanged using short snippets of XML called "stanzas" that are sent over a single stream back and forth from client to server. The initial issue is the fact that the client and server don't see eye-to-eye when interpreting whether message code is well formed, leading to parsing inconsistencies.
"The clients use gloox library for XML parsing … and Zoom's server … uses fast_xml for XML parsing, which in turn uses an XML parser called Expat," the researcher noted. "Indeed, it turns out that Expat and gloox parse XML in a different way and (at least one) exploitable inconsistency exists."
At issue is the fact that the server's Expat parser is lax when it comes to validating tag and attribute names, Fratric said. Specifically, it will forward tag names containing question marks (i.e., "<?xml ?>") to the client, even though it shouldn't. And when the client's gloox parser sees the question-mark sequence, it will reset the parser state so that anything coming after that will be considered a legitimate root node of the next stanza.
This makes it possible to escape the <message> tag safeguards, he noted, to add in whatever content the attacker would like: "The <message> tag here can, of course, be replaced with <iq> or any other tag and it will be accepted by the client as the data coming from the server." He dubbed this "stanza-smuggling."
Since attackers now have complete control over the message tag, that also means they can manipulate the "from" attribute, in order to spoof messages as if coming from another user. And, Fratric noted, they can also lead the victim's contacts to malicious websites for phishing or drive-by malware attacks. This is accomplished by altering the file-integration tag, to surreptitiously replace the URL that's opened when the user wants to share a file with another user, using Dropbox, Google Drive, SharePoint, and other cloud-based services.
Achieving Man-in-the-Middle Status
The MitM attack is accomplished by changing the <strem:error> tag. Using a specially crafted stanza, bad actors can create "a 'ClusterSwitch' task in the Zoom client, with an attacker-controlled 'web domain' as a parameter," Fratric said.
To trigger the attack, adversaries can simply type and send a message to the victim containing the magic string "iddqd" in the tag. That will cause the victim client to connect to the /clusterswitch endpoint on the attacker-provided domain, thus setting up the ability to see and modify traffic between the client and the Zoom Web server.
"From /clusterswitch endpoint, a client gets a list of domains to be used for various services," Fratric explained. "Since the attacker is already in the man-in-the-middle position, they can replace any of the domains with their own, acting as a reverse proxy and intercepting communications."
Exploiting the Client Update Process
The escalation to arbitrary code execution was a logical next step, Fratric noted, given that Zoom clients will periodically query the update endpoint from Zoom's Web server to see if there's anything new to install.
"Since the attacker is already in the MitM position, they can, of course, replace these endpoints and serve arbitrary data," according to the researcher.
Fratric ran into a snag here, though: The client downloads two files as part of the update process, and verifies their legitimacy — the "Installer.exe" file must be signed by "Zoom Video Communications, Inc." to start with; once installed, it checks the hash of the second .cab file.
However, it turns out that attackers can get around these hurdles with a downgrade attack.
"I served Installer.exe and .cab from Zoom version 4.4 (from mid-2019)," the researcher explained. "The installer for this version is still properly signed; however, it does not do any security checks on the .cab file."
In all, Fratric reported a total of six security vulnerabilities, including four Zoom-specific issues fixed in version 5.10.4 of the Zoom client:
- CVE-2022-22784 (improper XML parsing)
- CVE-2022-22786 (update package downgrade),
- CVE-2022-22787 (insufficient hostname validation),
- CVE-2022-22785 (improperly constrained session cookies)
There's unfortunately also a software supply chain issue at work: The two others (CVE-2022-25235, CVE-2022-25236) affect the Expat parser, which is open source and used in plenty of other applications, including wares from Aruba, F5, IBM, and Oracle, as well as the Red Hat Linux distro. They're patched in Expat version 2.4.5.
"Some or all parts of the chain are likely applicable to other platforms," Fratric said.
Zoom became a popular target for "Zoom-bombing" and other attacks in the wake of the work-from-home wave during the pandemic, calling into question the security of the platform and its encryption practices. The company implemented a raft of security changes to match it's heightened status, but nonetheless, bugs like these are somewhat inevitable, researchers noted.
"In 2020, we all instantly became hyper-connected to the Internet…and so did all of the systems we use," Mark Lambert, vice president of products at ArmorCode, tells Dark Reading. "Two years later, and it is clear that there is no looking back. Unfortunately, these types of vulnerabilities are inevitable given the speed that software is released to meet business goals. The only way for us to protect ourselves is to detect as soon as possible and react even quicker."
Managing the volume of software vulnerabilities and alerts is a difficult challenge for developers, he notes. "The only way for them to keep up with the pace of delivery is to operationalize application security and embed it into their DevOps pipeline."