Submitted by matt_eaton
on Tue, 07/09/2019 - 06:09 PM
Today after reviewing the public disclosure from Jonathan Letischuh on Medium about the Zoom webcam exploit I decided to take a look at my local copy of macOS 10.15 and detail my tests for anyone wanting to test this on their machine or prevent this from happening to them too. This exploit is covered in full detail at CVE-2019-13450 but what has been reported to happen is that when a US based customer of Zoom installs the Zoom client it will keeps a localhost server running at http://localhost:19423 or 19421. According to Jonathan's article, this server stays up and running even when the client is not in use or even if the client is uninstalled. I could not confirm either of these reports. I tested this out on my machine, the following is what I found.
NOTE: This test is being run with macOS 10.15 Catalina, Beta 3 and with Zoom.us version 3.5.64836.0908.
Testing for the Exploit 🧪
According to the Jonathan's article and the publicly available CVE a localhost server is always kept active to autolaunch a Zoom client to join a meeting. This localhost server is reported to be active at http://localhost:19423 or 19421. To test this I wanted to see if I could observe the active LISTENING ports for 19423 or 19421. I ran the following command but did not come up with anything.
# List out ports that are listening $ sudo lsof -n -i -P | grep LISTEN
From there I tried also making cURL requests against both of these ports on localhost but received a connection refused response.
# cURL into localhost on port 19423 or 19421 $ curl http://localhost:19423
This tells me that because the connection is being refused that the localhost is most likely not up and running for these ports, which is a good sign. To be 100% sure I wanted to test launching into a Zoom meeting with a local HTML file to see if the port had changed. To do this I loaded the URL used in Jonathan's article into a local .html page and fired it up in Chrome. NOTE, this code below is for testing only and should not be used in any malicious way shape or form.
<html> <head> </head> <body> <h3>Launches iFrame with Embedded Zoom Meeting Link</h3> <p>Look at Chrome developer tools now if your Webcam did not turn on</p> <iframe src="https://zoom.us/j/492468757" width="1000" height="600"/></iframe> </body> </html>
The good news is that launching my version of Zoom (3.5.64836.0908) did not respond in macOS 10.15. The bad news is that according to the Chrome developer tools, the iFrame did try and activate the localhost URLs to fire up the Zoom client on both 19423 and 19421 and received the same connection refused message.
How to Prevent this from Happening 🔐
Now that I have described my test cases and how this exploit did not take effect on macOS 10.15, I also wanted to describe a few ways to prevent this from happening to you if you are at risk.
- If you are not a Zoom user, take the Zoom.us client and move it into you trash can and empty your trash can. The Zoom.us client is found in your Applications folder.
- If you are a Zoom user, make sure that your Video settings are turned to off when you join a meeting.
- Make sure that the localhost pid is not running. That way you activate the client with your own free will. To kill the pid, run: lsof -i :19421 and then kill -9 [pid].
- Disable video for Zoom from the Plist file found at ~/Library/Preferences/us.zoom.xos.plist by adding this option to it: ZDisableVideo 1.
For more information on prevention and to keep updated with this issue, see Jonathan's article and the public CVE:
Member for
3 years 9 monthsLong time mobile team lead with a love for network engineering, security, IoT, oss, writing, wireless, and mobile. Avid runner and determined health nut living in the greater Chicagoland area.