Shulou(Shulou.com)05/31 Report--

This article shows you how Zoom video conferencing software vulnerabilities affect more than 4 million Mac systems. The content is concise and easy to understand. It will definitely make your eyes shine. I hope you can gain something from the detailed introduction of this article.

The authors found two vulnerabilities and a flaw in the ZOOM for Mac client program, which allows Mac users with ZOOM client installed to be vulnerable to RCE attacks, allowing attackers to remotely and unauthorizedly turn on their native cameras.

Zoom is a multi-person cloud video conferencing software that provides users with free cloud video calling services with HD video conferencing and mobile web conferencing capabilities. Users can communicate with their work partners through mobile phones, tablets, PCs, multi-person video and voice calls, screen sharing, meeting reservation management, etc. Zoom supports HD video calls of up to 100 people and is currently the leading mobile video conferencing tool. Zoom works on Windows, Mac, Linux, iOS, Android.

The vulnerability is caused by a bug in the ZOOM for Mac client software, which can be exploited by an attacker deploying code in his own website. When a system user with ZOOM for Mac accesses the website, the vulnerability can be triggered to enable unauthorized camera opening. The vulnerability could affect 750,000 companies worldwide that use Zoom software for daily video conferencing.

CVE Vulnerability Number

CVE-2019-13450: Information Disclosure Vulnerability Caused by Opening Victim System Camera (Unfixed)

CVE-2019-13449: DoS Denial of Service Attack (fixed in ZOOM 4.4.2 client version)

Introduction to vulnerabilities

The vulnerability allows remote unauthorized activation of cameras associated with ZOOM on victim systems by accessing a malicious website and forcing ZOOM client users to join a ZOOM video conference.

In this case, the victim can repeatedly join an invalid video conference, causing a denial of service attack (DoS) with ZOOM client installed. In addition, if a user installs ZOOM client software on your system and then uninstalls it, but it still has a localhost Web service left on your system, ZOOM can perform a complete program reload without any user interaction through this residual service. For now, this so-called "reload" function is still valid.

On Mac, if you install the ZOOM client software, it forms a Web service local to localhost:19421, which you can view in the terminal with the command lsof -i :19421.

First of all, this installation of ZOOM client software, open an API interface without any documentation, at least I think wrong; second, any website I visit may interact with the localhost Web service, which for me to do security, simple is a risk. Here is the code snippet from ZOOM source code that enables locaohost services:

When I looked at the code, I wondered if there was a buffer overflow vulnerability in its parameter processing, which would expose the operating system to RCE attacks. Of course, this was only a guess, and in the end, he did not find such a problem. After visiting a video conference join link, you can observe the behavior of the locaohost service through Chrome debugging tools, as follows:

Later, I also found that the page corresponding to the locaohost service does not execute normal AJAX requests, but it loads an image from the localhost web service running on the local machine. The different size of this loaded image correspond to different states and error codes representing the ZOOM service, as follows:

Terrible is that, judging from the above status and error codes (download, install, upgrade, launch...), The localhost web service not only enables ZOOM video conferencing, as mentioned above, but also reloads ZOOM if the user uninstalls it... Wait a minute.

My question is, why does this localhost web service return encoded data with an image size response? The only reason is that it is to circumvent CORS policy restrictions. However, for the CORS policy of localhost, the browser has completely no restrictions. Chrome, for example, has not restricted CORS requests from localhost since 2010. I suspect that ZOOM is doing this for security reasons, and it seems that this technique may be abused to bypass the CORS strategy. Here, I'll briefly analyze CVE-2019-13450, which opens the victim system camera, CVE-2019-13449, which causes DoS denial of service, and the reload bug that remains after uninstall.

Activating the victim's system camera bug.

I created a ZOOM private meeting natively with different accounts and tested it with Postman to see what the minimum GET request required to start a meeting was. There are a number of random parameters sent to the localhost web service in the analysis, two of which are important:

action=join

confno= whatever the conference number is

By manipulating these two parameters and constructing the following GET request from Postman, I was able to get my computer to join a ZOOM video conference created by another user.

Later, I modified other parameters to see if I could implement other behaviors, but from ZOOM's public documentation and ProtoBuff mechanism, I couldn't find any hidden features that could be exploited, and the native web service didn't have any official instructions to understand. The GET request above can only be used as a small verification POC, which can be used to entice victims to force users to join the meeting. After newly joining the meeting, the default setting of "New Meeting" is to let users choose audio/video to join. I think this is a security vulnerability in itself.

Later, I noticed that Tenable had reported an RCE vulnerability for ZOOM (CVE-2018-15715), which was fully fixed late last year, but if CVE-2018-15715 combined with the vulnerability I discovered, it could have an RCE impact on any Mac system with ZOOM clients installed. As far as my current findings are concerned, I haven't really exploited the code yet. How to activate the victim's system camera is a difficult problem. But when I set up the office video conference, I saw the following interface in ZOOM, that is to say, when setting up the conference, you can choose to let the participants turn on the camera to join the conference:

Select the "Participants: On" button under Video, and other participants will automatically turn on their own cameras to join the meeting as video. That way, I can go on to construct new POCs.

POC

Since the native localhost web service runs in the background, it is practically unnecessary to actually run the target application in the traditional way at all to trap the victim. The first line of POC code forces victims to join the conference:

If you want victims who join the conference to automatically turn on their cameras, you can embed the following video invitation link into the malicious website iframe controlled by the attacker, and the second line of POC code will work:

An attacker simply needs to deploy the above two lines of POC code on a website under his control, and then entice the victim to visit and browse, and the ZOOM client on the victim's Mac system will turn on the camera and join the attacker's pre-set video conference. This POC code can be embedded through malicious advertising, or phishing pages. This vulnerability is still valid. https://jlleitschuh.org/zoom_vulnerability_poc/This is a POC page I constructed that implements mandatory conference participation:

https://jlleitschuh.org/zoom_vulnerability_poc/zoompwn_iframe.html, this POC page enables you to turn on your camera and join my video conference:

DOS denial of service vulnerability

The above vulnerability can also lead to DOS attacks on the victim system. As long as a repeated invalid GET request is sent to the victim, the ZOOM client program in the victim system will repeatedly execute GET requests from the current system. The specific POC is as follows:

// It's actually better if this number isn't a valid zoom number.var attackNumber = "694138052"setInterval(function(){ var image = document.createElement("img"); // Use a date to bust the browser's cache var date = new Date(); image.src = "http://localhost:19421/launch? action=join&confno=" + attackNumber + "&" + date.getTime(); image.onload = function() { // Be tidy, clean up the DOM afterwards image[xss_clean].removeChild(image); }; document.body.appendChild(image);}, 1);

The DOS vulnerability has been fixed in version 4.4.2 of the ZOOM client.

Remains of reload bugs after uninstall

If the user installs the ZOOM client program on the system, the localhost web service mentioned above will be automatically started. Even if the ZOOM program is uninstalled, the localhost web service will still exist and support the reinstallation and update of ZOOM when the subsequent meeting is requested. I decompiled the localhost web service to understand its logic calls. With the help of Hopper Disassemble, I found the following method functions involved in the localhost web service:

This looks like taking parameters from an API request and using it to create a download URL to upgrade an installed ZOOM program. This method function, in turn, is controlled by the following method, which ensures that the download URL comes from a trusted domain name of zoom:

The localhost web service has an API built into it to update and reload current ZOOM programs on Mac, which users can confirm by:

If ZOOM has never been installed on your Mac before, install ZOOM first.

Then open the ZOOM client and close it.

Delete the Applications/zoom.us.app file and put it in the trash, and uninstall the ZOOM program;

Now click on any ZOOM meeting join invite link, and the remaining localhost web service on your system will "kindly" reload the ZOOM program and launch it.

You can see some built-in domain names in the decompiled ZOOM client code, and refer to the links corresponding to these domain names to implement remote update and reload actions from the ZOOM official website, such as zipow.com/upgrade? os=mac：

After these built-in domain names whois, it can be found that the existence of these domain names can be hijacked and exploited. For example, zoomgov.com expires on May 1, 2019. If the ZOOM manufacturer fails to renew the note in time, the attacker may note the domain name as his own, and then host malicious programs to infect users who normally install and uninstall the ZOOM client. Of course, if further exploited, this domain name hijacking risk combined with the vulnerabilities described above would enable RCE attacks in ZOOM client systems. Fortunately, after I reported the vulnerability, ZOOM continued to note this zoomgov.com in time until May 1, 2024.

This is the most basic security breach that should never happen.

In my opinion, there should be no interactive calls between websites and desktop applications, and browsers should implement a basic sandbox program to prevent malicious code from executing on users 'machines.

Because the localhost web service that exists in ZOOM users 'systems can receive HTTP and GET requests, this enables code execution to bypass the browser's native sandbox protection mechanism, leaving ZOOM users in a large attack surface.

Vulnerability escalation process

The author reported the above problems to ZOOM official on March 8,2019. ZOOM promised to fix the vulnerability within 90 days and provide a "quick fix" solution as soon as possible; During this period, after more than 10 rounds of repeated lengthy communication and negotiation, ZOOM finally informed the author that the vulnerability had been fixed on June 21,2019, but in the later July 7 retest process, the author successfully reproduced the remote camera opening vulnerability. In desperation, the author chose to disclose the vulnerability publicly.

Zoom, Google Meet, and Skype for Business are currently the dominant video conferencing apps, with Zoom having more than 40 million users as of 2015, and Zoom's market share has continued to grow since 2015, given that Apple accounts for 10% of the PC market, with at least 4 million of Zoom's users using Mac. Essentially, all of these vulnerabilities pose a serious security threat to Zoom users, but unfortunately Zoom has not been fully fixed within the 90-day grace period, and nearly 4 million Zoom users are now at risk.

What is the Zoom video conferencing software vulnerability that affects more than 4 million Mac systems? Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserves, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.