Hacking Zoom: Uncovering Tales of Security Vulnerabilities in Zoom

- 25 mins

Hacking Zoom

Uncovering Tales of Security Vulnerabilities in Zoom

This blog post discusses my experiments in testing and hacking Zoom.

Zoom has become one of the most high-performing tech companies of 2020. Zoom is a digital video conferencing software that went public in IPO last year1, a few months before the global pandemic.

Zoom grew rapidly over the past year going from 10M active users in early 2019 to over 200M by mid-2020.

The popularity of Zoom has made it a high-profile target for hackers, nefarious actors, and the security community. Organizations worldwide are using Zoom to enable remote work. The UK government even used Zoom for cabinet meetings2. Simply put, we can see Zoom in every part of our lives today.

This post shares my research and experiments in testing and hacking Zoom.

Executive Summary

My research focused on identifying security vulnerabilities in Zoom. The result of the research revealed several severe security vulnerabilities that affect the Zoom production and development infrastructure, the Zoom Linux app, and Zoom’s implementation of end-to-end encryption implementation.

My experience with Zoom’s security and its VDP (vulnerability disclosure program) did not match what I had seen in the public media. I assume this is because Zoom focused on the security incidents that had generated the most negative public PR. This is also likely due to Zoom implementing a last-minute bug bounty program after its user base boomed during the global pandemic.

The first finding that I identified in April 2020 has been not patched. The first time I received a conclusive response regarding the finding was on July 14, 2020, after 4 months of reporting the vulnerability and numerous follow-ups from my side.

When I submitted my CFP to DEFCON 2020, I conducted another round of experiments on Zoom, where I identified new security vulnerabilities that affected different Zoom products. All discovered vulnerabilities were responsibly disclosed to Zoom.

I would also like to note that all of my research was self-funded. I have also not received any bounty/reward for my efforts by Zoom.

List of Identified Vulnerabilities

The responsible disclosure section discusses the process I have been through in conducting a responsible disclosure with Zoom. It was a painful experience with a lack of communication from Zoom for most of the time. There are many things that could have been done to improve the Zoom VDP.

I can see that Zoom had difficulties building their bug bounty program. As a result, I’m also listing suggestions to help enhance the program at the end of the post.

Who Am I?

I’m a cyber security engineer that specializes in offensive security and AppSec. Read more about my previous work at https://mazinahmed.net/.

Table of Contents


Recorded Conference Talk


Introduction

I started my first round of tests on Zoom in April 2020. My goal was to find an impactful security vulnerability that affects Zoom infrastructure and users. I identified a memory leak vulnerability that affects an API belonging to Zoom production infrastructure - the details of the finding, as well as other findings, are discussed later in the article.

Once I confirmed the presence of the vulnerability, I reported it directly to security@zoom.us per their security page at zoom.us/security.

I expected I would be receiving a quick responsible confirmation, followed by a patch, and probably a reward. Instead, I have been in a continuous circle of follow-ups with no response regarding my finding - the responsible disclosure.

I also contacted Luta Security, which was a contractor to Zoom to set up their VDP during Q1-Q2 2020, but there was no luck either in getting a fix or a detailed analysis for the responsible disclosure.

After all of the confusion about the attempts of responsible disclosure, I decided to take my research to DEFCON 2020. I submitted my CFP and notified Zoom regarding my intentions of disclosing my finding in Zoom on June 05, 2020. I still haven’t received a conclusive response after that.

When my CFP was accepted, I started conducting further security research on Zoom and found new vulnerabilities that were affecting their infrastructure, the Zoom Linux app, and their end-to-end encryption implementation.

I reported all of the new findings to Zoom on July 11, 2020, repeating my intentions of disclosing all of my research in DEFCON 2020. This was where I received the first conclusive response from Zoom.

Identifying Attack Surface

My first step when testing on targets is the attack surface identification. It’s a step where I do the reconnaissance phase to understand the running systems, exposed APIs, (un)maintained services, and everything that can be interesting from an adversary point of view.

Before attacking Zoom, I wasn’t aware of the attack surface; I had to learn it during this research.

Domains Discovery

Luckily for me, I run FullHunt.io, a vulnerability intelligence platform that aids in the attack surface discovery, monitoring, and automating security.

There is an internal FullHunt API that allows querying domains owned by organizations. I ran a query that returned more than 13 domains.

I added them to my FullHunt account to automate the discovery process. While I collected a tremendous amount of data I didn’t have the time to test everything, as this research is a personal non-funded experiment I was doing in my free time. I focused on a portion of the attack surface. I will be show-casing various findings I identified.

Findings

Zoom Public Kerberos Authentication

While port-scanning different assets, an asset grabbed my attention.

Targets: ca01.idm.meetzoom.us

Nmap port scan on ca01.idm.meetzoom.us

I noticed a running Kerberos service that is externally accessible. Kerberos is a network authentication protocol designed to secure authentication for client/server applications.

The naming convention for the asset indicates that it’s running an identity management solution or a PKI (public-key infrastructure).

While checking what was running on port 80, I found that the host was running FreeIPA3. This is an open-source identity management solution developed by RedHat.

There are no known severe public vulnerabilities reported previously. Researching for a zero-day within FreeIPA is an option, but I didn’t have the time to focus on it. Another option was to review Zoom’s implementation of Kerberos and FreeIPA setup.

I also found that another asset that runs the exact setup.

Target: va01.idm.meetzoom.us

Practically speaking, Kerberos allows a great size of attack surface once we have an authenticated account. While not being within the internal network, the initial entry for Kerberos is more difficult.

The HTTP interface is quite verbose in terms of error messages, however, these are the default responses in FreeIPA.

It’s possible to enumerate users from the [/ipa/session/login_password] API as shown in the next screenshots: 2

Invalid account

Invalid account

Valid account

Valid account

However, there is a lockout policy within the HTTP API to lock accounts that exceed the number of invalid authentication attempts.

After triggering the policy, I revisited the asset once the lockout period had timed out.

It seemed that attacking this functionality from the HTTP interface was the best idea. I moved my attack into the Kerberos service directly.

Attacking Kerberos

I tried enumerating users using the public Kerberos service running on UDP/88.

One of the advantages of authenticating in UDP is the ability to craft packets with different source IPs. This can help a lot in evading IP blacklisting on the service-level. I didn’t need to jump into that part, as there were no security controls that were triggered within my tests on this service. Both user enumeration and user password brute-forcing were not blocked.

Building Wordlists

Based on my background knowledge on Zoom, I understood the email and account profile pattern on Zoom follows: {firstName}.{lastName}@zoom.us. We can get a start initializing the naming from Zoom.us/team page:

zoom.us/team page

I also enumerated email addresses using OSINT. This will be used to enumerate valid user accounts on the Kerberos service that is publicly accessible.

All of the generated names were not valid users on the Kerberos service - perhaps the two assets were Shadow IT assets that were mistakenly exposed publicly by Zoom.

User enumeration yielded me with a single valid user, “admin”.

Valid users

I also brute-forced the account password, as there was no lockout policy for user accounts. It seemed like a dead-end for the timespan.

Discovery of a Memory Leak on a Zoom Production Server

Zoom allows uploading profile pictures on accounts. I’m always interested in image parsers as the attack surface on image parsers is wide, and can open doors for different attack vectors.

I fuzzed the image parsing on Zoom with a range of techniques. Based on my analysis of what was happening in the background:

  1. A user uploads a profile image.
  2. Only JPEG, GIF, and PNG are allowed.
  3. If the image is PNG or GIF, it is converted to JPEG.
  4. If the image is in JPEG, then image conversion is not triggered.
  5. If the image contains an invalid image header, the updating profile API aborts the process.
  6. The check for validating images is done by checking the magic bytes 4. This means we can’t control the first bytes of the file.

Based on my fingerprinting, I had a confident assumption that Zoom is using ImageMagick as a backend to their image conversion on their server-side. The common pattern on the deployment of image conversion microservices is they barely receive required updates and security controls once the microservice reaches a stable state. This happens as it is not as vital to the business as other functionalities within the infrastructure.

One popular vulnerability for ImageMagick is CVE-2016–3714, a remote code execution vulnerability.

I tested the functionality with the CVE-2016–3714 and it seemed to be patched.

Another less popular vulnerability that ImageMagick was vulnerable to was a memory leak vulnerability that occurs because of the uninitialization of the memory space on the GIF parser of ImageMagick. As a result, we can leak portions of the memory in a “Heartbleed” approach.

All versions of ImageMagick builds before https://github.com/ImageMagick/ImageMagick/commit/9fd10cf630832b36a588c1545d8736539b2f1fb5 are vulnerable.

The vulnerability is not commonly known. It also has a registered CVE of CVE-2017-15277.

I generated a payload using the exploit5 for the vulnerability. When uploading the payload, the converted images were rendered in a way that indicated successful exploitation.

Original Payload

Payload

When rendered by Zoom APIs.

Exploit

I further confirmed that this is not a rendering bug on the ImageMagick implementation at Zoom, by generating a typical black image by ImageMagick with the same specs of the payload:

$ convert -size 300x300 xc:black black.gif
Normal view

Normal view

After a normal GIF image is rendered by Zoom: Rendering a normal image.

The result showed that this image is rendering normally when supplying a normal GIF image with the same specifications of the payload, confirming the existence of the security vulnerability, and illuminating the part where there is a rendering issue on the ImageMagick setup is at Zoom.Us.

Automating the Exploitation

To plan the automation of the exploitation of the memory leak at Zoom, I need to:

  1. Generate a new unique payload
  2. Upload it to Zoom
  3. Download the rendered file.
  4. Extract the data from the corrupted file rendered by Zoom.
  5. Repeat, and store leaked memory portions.

Proof of Concept

Video

A Memory Leak on Zoom production is not the end…

After a week from the time of automating the exploit for the memory leak, I remembered that Tavis Ormandy had researched on the GhostScript engine6. GhostScript is an interpreter for the PostScript language, and is also used in ImageMagick.

Tavis’s research disclosed a remote command execution on GhostScript. This research is vital to this functionality since if we’re able to exploit GhostScript on the ImageMagick, we can achieve remote command execution.

I confirmed this vulnerability existed on Zoom’s build with the timeline of ImageMagick patches. In July 2017, the memory leak vulnerability was discovered and patched. In August 2018, GhostScript and ImageMagick patched the remote command execution vulnerability. This meant that if the memory leak was present at Zoom production, then the GhostScript RCE was also present at Zoom production.

I replicated this vulnerability locally in my environment based on the environment of Zoom.

Proof of Concept Payload

Proof of Concept Payload

Proof of Concept Payload

Local replication of the RCE vulnerability

Local replication of the RCE vulnerability

Zoom’s Prevention

There is a check on the magic bytes on uploaded images within the Zoom API [/p/upload], otherwise, full exploitation of the vulnerability is possible. If the microservice is called in other places, then it may be still exploitable there.

Shadow IT & Zoom

Shadow IT is a pattern of public services at Zoom. Some instances don’t receive frequent updates and are publicly accessible. I found a development instance that has not been updated for at least 10 months, and although I’m not sure, I think it was pushed to a Zoom customer. This meant that if there is a vulnerability that was patched on production, it may be exploitable on these Shadow IT instances. The way I confirmed this is because Zoom left a version build file on the instance.

Instance age

This screenshot was taken on July 4th, 2020. The build time was September 10th, 2019.

Another addition to complete the hacking puzzle is: https://bscdev.meetzoom.us/nginx_status

Nginx status on the ShadowIT asset

The Nginx status page is enabled due to a backend misconfiguration in the development instance, allowing me to have a confident guess that this instance is not heavily used, and potentially have lesser logging triggers compared to the Zoom.us production web-app.

It’s showing 9 active connections on the instance, making it an excellent fit to test, while not triggering alerts.

Zoom App for Linux

I also had a testing session on the Zoom App for Linux. The security community has not put a focus on the Zoom client for Linux in terms of security research. I thought of initiating this part.

Zoom TLS/SSL is Broken By Design on Linux

Whenever traffic is intercepted with a custom TLS/SSL certificate, Zoom prompts users with this message:

Zoom: Untrusted Server certificate

Once users click “Trust anyway”, the certificate is added to a local Zoom database with the fingerprints of the certificate. When the next request occurs, the whitelisted certificate is permitted as expected.

The catch here is, all TLS/SSL certificates can be directly “accepted” by malware to the local Zoom database without additional permissions. The custom implementation of the Zoom certificate database does not solely rely on system CA certificate DB. System CA certificate DB requires root access in normal cases to whitelist a new SSL/TLS certificate.

I wrote a Proof of concept in Golang that injects TLS/SSL certificate fingerprints into the local Zoom database. Once this code is executed on a user machine, all injected certificates will be accepted without errors on Zoom.

Code:

Zoom Launcher Implementation: What’s a bad design for an application launcher? Zoom Launcher for Linux

Launching Zoom

[/usr/bin/zoom] is a symlink of [/opt/zoom/ZoomLauncher]. When Zoom is called:

$ zoom

The following occurs.

Launching Zoom

This sounded interesting already.

Apparently, Zoom is checking if there is a file on the $PWD directory that is for Zoom, and it executes it, otherwise it navigates to the Zoom installation directory and executes another binary, Zoom executable.

This sounds bad already. But still, the next part is the surprising part. if there is an executable called “zoom” on the $PWD directory, it will execute it as a child process for /usr/bin/zoom.

Proof of Concept

This breaks all of the protection of application whitelisting, allows malware to run as a subprocess of a trusted vendor (Zoom), and is a bad design/security practice by all means.

I had thoughts on why it was designed this way, but I simply didn’t find a good reason.

Zoom Local Database Implementation: Bad practice for Linux security.

I noticed another interesting issue in Zoom local database implementation. Zoom local database allows Zoom to store custom configurations and user data.

Assuming there is access to the user machine, by any level of permissions, anyone can read and exfiltrate Zoom user data and configuration.

Zoomus.db local database permissions

The customer data and main PII details are obfuscated, which is good, however, there is still data that is exposed and is important.

Zoom is End-to-End Encrypted? Not fully.

Zoom announced that it’s now supporting end to end encryption, and has pushed additional security updates to protect users in May 20207. It has been everywhere in the news.

During my tests, I also tested Zoom Chat, a feature on Zoom that allows group chats. It allows teams to collaborate, share files, and of course, send messages.

I have noticed that the chat logs of Zoom are stored on-disk in plain-text. Combining this with the Linux file permissions bad practice, it means that any process can unrestrictedly access all of the Zoom chats.

Video

Responsible Disclosure

Timeline

Zoom’s Analysis & my response to the analysis

“Zoom Public Kerberos Authentication”

Zoom: These were development servers with no access to any production data. Moreover authentication required 2FA, so brute forcing a password, though not demonstrated in your report, would have been insufficient to gain access to the system.

While I agree it may be a forgotten development server that was mistakenly exposed, I haven’t seen any references or indications or having 2FA implemented. In all cases, it’s down now, which is great.

“Discovery of a Memory Leak on a Zoom Production Server”:

Zoom: After an internal investigation, we’ve concluded that the behavior you found was not a memory leak but just our image utility’s best effort at converting a malformed gif into a jpeg.

This is the exact same behavior that is expected from valid exploitation of the CVE-2017-15277 as analyzed in the original report on ImageMagick 8.

The observed behavior that occurs in ImageMagick is ImageMagick’s effort in converting a malformed a gif, leaking a portion of the system memory when providing a malformed gif that has an uninitialized palette in the gif file; this is where the vulnerability is there.

From https://github.com/ImageMagick/ImageMagick/issues/592.

Gif coder leaves the palette uninitialized if neither global nor local palette is present in a gif file. If ImageMagick is used as a library loaded into a process that operates on interesting data, this can cause security consequences.

Having a malformed gif rendered this way confirms the presence of the vulnerability.

Zoom: we did check and confirmed that ImageMagick is not used for image conversions here.

However, the same vulnerability is reproduced, maybe a fork of ImageMagick? an image processing software that is vulnerable to the same CVE? In all cases, it’s clear that something is wrong.

“Shadow IT & Zoom”

Zoom: These are non-sensitive information disclosures from a shared development environment. Information hygiene is important to us and we appreciate you reporting this finding.

Great! FullHunt.io can help here. Probably the best product out there for mitigating Shadow IT risks.

“Zoom TLS/SSL is Broken By Design on Linux”

Zoom: This is per user certificate pinning and intentionally allows for the user to allow custom certificates. The user can write to their own database, but no other non-root users can. It’s common best practice to have user applications run at their privilege level, as requiring Zoom to run as root would introduce unnecessary security risks to Zoom and our customers.

“Zoom Launcher Implementation”

Zoom: This will be resolved in version 5.2.0 to be released on August 2nd. Note that to exploit this finding, an attacker would need to have compromised the victim’s computer by other means, and only if it was running the Linux operating system. Further, this attack also only works if the victim is running Zoom for the first time.

“Zoom local database implementation”

Zoom: This will be resolved in version 5.2.0 to be released on August 2nd. Note that, as you stated, to be able to read this data the attacker would need to have already compromised the victim’s computer by other means, and only if that computer is running a Linux operating system.

I’m not sure if the same vulnerability is also reproduced on macOS. It may be worth checking.

“Zoom is End-to-End Encrypted?”

Zoom: We’re working on remediation for this finding. Note to be able to read this data, an attacker would need to have already compromised the victim’s device by other means.

I appreciate the detailed analysis done by Zoom security.

Zoom Linux App Update

On August 3rd, 2020, the Zoom 5.2.4 was released, without mentioning the security patches at all. Zoom issued a silent fix to patch the reported security vulnerabilities without informing users about the fixes.

Zoom release notes for Zoom 5.2.4

Conclusion

Zoom stated that they’re planning to patch the reported vulnerabilities, and there will be a security fix for the Zoom Linux client on August 2nd.

Zoom has massively grown during the global pandemic. As with any company building their security program, there are many challenges that Zoom appears to be facing, despite the large budget for security.

Coordinating the security disclosure has been a difficult experience from a security researcher’s perspective, despite all of the effort done by Zoom to hire top-class security firms to aid in building the program. The main reason this is happening is because of the “last-minute” implementation of their vulnerability disclosure program. I would be surprised if I’m the only researcher in the world that had this experience.

I would also like to note that all of the research was self-funded. I have also not received a bounty/reward for my efforts by Zoom.

Building a security program is not easy, there are many aspects to consider and processes to follow. A budget can “aid” in hiring great talents, but cannot build the program alone. It’s always important to start building the security program from an early point; it takes time and effort from different teams within the organization. It has never been an easy initiative to build a security program. A vulnerability disclosure program is only a single aspect in a larger cycle that should be there and should be done correctly.

I was also surprised that my experience with Zoom did not match the expectations. I have been seeing in the media a lot of great impressions about the Zoom vulnerability disclosure program. However, what I have experienced was different. I hope this is not because my research was not media-focused with public media involvement.

Acknowledgment

I would like to thank Matt Suiche of Comae Technologies for his help in having this research available.

References

  1. https://www.cnbc.com/2019/04/18/zoom-ipo-stock-begins-trading-on-nasdaq.html

  2. https://www.infosecurity-magazine.com/news/uk-government-zoom-despite-mod/

  3. https://www.freeipa.org/page/Main_Page

  4. https://en.wikipedia.org/wiki/File_format#Magic_number

  5. https://github.com/neex/gifoeb

  6. https://bugs.chromium.org/p/project-zero/issues/detail?id=1640

  7. https://blog.zoom.us/end-to-end-encryption-update/

  8. https://github.com/ImageMagick/ImageMagick/issues/592

Mazin Ahmed

Mazin Ahmed

Thoughts of a hacker

rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora