Good Apps Behaving Badly: Dissecting Zoom’s macOS Installer Workaround

This post was updated on April 3, 2020 to reflect Zoom’s response.

It seems like overnight half the world switched to working from home and depending on Zoom for daily human interaction. Our own team is no exception, so it came as a surprise that the widely-used application installs itself on Macs by working around Apple’s regular security, demonstrating behavior commonly associated with malware.

In a clear case of “good apps behaving badly”, I noted in my original Twitter post that Zoom’s Mac app installer uses pre-installation scripts and displays a password dialog pretending to be an OS prompt.

 


In a follow-up post, I wrote:

 

 

 

The post has received over 3,000 retweets and prompted the CEO of Zoom to respond:


Below is a step-by-step technical description of what is happening:

  • Zoom uses the pkg format to distribute their client on macOS. PKGs are a well-known installer format, similar to MSI on Windows.
  • When users join a meeting, they are prompted to download and run the software
  • Usually, pkg installers contain multiple pages where users can customize and confirm the installation
  • The Zoom installer skips these additional steps and instead runs “pre-requirement” scripts, which are usually meant to be run before the installation to check if the software is compatible with the machine
  • macOS warns the user before running the “pre-requirement” script, but since the message only says that it “will determine if the software can be installed”, the user will most likely click Continue, not knowing that this already starts the installation

Zoom Installer

    • Instead of only doing pre-installation checks, the Zoom installer performs the whole installation as part of the script
    • The installer comes with a bundled version of 7zip which is then used to extract the Payload
    • If the user is part of the “admin” group, which is in most cases true if the user is not restricted by the company’s IT department, elevated rights (“root”) are not required to install an application to the default /Applications directory
    • In that case, the script copies the extracted client into /Applications, does some cleanup and is essentially done
    • If the user does not have the appropriate rights to write into /Applications and the Zoom client is not installed already, it will be copied to the local application directory at /Users//Applications

 

Applications - Zoom Client Not Installed

 

  • Finally, there is a very interesting third case: if the client is already installed in /Applications but the current user does not have the appropriate right to update it, the script will launch a helper tool called “zoomAutenticationTool”(sic) which is also bundled as part of the PKG

“zoomAutenticationTool”(sic)

VMRay Analyzer Report showing the execution of the “zoomAutenticationTool”(sic).

VMRay Analyzer Report showing the execution of the “zoomAutenticationTool”(sic).

 

  • This tool uses the infamous and deprecated AuthorizationExecuteWithPrivileges() system API to display a password prompt in order to run the also bundled “runwithroot” script with root privileges

System Privileges

The AuthorizationExecuteWithPrivileges API Call shown in the VMRay Function Log.

 

It is not uncommon for macOS applications to temporarily request root privileges, for example, to install a persistent service or start a privileged helper-tool. However, in this case, the Zoom installer actively overrides the message that is shown in the password prompt. Instead of displaying a message along the lines of “Zoom needs your password to update the existing Application”, they use the string “System need your privilege to change”(sic). This leaves the impression that the OS is requesting the user’s password while it is actually the Zoom installer.

The stated reasoning behind this practice according to the Zoom CEO is that they want to reduce the number of clicks from download to getting the client running. However, this is done by abusing the pre-requirements scripts. The user does not need to click through the installer, it just happens instantly.

While this practice is nice from Zoom’s perspective and for usability, it violates Mac user expectations. If a Mac user opens a pkg file, they expect to click through it and give their consent before installation. Instead, Zoom performs this operation instantly without another confirmation. An analogy would be like putting car keys into the ignition, but instead of only the radio and the engine starting up, the car starts driving on its own.

The second and more severe problem is the password prompt. There is no need to fake this message, rather than explicitly state what operations Zoom is performing. Instead, Zoom impersonates the system and attempts to “social-engineer” the user into entering his password. We should note that Zoom doesn’t capture the plaintext password, just the “authorization” from the OS to execute something as root.

This is a shady practice that is already in use by actual macOS malware samples (for example Coldroot and Proton) which often pretend to be an Apple process or completely fake the password prompt. Zoom “promoting” this questionable technique conditions users to blindly enter their password into any dialog that pops up and makes it easier for malware authors to dupe them.

It should be noted PKG files are a popular distribution format for adware on macOS and our upcoming v3.3 VMRay Analyzer release supports the analysis of these files. VMRay extracts all pre and post-install scripts that are embedded into the PKG but not part of the actual Payload. In the files tab of the VMRay Analyzer Report, you can see that there are additional files that are being executed before installation. In the dynamic analysis, we see 7zip and all the behavior described above.

 

 

While we understand Zoom’s position in wanting to reduce the number of clicks during installation, increased usability should not promote bad security practices and resort to lying to the user. There was no ill-intent associated with this behavior but it is a bad practice for one of the most widely used applications in the world. As one Twitter user noted:

View the VMRay Analyzer Report (v3.3 Pre-Release) for the Zoom macOS Installer

UPDATEApril 3, 2020

This blog post about Zoom has gained some notable media coverage, including a write-up and link in the Washington Post and Forbes. The original tweet now has over 4,000 retweets and 8,000 likes.

The increased press coverage triggered a longer reply from the CEO of Zoom. In a posting on the company website, he writes:

“To put [Zoom’s] growth in context, as of the end of December last year, the maximum number of daily meeting participants, both free and paid, conducted on Zoom was approximately 10 million. In March this year, we reached more than 200 million daily meeting participants, both free and paid.”

During this rapid growth, he acknowledged “we have fallen short of the [community’s] privacy and security expectations. For that, I am deeply sorry.”

Over the next 90 days, he writes, the company will:

  • Immediately enact a feature freeze and shift all engineering resources to focus on trust, safety, and privacy issues
  • Conduct a comprehensive review with third-party experts and representative users to ensure the security of all new consumer use cases
  • Prepare a transparency report that details information related to requests for data, records, or content
  • Enhance the current bug bounty program

These all sound like good efforts to us here at VMRay and we commend Zoom for making them. As a post-script, Zoom pushed out in short order an updated installer that addressed the issues we raised.