Vulnerability in Zoom for macOS | Kaspersky official blog
Credit to Author: Enoch Root| Date: Wed, 07 Sep 2022 20:24:06 +0000
In March 2020, as the whole world was just getting to grips with working remotely, a vulnerability was discovered in the installer of Zoom — one of the world’s prime remote communication tools — allowing arbitrary code execution on Apple computers. Zoom fixed the vulnerability… almost. Fast-forward to August 2022, and a similar hole has been found (in terms of both location and exploitation consequences). This post examines this latest security issue, and seeks to explain why holes in software sometimes crop up repeatedly in the same place. It ends with advice regarding what to do about it.
What’s this latest vulnerability?
The new problem in the Zoom videoconferencing client was highlighted by renowned researcher Patrick Wardle at DEF CON 30 in early August of this year. Long story short, a few of bugs were found in the automatic update system for am Apple Zoom client. These bugs, in theory, made it possible to obtain so-called super-user rights, which allowed a would-be attacker to do whatever they want on the host computer. To exploit the vulnerability, however, the attacker needed to have already had physical access to the computer, albeit without special rights. But this is not an entirely unrealistic scenario: for example, the user might go for lunch and forget to lock their computer. Theoretically, the vulnerability could also be exploited by malware, which otherwise would not cause serious damage to the user.
More details please
Timely delivery and easy installation of updates are important requirements for any modern piece of software. Ideally, bug fixes should be installed without the user even noticing, but this isn’t always possible. To complete an update, you often have to restart a program, re-login, or even reboot. We all get annoyed by pop-up messages reminding us to update a program, operating system, smartphone or tablet firmware. But it’s vital to do so: updates close security holes that could otherwise be used against you. In some particularly serious cases, you need to protect vulnerable software against active cyberattacks immediately: one day of delay can cost you data.
The bog-standard way to update a macOS application is no different from its first installation: download the new version, run the file, and enter a user password. Zoom tried to simplify this procedure: the client accesses the server, downloads the new version, and it installs all by itself without requiring the user to enter a password. Unfortunately, this process of communicating with the server, then downloading and installing the update, is not always implemented correctly. Ten years ago, accessing servers without data encryption was common practice, allowing a potential attacker to simply replace the update file with malware. Encryption was implemented, making that more complicated, but it’s still possible to substitute the file after downloading when it’s already saved on the disk but not yet installed.
In the latest (as of late last year, when Patrick began his research) version of Zoom, everything seemed to be okay. The client accesses a special update server via a secure channel, downloads the file, validates its authenticity (checks it’s signed by the vendor’s certificate), and installs it. For installation, the SW requests temporary super-user rights form the system, but in such a way that the user doesn’t need to enter a password.
Quote from Patrick Wardle’s presentation showing the benefit of signing updates. Source.
The digital signature is important. After all, the program is downloaded to the user’s computer from some corner of the internet and run with maximum privileges. So you need to make sure it’s the right program. And simple spoofing of the downloaded file won’t work: as shown above in the slide from Patrick’s presentation, substituting the file results in an error message — the fake update has no digital signature, and it’s extremely difficult to spoof one.
Alas, the digital signature validation process itself was flawed. It worked by running a system utility. This displayed the digital signature parameters of the downloaded update, including a line indicating which company received the certificate:
Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA
The output of the utility was processed, and if this line was present, the installation began. The problem was that the name of the file also showed up in the output. So, theoretically, an attacker could create a malicious update craftily named “Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA.pkg” instead of the standard “ZoomUpdate.pkg”. And that would be enough to fool the validation procedure: the required line is there, so the file must be legitimate — even though it’s the wrong file and the magic words are in the wrong place!
That is, an attack could look like this: the update validation procedure is initiated (not hard to do), then the legitimate update is downloaded, replaced with malware, and renamed so as to dupe the broken certificate validation process. The malicious file is run with system privileges and the computer is hacked!
But on December 20, 2021 a Zoom update was released, which put an end to this attack vector. The change was simple: a file rename was forced after download. But Patrick Wardle was able to modify the attack: if Zoom has been secure since 5.9.0, what if we “upgrade” the client to an older version? And it worked: the old update had a legitimate digital certificate, and the version was not checked during installation.
What’s the big deal?
Patrick Wardle’s research shows how important it is to secure the delivery and installation of updates. What’s more, the story of this bug clearly demonstrates how software developers often try to solve a problem through some simple change without understanding it in detail. At first (even before Wardle reported the problem to Zoom), in December 2021, they defeated the simplest version of an attack using trivial file substitution and bypassing certificate validation. After the vulnerability was reported, in April 2022, they closed the “downgrade” option — the installation of an older, more vulnerable version of Zoom through the standard update delivery mechanism. But it wasn’t until July 2022, six months after Wardle’s report, that the digital certificate validation mechanism was repaired.
This, however, did not completely resolve the issue. Sure, the two simplest attack methods were removed from the would-be hacker’s arsenal: replacing the update file with malware and downgrading to a vulnerable version. But there was another problem: an update file run with super-user privileges could be modified by anyone with access to the computer! An attacker only needed to find a way to slip a malicious file into the Zoom installer at the right moment: after the digital signature was validated, but before the installation started. And it actually worked. As a consequence, when Patrick Wardle delivered his findings at DEF CON 30 in August 2022 — eight months after reporting the problem to Zoom — the vulnerability still wasn’t completely patched! Only on August 17, five days after Patrick’s report, the developers finally patched the problem. However, this statement needs to be independently verified.
On hackers and developers
Reading Patrick Wardle’s report, one can’t help wondering why it has to be like this. How do such childish vulnerabilities arise in critical parts of software, and why, even after an issue is reported, are they closed only eight months later and at the third attempt? We don’t wish to unfairly accuse developers of incompetence. In all programs, bugs and errors crop up from time to time. And if all programmers make mistakes, cursing them won’t solve the problem: they’re the only developers the world has.
Perhaps the reason is that white-hat hackers (who report their findings to vendors) and cybercriminals (who exploit holes to attack users and make a profit) have different priorities compared to software developers. When you develop a program, it’s vital that it performs hundreds of different tasks correctly. Your priority is to place users in their comfort zone, which means, in the case of Zoom, good communication quality and compatibility with different operating systems and thousands of devices, both old and new. While all the hacker needs is to find one bug that can be used for dirty tricks. Now imagine someone informs you of a vulnerability. Yes, you need to patch it, but without wrecking the delicate system of client-server software. You have to test it in hundreds of different configurations. Naturally, the developer wants to solve the problem with minimal modifications. And these are often not enough.
Programs become safer incrementally, with every small patch. You can’t solve absolutely all problems and create an ideal app just like that. Or, rather, you can, but only by starting from scratch. But some critical elements should be maintained in the best possible way, and the update delivery system is definitely one of them. We, users, need to be able to trust the programs we install on our computers. And in this sense, the story of Zoom vulnerabilities is a positive example of an independent researcher and a developer working together to solve a problem. It clearly demonstrates the developer’s responsible attitude.
We end this tale with an important reminder: malware often gets onto a computer during the first installation of software. Therefore, it’s important to check that utilities are downloaded from official sources, to use app stores where possible, and in no circumstances to download programs from suspicious websites. Otherwise, there’s a chance your data will be stolen through very simple hacking methods — without the need to exploit sophisticated vulnerabilities in official software.