Software installers are a critical part of every organization’s software deployment. Installers are complex and often misunderstood, as vendors will commonly build an installer and touch it as little as possible. Sometimes that results in unexpected consequences and security issues.

One such issue is the use of the AuthorizationExecuteWithPrivileges API. It has long been deprecated by Apple, who clearly articulates its inherent security risks. These risks have been highlighted at conference talks and in media for years.

https://developer.apple.com/documentation/security/1540038-authorizationexecutewithprivileg

Unfortunately, the more secure alternatives to this API (such as SMJobBless) are quite cumbersome and often require application design changes. This is a steep price to pay for simply wanting to execute a task as an administrator after prompting the user for credentials. The security implications of not getting the usage correct on this deprecated API, however, are real.

The most recent example of the misuse of this API was brought to light by the well-known security researcher, Felix Seele (of VMRay). Felix noted that the Zoom installer took some rather obscure and non-traditional steps during its installation and upgrade process.

In a blog post titled “Good Apps Behaving Badly: Zoom macOS Installer”, VMRay detailed the ways in which Zoom’s installer package did not meet macOS user expectations by employing misleading techniques in the name of reducing user friction.

Zoom’s use of AuthorizationExecuteWithPrivileges was the latest case study highlighting the continued use of this insecure API. In past blog posts and presentations it has been repeatedly demonstrated that an existing (local) malicious application with limited permissions can abuse improper use of the API to elevate its own permissions to root.

So, what can I do to keep my users safe?

Practically speaking, while the Zoom installer employed problematic practices, it posed a limited threat surface, given the attacker already required local code execution to take advantage of the privilege escalation.

Additionally, Zoom released a message to their users this morning outlining their approach to this and other security concerns that have been raised in recent days.

To their credit, in a matter of days they have:

• Released security-related fixes for their Windows and macOS clients/installers
• Enacted a feature freeze to focus on safety/privacy issues
• Pledged to engage in pen-tests and improve their bug bounty program

This is a great response to these issues. They are clearly taking the reported issues seriously and re-focusing their efforts on privacy and security to ensure that their expanding user base is protected.

That said, we’d recommend the following mitigations for enterprise IT admins using Zoom or other tools that may utilize these deprecated APIs:

• Ensure you use the latest macOS installers for the tool for deployments and upgrades. For Zoom, at time of this publication, is Version 4.6.9 (19273.0402).
• Enforce single sign-on (SSO) and if available, use conditional access to ensure that the device meets a security baseline before allowing the installation to occur.
• The old adage of “patch early, patch often” still applies. For the Zoom situation, inspect your device inventory to ensure that all Zoom macOS clients are updated appropriately.
• For any future problematic installers, admins can leverage tools such as Jamf Composer to repackage installers.

For IT/InfoSec professionals that want to monitor vulnerable use of the AuthorizationExecuteWithPrivileges API, you should enlist the help of your EPP/EDR. Specifically:

• Look for processes executed by security_authtrampoline (macOS helper binary for AuthorizationExecuteWithPrivileges) that are not owned by root, or
• Monitor for process invocation of security_authtrampoline where the first argument is either a relative path, or not owned by root.

Jamf Protect users can inspect the results of the ‘UserElevatedAction’ analytic to get a view of all security_authtrampoline usage in their environment, and be on the lookout for our latest analytic(s) that will provide more focus on insecure usage such as discussed above.

And finally, if you are a developer, please closely examine your use of this API and move away from it wherever possible.

For more information on how we can help, please go here.