Screenshot by Josh Centers
Zoom and RingCentral Exploits Allow Remote Webcam Access
Recently, software engineer Jonathan Leitschuh uncovered a major security flaw in the Mac client for Zoom, a video conferencing system popular with businesses, and RingCentral, which is a rebadged version of Zoom. Zoom made it so that when you clicked a Zoom link and had the client installed, the link automatically opened the Zoom client. It turns out that this implementation isn’t secure, because an attacker can create a link that will automatically join you to a call and turn your video camera on. (Note that it cannot disable the green LED indicator of the FaceTime cameras in the Mac, so if you use that camera exclusively, you always know when it’s on.)
Even worse, you couldn’t eliminate the vulnerability by merely deleting the Zoom app, because Zoom installed a hidden Web server on your Mac that would reinstall the Zoom client for you if necessary when you clicked a Zoom link.
Initially, Zoom defended its use of the hidden Web server, but quickly repented, and released an update, version 4.4.4 (53932.0709), that removes the hidden Web server and offers an option to completely uninstall Zoom. The company has promised additional updates to improve user privacy.
To make sure that users who neglect to update the Zoom app are not exposed, Apple released a silent macOS update that removes the hidden Web server. The update installs automatically without any interaction on your part. To see if it’s installed, open System Information in /Applications/Utilities, and click Installations, which is under Software in the sidebar. Click the Install Date column header so that you see the latest installations first, and look for MRTConfigData, which should be at version 1.45 or above. (Hat tip to Howard Oakley for this tidbit.)
Reader Al Varnell has told us that Apple’s update did not remove the RingCentral Web server, so you’ll have to update its client to the latest version to get rid of it.
Unfortunately, the hidden Web server was only part of the vulnerability. Even after the server is uninstalled, it’s possible for a Mac to inadvertently join a Zoom conference with the Web cam enabled.
How to Tell If You’re Affected
To test for the vulnerability for yourself, the easiest way is to click one of the links below, which Leitschuh set up as proofs of concept. The second link will activate your Web cam automatically. Be warned that if the vulnerability is present clicking either link will drop you into a video conference, likely with other people as freaked out as you are.
https://jlleitschuh.org/zoom_vulnerability_poc/
https://jlleitschuh.org/zoom_vulnerability_poc/zoompwn_iframe.html
Fixing the Zoom Vulnerability
The Apple update takes care of the hidden Web server, but you can still be tricked into clicking a Zoom link that activates your Web cam. Here is how to avoid that.
First, check if you have the latest version of the client by opening Zoom and choosing zoom.us > Check for Updates. If the app prompts you, click Update Now to update it.
Note that version 4.4.4 (53932.0709) adds a Zoom icon to your menu bar. You can disable that by opening Zoom, going to zoom.us > Preferences > General and unchecking “Add Zoom to macOS menu bar.”
To prevent Zoom from activating your Web cam without your explicit consent, open Zoom and choose zoom.us > Preferences (Command-,), click Video in the Settings window’s sidebar, and check the “Turn off my video when joining a meeting” option.
If you use Chrome or Firefox as your browser, you’ll also want to check and change some settings to prevent Zoom links from opening automatically, per Karan Lyson on GitHub, because it’s possible that you gave Zoom permission to open Zoom conferences automatically when you click a Zoom link. (This doesn’t affect Safari.)
But if you don’t want to fool with these settings, it’s easier to uninstall Zoom entirely (and we wouldn’t blame you if you did). Open Zoom, choose zoom.us > Uninstall Zoom.
To fix this in Chrome:
- Quit Chrome by choosing Chrome > Quit Google Chrome.
- Open your user library folder in the Finder by holding Option, choosing Go in the menu bar, and choosing Library.
- Open the Application Support folder and navigate to
/Google/Chrome/Default. - Double-click the Preferences file, which opens in TextEdit by default.
- Press Command-F to open Find, and search for
"zoommtg":falseand"zoomrc":false(just search for “zoommtg” and “zoomrc” to reveal them). - If these strings exist, delete them and the comma immediately after.
- Choose File > Save, close TextEdit, and re-open Chrome.
Fortunately, this is easier in Firefox:
- Choose Firefox > Preferences.
- Click in the Find in Preferences field.
- Search for
zoommtgandzoomrc. - If these preferences are found, change them to “Always ask.”
As for the Web server that Zoom snuck onto Macs, between Apple’s update and the Zoom update, it should be eliminated. I’ve tested and confirmed this on my machine by deleting the hidden ~/.zoom file I made in Terminal and reinstalling Zoom, which didn’t recreate the directory that older versions kept the Web server in (see my description of the old Terminal method below if you don’t know what I’m talking about). Don’t take my word for it: you can check yourself by opening Terminal, entering the following command, and pressing Return:
lsof -i :19421
That command searches for services listening on port 19421, which is the port that both Zoom and RingCentral used. After the update, it should dump you back to the command line with no result. Under older versions of Zoom, you’d see an entry called ZoomOpene like in the screenshot below.
You can also enter ls ~/.zoom, which should return with “No such file or directory” after updating to version 4.4.4 (53932.0709).
The Old Terminal Method
Before the Apple update and Zoom’s 4.4.4 (53932.0709) update, you had to use Terminal wizardry to disable the hidden Web server. You no longer need to do any of this to fix Zoom, but I’m leaving it here both for historical reference and because this is a handy technique to be aware of in case another app pulls a stunt like this.
First, open Terminal and enter kill -9 PID, with PID (process identification number) being the PID that you saw when you ran lsof -i :19421. In my case, that PID was 24272, so I ran kill -9 24272. After you kill the process, you can run lsof -i :19421 again to confirm it worked; if successful, Terminal will return with its normal command prompt.
Then, create a new file in the Web server’s place, and set its permissions so Zoom can’t overwrite the file:
rm -rf ~/.zoomus; touch ~/.zoomus && chmod 000 ~/.zoomus;
If you’ve used RingCentral, you’ll have to use a different set of commands to disable the Web server. As I described above, use kill -9 PID to kill any process on port 19421 (which you can find with lsof -i :19421) and then run this command:
rm -rf ~/.ringcentralopener; touch ~/.ringcentralopener &&chmod 000 ~/.ringcentralopener;
Note that you’ll have to follow these steps for every user account on your Mac.
Interestingly, removing the Web server doesn’t disable Zoom or RingCentral functionality at all.
Questionable Judgement
Thankfully, Zoom has (sort of) addressed its issues, but only after intense pressure.
TidBITS Security Editor Rich Mogull had this to say about the vulnerability: “Zoom’s efforts to circumvent Safari’s native security are completely irresponsible. The Web server ‘feature’ merely adds a small amount of convenience at a massive security cost. This is a flagrant and deliberate security and privacy violation that raises serious concerns over Zoom’s internal security prioritization and threat modeling.” We agree. And as Steve Troughton-Smith pointed out, bad actors like Zoom justify Apple’’s continued efforts to lock down macOS.
If you have to use Zoom, you can rest assured for now that the known issues have been addressed. But what’s less assuring is that there may be other security and privacy issues lurking beneath the surface, waiting to be discovered. And with Zoom already showing incredibly poor judgment, we advise uninstalling the client unless you absolutely need it.
Thanks for bringing us the solution for this! I use it weekly for a class I teach, and it has worked really well. I have always hosted, though, never joined someone else’s session. All of the specifics and instructions in your article made perfect sense, but when I came to this sentence…
I guess I’m reading it wrong, but I’m left asking, “Does Josh mean ‘If you’ve never used Zoom, you may have to install the app but then disable part of it by following these instructions; just using your regular browser won’t/may not work’?”
Thanks again.
Zoom has updated its statement, and is now rushing out an update that will remove the Web server. We’ll update our instructions when that happens.
The purpose of the Web server is to reinstall the client if you’ve uninstalled it, so you may have to take a few more steps to join a conference if you’ve uninstalled the app. I’d rewrite it to be clearer, but when Zoom updates the app to remove the Web server I’ll have to rewrite the article anyway, so…
Blue Jeans uses the same nonsense, and the app has not been updated to remove it (so far, from what I can see):
https://support.bluejeans.com/s/article/BlueJeans-Detector-Service
All of the terminal commands are a bit of overkill; there’s a much simpler way to deal with this. Go to System Preferences --> Users & Groups --> Login Items. You’ll see “Zoom Opener” listed there - just select it and click the “-” to delete it. Then log out or restart your Mac. That will stop the background server from running automatically, but the file will still be in a hidden “.zoomus” folder (to delete that, the terminal command is still useful, but it won’t do anything if you leave it there).
Zoom has released a new version of its client, version 4.4.4 (53932.0709), which offers a complete uninstall option and ditches the hidden server. I’ve update the article to reflect that update, but I’ve left the Terminal commands for historical reference and in case another bad app pulls a similar stunt.
Or in case, for some unfathomable reason, people are reluctant to download and install yet more software from these known purveyors of malware.
Fool me once…
Now Apple has joined in on the fun, releasing a silent update to kill the Zoom Web server. I’ve updated the article again to reflect that.
I’ve updated the article AGAIN to add more information about the stealth Apple update, and to add instructions from Karan Lyons on how to mitigate the vulnerability in Chrome and Firefox. Really, I just advise updating the Zoom client and uninstalling it entirely, it’ll save you a lot of trouble.
While the second of Leitschuh’s proof of concept links works and dumps me into the conference (audio/video initially both off as set in prefs), the first link just leads me to a page with broken image link.
Apple has released a second silent update to address vulnerabilities in RingCentral and Zhumu, the Chinese version of Zoom.
Just wondering, what app would you suggest for duplicating Zoom’s functionality?
Howard Oakley has penned a nice article about how to check that Zoom is really gone.
Since I read your article, I’ve been checking the System Information app’s “Installations” list, but the “MRTConfigData” item still says “1.28, 2018/01/27, 15:59.”
This morning (Japan time) I installed Security Update 2019-004 into my iMac’s High Sierra 10.3.6, but System Information still says the same thing about MRTConfigData.
I searched for files that has the text string “METConfigData” in the name, and EasyFind found two files named com.apple.pkg.MRTConfigData…, one ending with".plist", and another ending with “.bom”, and both are in /System/Library/Receipts, and are dated 2018/01/27, 15:59.
Howard Oakley’s page says High Sierra should have MRT Config Data version 1.47, 18 July 2019, but my iMac’s High Sierra system doesn’t have that! It says only version 1.28 of January 2018.
However, there is an application named “MRT” in /System/Library/CoreServices, and its last modified date is today, July 23, 2019, 9:50 AM (Japan time), that was when Security Update 2019-004 was being installed.
That would seem to indicate to me that you don’t have your System Preferences properly configured to receive updates. Go to System Preferences->App Store and make sure you have checked both the “Automatically check for updates” and “Install system data files and security updates” enabled. The security updates mentioned here are not the same as the update you manually installed today, rather they are critical background (silent) installs.
System Information only shows you the dates when a particular package is installed, so it will show you that Security Update 2019-004 was installed, but not the individual components like MRT.
Yes, you have been looking in the wrong place for your current version number. That app is what was installed with the Security Update, so you are now fully up-to-date. There is a Terminal command you can use to see what version you have, but a much easier way is to download Howard Oakley’s SilentKnight or LockRattler app from SilentKnight, silnite, LockRattler, SystHist & Scrub – The Eclectic Light Company and run it when you hear there has been an update.
Hi Al, thank you for your message.
Yes. I’ve checked System Preferences’ App Store tab right now, and the settings are indeed set as you said.
Finder says that the version number of the MRT application (currently in my //System/Library/CoreServices) is 1.35 (created on June 14, 2018, 9:02, and modified today, at 9:50.
Howard Oakley’s SilentKnight app (version 1.1 (2)) complains Gatekeeper is version 135 which should be 173, and MRT is version 1.35 which should be 1.47.
So, my question is: why did Apple fail to update those versions? Security Update 2019-004 certainly updated my system this morning (and did modify the MRT app), and why didn’t it make them “up to date”?
I was in Mojave, so had to reboot to High Sierra to figure out what was going on.
I am able to verify that the version of MRT that comes with Security Update 2019-004 for Sierra is 1.35, and since you had an older version before, it was updated. I have no idea why Apple chose not to include the latest versions. They have a special package included with each update designed to do exactly that. There are several projects that are managed by individual development teams that operate independently of the main macOS engineering team. Examples are Safari, iTunes, MRT, Gatekeeper, XProtect, etc. A separate package called “FullBundleUpdate.pkg” is part of each update with the intent of gathering those disparate items into the update. Again, I don’t know that this was an error or there was some underlying reason for using an older version. I can tell you that it’s not at all unusual as I see it with just about every update.
In my case, I already had version 1.47 and the installer was smart enough not to downgrade it, but I’ve seen that in the past, as well.
What should happen in your case is that within 24 hours, the system should check and bring any of those “system data files and security updates” up to date in the background, as long as your Mac is awake and you are logged in. But judging from what you’ve observed, that probably isn’t going to happen. There is almost certainly something systemically wrong with your setup, but I have no idea what it might be.
So you can either wait 24 hours while logged into your computer to see if the updates take place or if you don’t feel you can wait, use SilentKnight, since you already have it, and if it shows “updates available” for Gatekeeper and MRT, click the “Install all updates” button and be done with it…for now.
This morning (Japan Time), after seeing Agen’s TidBITS Talk message, I let the App Stare app install a newly released
“Security Update 2019-004 High Sierra 10.13.6”, on my iMac running macOS High Sierra 10.13.6.
A week ago, I let it install “Security Update 2019-004”, which updated my iMac to High Sierra 10.13.6 (17G8029).
This morning, after the new update, my iMac says it’s running High Sierra 10.13.6 (17G8030).
Safari was not touched this morning - it had been updated to Safari 12.1.2 (13607.3.10) last week.
According to Howard Oakley’s SilentKnight, even after the new Security Update this morning,
Gatekeeper is still version 135 which should be 173, and MRT is still version 1.35 which should be 1.47.
So, it looks like Apple is still thinking version 1.35 of MRT/Gatekeeper is enough for macOS High Sierra 10.13.6.
P.S.: About an hour ago, I sent this message using a wrong method to Post. Sorry Adam, please disregard the message of mine an hour ago (7:55 AM Japan time), and use this message instead. Mark (Masatsugu) Nagata
It may take up to 24-hours before these background updates occur and your Mac needs to be awake and logged in at the time. I can assure you that SilentKnight is correct in what it is telling you, in that my Gatekeeper and MRT have been updated to the latest versions for Sierra, High Sierra and Mojave. If you don’t receive those updates by this time tomorrow I recommend you use the features of SilentKnight to force the installation of those updates.
Thanks for your suggestion, Al. My iMac was indeed at least 30 hours awake (using the “Disable Screen Saver” screen hot corner overnight) after I saw your message last week, but the situation didn’t change. I think I will wait for Apple to recognize the thing (or rather, will see if/when Apple does it) - I have never used the FaceTime camera anyway, for any kind of communication with the outside world.
If by “Apple” you are referring to macOS, then since it hasn’t noticed by now (and indeed for a very long time according to your earlier observations) it will never happen. If you don’t use SilentKnight to update those two processes, it won’t happen until the next Security Update for High Sierra is released. Again, I must surmise you have a systemic issue of some sort with properly receiving background updates.
Neither MRT nor Gatekeeper have anything to do with your FaceTime camera. That was patched by the Security Update.
MRT removes any accidentally installed malware.
Gatekeeper makes certain that you don’t download anything from the Internet that violates your AppStore settings with respect to signing, causes XProtect to check for a malware installer and to prevent the launch of any app or process who’s DeveloperID has been revoked.
How could we find out / troubleshoot the “systemic issue of some sort with properly receiving background updates”? To me, that’s the central point in this case.
Sorry, but I’ve already covered all the troubleshooting knowledge I have and I’ve been looking into these things ever since I became aware of these updates over eight years ago when XProtect was introduced into OS X 10.6.7. I’ve submitted numerous problem reports to Apple Security when an update failed for me, some of which were eventually fixed. I still have a nagging issue with incomplete App Store updates to Sierra and have found a workaround for that. Unfortunately, that one won’t work for you.
You might be able to detect what is going wrong by using a combination of a Terminal command followed by analysis of your install.log, but that’s probably a long shot, depending on your expertise in that area and the ability of that log to provide useful diagnostic information.
Your situation is unusual, but not totally unheard of. My only suggestions in these cases has been to erase the drive, reinstall the OS with no migration then re-install all apps from source, Finder copy needed user documents and reset all preferences. As far as I know, nobody was willing to take such drastic steps, so I can’t guarantee that even those steps would do the trick.
Still wondering.
Skype, Google Hangouts, or FaceTime, to name a few.