{"id":20027,"date":"2022-09-08T00:25:18","date_gmt":"2022-09-07T20:25:18","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/20027\/"},"modified":"2022-09-08T00:25:31","modified_gmt":"2022-09-07T20:25:31","slug":"defcon30-zoom-vulnerability","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/20027\/","title":{"rendered":"A Zoom vulnerability, and the war between the hackers and the developers"},"content":{"rendered":"

In March 2020, as the whole world was just getting to grips with working remotely, a vulnerability<\/a> was discovered in the installer of Zoom \u2014 one of the world\u2019s prime remote communication tools \u2014 allowing arbitrary code execution on Apple computers. Zoom fixed the vulnerability\u2026 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.<\/p>\n

What\u2019s this latest vulnerability?<\/h2>\n

\nThe new problem in the Zoom videoconferencing client was highlighted<\/a> 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.<\/p>\n

More details please<\/h2>\n

\nTimely 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\u2019t 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\u2019s 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.<\/p>\n

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\u2019s still possible to substitute the file after downloading when it\u2019s already saved on the disk but not yet installed.<\/p>\n

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\u2019s signed by the vendor\u2019s 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\u2019t need to enter a password.<\/p>\n

\"Quote<\/a>

Quote from Patrick Wardle\u2019s presentation showing the benefit of signing updates. Source<\/a>.<\/p><\/div>\n

The digital signature is important. After all, the program is downloaded to the user\u2019s computer from some corner of the internet and run with maximum privileges. So you need to make sure it\u2019s the right program. And simple spoofing of the downloaded file won\u2019t work: as shown above in the slide from Patrick\u2019s presentation, substituting the file results in an error message \u2014 the fake update has no digital signature, and it\u2019s extremely difficult to spoof one.<\/p>\n

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:<\/p>\n

Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA<\/em><\/p>\n

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 \u201cZoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA.pkg\u201d<\/em> instead of the standard \u201cZoomUpdate.pkg\u201d<\/em>. And that would be enough to fool the validation procedure: the required line is there, so the file must be legitimate \u2014 even though it\u2019s the wrong file and the magic words are in the wrong place!<\/p>\n

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!<\/p>\n

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 \u201cupgrade\u201d 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.\n<\/p>\n

What\u2019s the big deal?<\/h2>\n

\nPatrick Wardle\u2019s research shows how important it is to secure the delivery and installation of updates. What\u2019s 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 \u201cdowngrade\u201d option \u2014 the installation of an older, more vulnerable version of Zoom through the standard update delivery mechanism. But it wasn\u2019t until July 2022, six months after Wardle\u2019s report, that the digital certificate validation mechanism was repaired.<\/p>\n

This, however, did not completely resolve the issue. Sure, the two simplest attack methods were removed from the would-be hacker\u2019s 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 \u2014 eight months after reporting the problem to Zoom \u2014 the vulnerability still wasn\u2019t completely patched! Only on August 17, five days after Patrick\u2019s report, the developers finally patched the problem. However, this statement needs to be independently verified.\n<\/p>\n

On hackers and developers<\/h2>\n

\nReading Patrick Wardle\u2019s report, one can\u2019t 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\u2019t 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\u2019t solve the problem: they\u2019re the only developers the world has.<\/p>\n

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\u2019s 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.<\/p>\n

Programs become safer incrementally, with every small patch. You can\u2019t 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\u2019s responsible attitude.<\/p>\n

We end this tale with an important reminder: malware often gets onto a computer during the first installation of software. Therefore, it\u2019s 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\u2019s a chance your data will be stolen through very simple hacking methods \u2014 without the need to exploit sophisticated vulnerabilities in official software.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Takeaway from DEF CON 30: vulnerability in Zoom for macOS.<\/p>\n","protected":false},"author":665,"featured_media":20030,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[14,741,1328,2282,268],"class_list":{"0":"post-20027","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-apple","11":"tag-def-con","12":"tag-macos","13":"tag-videoconferencing","14":"tag-vulnerabilities"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/20027\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/defcon30-zoom-vulnerability\/24561\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/27010\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/defcon30-zoom-vulnerability\/24918\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/25259\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/defcon30-zoom-vulnerability\/27616\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/defcon30-zoom-vulnerability\/33925\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/defcon30-zoom-vulnerability\/11012\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/45420\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/defcon30-zoom-vulnerability\/19410\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/defcon30-zoom-vulnerability\/20011\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/defcon30-zoom-vulnerability\/29272\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/defcon30-zoom-vulnerability\/25412\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/defcon30-zoom-vulnerability\/30967\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/defcon30-zoom-vulnerability\/30663\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/vulnerabilities\/","name":"vulnerabilities"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/20027","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=20027"}],"version-history":[{"count":1,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/20027\/revisions"}],"predecessor-version":[{"id":20029,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/20027\/revisions\/20029"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/20030"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=20027"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=20027"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=20027"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}