Gatekeeper’s Achilles heel: Unearthing a macOS vulnerability

Credit to Author: Microsoft Security Threat Intelligence| Date: Mon, 19 Dec 2022 18:00:00 +0000

On July 27, 2022, Microsoft discovered a vulnerability in macOS that can allow attackers to bypass application execution restrictions imposed by Apple’s Gatekeeper security mechanism, designed to ensure only trusted apps run on Mac devices. We developed a proof-of-concept exploit to demonstrate the vulnerability, which we call “Achilles”. Gatekeeper bypasses such as this could be leveraged as a vector for initial access by malware and other threats and could help increase the success rate of malicious campaigns and attacks on macOS.

After carefully reviewing the implications, we shared the vulnerability with Apple in July 2022 through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Fixes for the vulnerability, now identified as CVE-2022-42821, were quickly released by Apple to all their OS versions. We note that Apple’s Lockdown Mode, introduced in macOS Ventura as an optional protection feature for high-risk users that might be personally targeted by a sophisticated cyberattack, is aimed to stop zero-click remote code execution exploits, and therefore does not defend against Achilles. End-users should apply the fix regardless of their Lockdown Mode status. We thank Apple for the collaboration in addressing this issue.

In this blog post, we share information about Gatekeeper and the vulnerability able to bypass it. We also share this research to emphasize the importance of collaboration among researchers and the security community to improve defenses for the larger ecosystem.

Unlocking the Gatekeeper security mechanism

Many macOS infections are the result of users running malware, oftentimes inadvertently. Fake app bundles might masquerade themselves as different apps, like Flash Player, or as a legitimate file, such as using a PDF icon and using the app name “Resume”. To combat this highly popular infection vector, Apple has imposed strong security mechanisms. When downloading apps from a browser, like Safari, the browser assigns a special extended attribute to the downloaded file. That attribute is named com.apple.quarantine and is later used to enforce policies such as Gatekeeper or certain mitigations that prevent sandbox escapes. In recent years, Apple has tightened the security policies even further, and the current Gatekeeper design dictates the following behavior for downloaded apps:

1. If the app is validly signed and notarized, meaning approved by Apple, then a prompt requires the user’s consent before its launched.
2. Otherwise, the user is informed that the app cannot be run as it’s untrusted.

Extended attributes are a filesystem feature supported on common macOS filesystems, like APFS and HFS+, and their main purpose is to save file metadata. Specifically, the com.apple.quarantine attribute saves information regarding the source of the downloaded file, as well as data instructing Gatekeeper how to process the file. The attribute format is generally:

flag;date;agent_name;UUID

Extended attributes can be viewed or modified with the xattr command line utility.

A flag value of “0083” enforces Gatekeeper restrictions on the file, as displayed below:

Due to its essential role in stopping malware on macOS, Gatekeeper is a helpful and effective security feature. However, considering there have been numerous bypass techniques targeting the security feature in the past, Gatekeeper is not bulletproof. Gaining the ability to bypass Gatekeeper has dire implications as sometimes malware authors leverage those techniques for initial access.

Historical overview of Gatekeeper bypasses

Numerous Gatekeeper bypasses have been identified in the past years, some even abused by malware families such as Shlayer. When examining Gatekeeper bypasses from recent years, we see two approaches:

1. Misuse the com.apple.quarantine extended attribute assignment.
2. Find a vulnerability in the components that enforce policy checks on quarantined files.

Two cases that we don’t consider to constitute a “true” Gateway bypass are:

1. Using unsupported filesystems, like a USB mass storage device using FAT32, as these require non-trivial user interaction to run macOS applications.
2. MITRE’s definition of “Gatekeeper Bypass” (T1553.001), which requires code execution to forcefully modify or remove the com.apple.quarantine extended attribute.

Here are some examples of Gatekeeper bypass vulnerabilities discovered over the last several years:

Vulnerability	Exploits	Description
CVE-2022-22616	Assignment of the quarantine attribute.	Gzip files archived in BOM archives are not assigned with the quarantine extended attribute, further detailed here.
CVE-2021-1810	Assignment of the quarantine attribute.	Paths longer than 886 characters were not assigned with extended attributes. Therefore, creating a symbolic link that points to an app that resides in a long path results in a Gatekeeper bypass. Since symbolic links are not assigned with the quarantine attribute, it was possible to completely bypass Gatekeeper, as outlined here.
CVE-2021-30657	Component(s) that enforce policy checks.	App bundles with a missing Info.plist and a shell script main executable component are treated incorrectly by syspolicyd, a component that enforces policy restrictions on apps. Writeups can be found here and here.
CVE-2021-30853	Component(s) that enforce policy checks.	A security bug in the way files with a “Shebang” (#!) header are interpreted by syspolicyd cause it to consider the app bundle to be safe, as detailed here.
CVE-2019-8656	Assignment of the quarantine attribute.	Since symbolic links are not assigned with the quarantine extended attribute, an archive that contains a symbolic link to an app that resides in an external filesystem (NFS) results in a Gatekeeper bypass. Apple fixed the issue by blocking the execution of applications from remote shared locations, documented here.
CVE-2014-8826	Component(s) that enforce policy checks.	Quarantine attributes are not checked for JAR files, which are run by Java, as summarized here.

Metadata persistence over AppleDouble

Intrigued by CVE-2021-1810, as listed in the above table, we wondered what mechanism could be leveraged in archives. Considering symbolic links are preserved in archives and aren’t assigned with quarantine attributes—we looked for a mechanism that could persist different kinds of metadata over archives.

After some investigation, we discovered a way to persist important file metadata through a mechanism called AppleDouble.

Even though extended attributes are common on different filesystems, they might be implemented differently or even not supported, so copying files with their metadata becomes a challenging task. To solve this problem, back in 1994, Apple introduced the concept of AppleSingle and AppleDouble formats. In a nutshell, AppleSingle is a binary blob that is added as a part of the original file contents so that there’s only a “single” file to process, whereas AppleDouble saves the metadata in a different file side-by-side next to the original file, with a “._” prefix.

Interestingly, when extracting an archive, macOS processes any attached AppleDouble file and assigns the target file with the appropriate metadata.

The AppleDouble binary file format is quite complicated, but the code that parses it can be read in the XNU git repository in the file that handles extended attributes, which also includes ASCII-art depiction of the format. To demonstrate the AppleDouble file information, we used the ditto utility as such:

When the file is archived alongside its original file and then extracted by macOS, extended attributes are fully restored, as demonstrated here:

Using this newfound knowledge, we examined how we could use the AppleDouble mechanism to trick Gatekeeper in some way.

Our first approach was to generate many large extended attributes in the AppleDouble format such that there won’t be enough space to assign the com.apple.quarantine extended attribute. Interestingly, it doesn’t work—AppleDouble is ignored if the overall size is over 2 GB, and there is no limitation on the number of extended attributes a file could get (besides the size of the disk).

Researching further, we decided to examine the source code of the unarchiving mechanism. Carefully studying the copyfile_unpack implementation, we discovered an option for a special extended attribute named com.apple.acl.text (saved in the XATTR_SECURITY_NAME constant in the source code), which is used to set arbitrary Access Control Lists.

Using ACLs for exploitation

Access Control Lists (ACLs) are a mechanism in macOS that further extends the traditional permission model. The traditional permission model saves permission for each file in a file “mode”, which can be changed by using the chmod utility. It enforces permissions on the owning user, owning group, and others in terms of reading (r), writing (w) and launching (x). A file’s mode can be viewed by listing files with the “-l” (long) flag:

Unlike the traditional permission mechanism, ACLs allow fine-grained permissions to files and directories. Each ACL has one or more Access Control Entries (ACEs) that dictate what each principal can or cannot do, much like firewall rules. Like the file mode, ACLs can be modified with the chmod utility and viewed with the ls utility. It’s important to note that file access checks are dictated by both ACLs and the traditional permission model mechanisms, as demonstrated by the following example:

The set of authorizations supported by ACLs is well-documented by Apple in the chmod manual, which contain more than the traditional reading, writing, or launching abilities, including:

• writeattr: controls the ability to write attributes to the file
• writeextattr: controls the ability to write extended attributes to the file
• writesecurity: controls the ability to set ACLs to the file
• chown: controls the ability to set the owner of the file
• delete: controls the ability to delete the file

Equipped with this information, we decided to add very restrictive ACLs to the downloaded files. Those ACLs prohibit Safari (or any other program) from setting new extended attributes, including the com.apple.quarantine attribute.

Two minor challenges that we had to overcome during the proof-of-concept (POC) development were:

• The format of the ACL text as saved in the AppleDouble file isn’t identical to the format of the chmod command line. This can easily be overcome by invoking the macOS acl_to_text API and saving the ACL with the correct format.
• When using the ditto utility, the com.apple.acl.text extended attribute is lost in the resulting AppleDouble file. This can be overcome by either manually creating the binary AppleDouble or, as we chose in this case, simply patching the resulting AppleDouble file before archiving it.

Therefore, our POC is as follows:

1. Create a fake directory structure with an arbitrary icon and payload.
2. Create an AppleDouble file with the com.apple.acl.text extended attribute key and a value that represents a restrictive ACL (we chose the equivalent of “everyone deny write,writeattr,writeextattr,writesecurity,chown”). Perform the correct AppleDouble patching if using ditto to generate the AppleDouble file.
3. Create an archive with the application alongside its AppleDouble file and host it on a web server.

We named our POC exploit Achilles after its use of ACLs to bypass Gatekeeper. Our POC recorded video can be viewed here:

The AppleDouble file we used for this Gatekeeper bypass can be generated, as displayed below:

Improving security for all through research and threat intelligence sharing

The threat landscape continues to evolve, delivering new threats and attack capabilities that take advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems and data. Our data shows that fake apps remain one of the top entry vectors on macOS, indicating Gatekeeper bypass techniques are an attractive and even a necessary capability for adversaries to leverage in attacks. Nonetheless, through research-driven protections and collaboration with customers, partners, and industry experts, we strive to enrich our protection technologies to defend against such issues—regardless of the platform or device in use.

As environments continue to rely on a diverse range of devices and operating systems, organizations need security solutions that can provide protection across platforms and a complete picture of their security posture. Collaborative research such as this informs our comprehensive protection capabilities across platforms, allowing Microsoft Defender for Endpoint to deliver and coordinate threat defense across all major OS platforms including Windows, macOS, Linux, Android, and iOS. On macOS devices, Microsoft Defender for Endpoint detects and exposes threats and vulnerabilities, including CVE-2022-42821, using antivirus, endpoint detection and response (EDR), and threat and vulnerability management capabilities. This research also improved Microsoft Defender’s Vulnerability Management capabilities to discover, prioritize, and remediate misconfigurations and vulnerabilities. This includes detecting CVE-2022-42821 on macOS devices by examining AppleDouble files misusing ACLs.

This case also emphasized the need for responsible vulnerability disclosures and expert, cross-platform collaboration to effectively mitigate issues, protecting users against present and future threats. We wish to again thank the Apple product security team for their efforts and responsiveness in addressing the issue.

Our Microsoft security researchers continue to discover new threats and vulnerabilities as part of our effort to secure users’ computing experiences, be it a Windows or non-Windows device. In the effort to improve security for all, we will continue to share intelligence and work with the security community to create and improve upon solutions that protect users and organizations across platforms every single day.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Gatekeeper’s Achilles heel: Unearthing a macOS vulnerability appeared first on Microsoft Security Blog.

https://blogs.technet.microsoft.com/mmpc/feed/