macOS Gatekeeper / Quarantine / XProtect
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gatekeeper is a security feature developed for Mac operating systems, designed to ensure that users run only trusted software on their systems. It functions by validating software that a user downloads and attempts to open from sources outside the App Store, such as an app, a plug-in, or an installer package.
The key mechanism of Gatekeeper lies in its verification process. It checks if the downloaded software is signed by a recognized developer, ensuring the software's authenticity. Further, it ascertains whether the software is notarised by Apple, confirming that it is devoid of known malicious content and has not been tampered with after notarisation.
Additionally, Gatekeeper reinforces user control and security by prompting users to approve the opening of downloaded software for the first time. This safeguard helps prevent users from inadvertently running potentially harmful executable code that they may have mistaken for a harmless data file.
Application signatures, also known as code signatures, are a critical component of Apple's security infrastructure. They're used to verify the identity of the software author (the developer) and to ensure that the code hasn't been tampered with since it was last signed.
Here's how it works:
Signing the Application: When a developer is ready to distribute their application, they sign the application using a private key. This private key is associated with a certificate that Apple issues to the developer when they enrol in the Apple Developer Program. The signing process involves creating a cryptographic hash of all parts of the app and encrypting this hash with the developer's private key.
Distributing the Application: The signed application is then distributed to users along with the developer's certificate, which contains the corresponding public key.
Verifying the Application: When a user downloads and attempts to run the application, their Mac operating system uses the public key from the developer's certificate to decrypt the hash. It then recalculates the hash based on the current state of the application and compares this with the decrypted hash. If they match, it means the application hasn't been modified since the developer signed it, and the system permits the application to run.
Application signatures are an essential part of Apple's Gatekeeper technology. When a user attempts to open an application downloaded from the internet, Gatekeeper verifies the application signature. If it's signed with a certificate issued by Apple to a known developer and the code hasn't been tampered with, Gatekeeper permits the application to run. Otherwise, it blocks the application and alerts the user.
Starting from macOS Catalina, Gatekeeper also checks whether the application has been notarized by Apple, adding an extra layer of security. The notarization process checks the application for known security issues and malicious code, and if these checks pass, Apple adds a ticket to the application that Gatekeeper can verify.
When checking some malware sample you should always check the signature of the binary as the developer that signed it may be already related with malware.
Apple's notarization process serves as an additional safeguard to protect users from potentially harmful software. It involves the developer submitting their application for examination by Apple's Notary Service, which should not be confused with App Review. This service is an automated system that scrutinizes the submitted software for the presence of malicious content and any potential issues with code-signing.
If the software passes this inspection without raising any concerns, the Notary Service generates a notarization ticket. The developer is then required to attach this ticket to their software, a process known as 'stapling.' Furthermore, the notarization ticket is also published online where Gatekeeper, Apple's security technology, can access it.
Upon the user's first installation or execution of the software, the existence of the notarization ticket - whether stapled to the executable or found online - informs Gatekeeper that the software has been notarized by Apple. As a result, Gatekeeper displays a descriptive message in the initial launch dialog, indicating that the software has undergone checks for malicious content by Apple. This process thereby enhances user confidence in the security of the software they install or run on their systems.
Note that from Sequoia version, spctl doesn't allow to modify Gatekeeper configuration anymore.
spctl is the CLI tool to enumerate and interact with Gatekeeper (with the syspolicyd daemon via XPC messages). For example, it's possible to see the status of GateKeeper with:
Note that GateKeeper signature checks are performed only to files with the Quarantine attribute, not to every file.
GateKeeper will check if according to the preferences & the signature a binary can be executed:
syspolicyd is the main daemon responsible to enforcing Gatekeeper. It maintains a database located in /var/db/SystemPolicy and it's possible to find the code to support the database here and the SQL template here. Note that the database is unrestricted by SIP and writable by root and the database /var/db/.SystemPolicy-default is used as an original backup in case the other gets corrupted.
Moreover, the bundles /var/db/gke.bundle and /var/db/gkopaque.bundle contains files with rules that are inserted in the database. You can check this database as root with:
syspolicyd also exposes a XPC server with different operations like assess, update, record and cancel which are also reachable using Security.framework's SecAssessment* APIs and xpctl actually talks to syspolicyd via XPC.
Note how the first rule ended in "App Store" and the second one in "Developer ID" and that in the previous imaged it was enabled to execute apps from the App Store and identified developers. If you modify that setting to App Store, the "Notarized Developer ID" rules will disappear.
There are also thousands of rules of type GKE :
These are hashes that from:
/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth
/var/db/gke.bundle/Contents/Resources/gk.db
/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db
Or you could list the previous info with:
The options --master-disable and --global-disable of spctl will completely disable these signature checks:
When completely enabled, a new option will appear:
It's possible to check if an App will be allowed by GateKeeper with:
It's possible to add new rules in GateKeeper to allow the execution of certain apps with:
Regarding kernel extensions, the folder /var/db/SystemPolicyConfiguration contains files with lists of kexts allowed to be loaded. Moreover, spctl has the entitlement com.apple.private.iokit.nvram-csr because it's capable of adding new pre-approved kernel extensions which need to be saved also in NVRAM in a kext-allowed-teams key.
Upon downloading an application or file, specific macOS applications such as web browsers or email clients attach an extended file attribute, commonly known as the "quarantine flag," to the downloaded file. This attribute acts as a security measure to mark the file as coming from an untrusted source (the internet), and potentially carrying risks. However, not all applications attach this attribute, for instance, common BitTorrent client software usually bypasses this process.
The presence of a quarantine flag signals macOS's Gatekeeper security feature when a user attempts to execute the file.
In the case where the quarantine flag is not present (as with files downloaded via some BitTorrent clients), Gatekeeper's checks may not be performed. Thus, users should exercise caution when opening files downloaded from less secure or unknown sources.
Checking the validity of code signatures is a resource-intensive process that includes generating cryptographic hashes of the code and all its bundled resources. Furthermore, checking certificate validity involves doing an online check to Apple's servers to see if it has been revoked after it was issued. For these reasons, a full code signature and notarization check is impractical to run every time an app is launched.
Therefore, these checks are only run when executing apps with the quarantined attribute.
This attribute must be set by the application creating/downloading the file.
However, files that are sandboxed will have this attribute set to every file they create. And non sandboxed apps can set it themselves, or specify the LSFileQuarantineEnabled key in the Info.plist which will make the system set the com.apple.quarantine extended attribute on the files created,
Moreover, all files created by a process calling qtn_proc_apply_to_self are quarantined. Or the API qtn_file_apply_to_path adds the quarantine attribute to a specified file path.
It's possible to check it's status and enable/disable (root required) with:
You can also find if a file has the quarantine extended attribute with:
Check the value of the extended attributes and find out the app that wrote the quarantine attr with:
Actually a process "could set quarantine flags to the files it creates" (I already tried to apply the USER_APPROVED flag in a created file but it won't apply it):
And remove that attribute with:
And find all the quarantined files with:
Quarantine information is also stored in a central database managed by LaunchServices in ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 which allows the GUI to obtain data about the file origins. Moreover this can be overwritten by applications which might be interested in hiding its origins. Moreover, this can be done from LaunchServices APIS.
This library exports several functions that allow to manipulate the extended attribute fields.
The qtn_file_* APIs deal with file quarantine policies, the qtn_proc_* APIs are applied to processes (files created by the process). The unexported __qtn_syscall_quarantine* functions are the ones that applies the policies which calls mac_syscall with "Quarantine" as first argument which sends the requests to Quarantine.kext.
The kernel extension is only available through the kernel cache on the system; however, you can download the Kernel Debug Kit from https://developer.apple.com/, which will contain a symbolicated version of the extension.
This Kext will hook via MACF several calls in order to traps all file lifecycle events: Creation, opening, renaming, hard-linkning... even setxattr to prevent it from setting the com.apple.quarantine extended attribute.
It also uses a couple of MIBs:
security.mac.qtn.sandbox_enforce: Enforce quarantine along Sandbox
security.mac.qtn.user_approved_exec: Querantined procs can only execute approved files
XProtect is a built-in anti-malware feature in macOS. XProtect checks any application when it's first launched or modified against its database of known malware and unsafe file types. When you download a file through certain apps, such as Safari, Mail, or Messages, XProtect automatically scans the file. If it matches any known malware in its database, XProtect will prevent the file from running and alert you to the threat.
The XProtect database is updated regularly by Apple with new malware definitions, and these updates are automatically downloaded and installed on your Mac. This ensures that XProtect is always up-to-date with the latest known threats.
However, it's worth noting that XProtect isn't a full-featured antivirus solution. It only checks for a specific list of known threats and doesn't perform on-access scanning like most antivirus software.
You can get information about the latest XProtect update running:
XProtect is located on. SIP protected location at /Library/Apple/System/Library/CoreServices/XProtect.bundle and inside the bundle you can find information XProtect uses:
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist: Allows code with those cdhashes to use legacy entitlements.
XProtect.bundle/Contents/Resources/XProtect.meta.plist: List of plugins and extensions that are disallowed to load via BundleID and TeamID or indicating a minimum version.
XProtect.bundle/Contents/Resources/XProtect.yara: Yara rules to detect malware.
XProtect.bundle/Contents/Resources/gk.db: SQLite3 database with hashes of blocked applications and TeamIDs.
Note that there is another App in /Library/Apple/System/Library/CoreServices/XProtect.app related to XProtect that isn't involved with the Gatekeeper process.
Note that Gatekeeper isn't executed every time you execute an application, just AppleMobileFileIntegrity (AMFI) will only verify executable code signatures when you execute an app that has been already executed and verified by Gatekeeper.
Therefore, previously it was possible to execute an app to cache it with Gatekeeper, then modify not executables files of the application (like Electron asar or NIB files) and if no other protections were in place, the application was executed with the malicious additions.
However, now this is not possible because macOS prevents modifying files inside applications bundles. So, if you try the Dirty NIB attack, you will find that it's not longer possible to abuse it because after executing the app to cache it with Gatekeeper, you won't be able to modify the bundle. And if you change for example the name of the Contents directory to NotCon (as indicated in the exploit), and then execute the main binary of the app to cache it with Gatekeeper, it will trigger an error and won't execute.
Any way to bypass Gatekeeper (manage to make the user download something and execute it when Gatekeeper should disallow it) is considered a vulnerability in macOS. These are some CVEs assigned to techniques that allowed to bypass Gatekeeper in the past:
It was observed that if the Archive Utility is used for extraction, files with paths exceeding 886 characters do not receive the com.apple.quarantine extended attribute. This situation inadvertently allows those files to circumvent Gatekeeper's security checks.
Check the original report for more information.
When an application is created with Automator, the information about what it needs to execute is inside application.app/Contents/document.wflow not in the executable. The executable is just a generic Automator binary called Automator Application Stub.
Therefore, you could make application.app/Contents/MacOS/Automator\ Application\ Stub point with a symbolic link to another Automator Application Stub inside the system and it will execute what is inside document.wflow (you script) without triggering Gatekeeper because the actual executable doesn't have the quarantine xattr.
Example os expected location: /System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
Check the original report for more information.
In this bypass a zip file was created with an application starting to compress from application.app/Contents instead of application.app. Therefore, the quarantine attr was applied to all the files from application.app/Contents but not to application.app, which is was Gatekeeper was checking, so Gatekeeper was bypassed because when application.app was triggered it didn't have the quarantine attribute.
Check the original report for more information.
Even if the components are different the exploitation of this vulnerability is very similar to the previous one. In this case with will generate an Apple Archive from application.app/Contents so application.app won't get the quarantine attr when decompressed by Archive Utility.
Check the original report for more information.
The ACL writeextattr can be used to prevent anyone from writing an attribute in a file:
Moreover, AppleDouble file format copies a file including its ACEs.
In the source code it's possible to see that the ACL text representation stored inside the xattr called com.apple.acl.text is going to be set as ACL in the decompressed file. So, if you compressed an application into a zip file with AppleDouble file format with an ACL that prevents other xattrs to be written to it... the quarantine xattr wasn't set into de application:
Check the original report for more information.
Note that this could also be be exploited with AppleArchives:
It was discovered that Google Chrome wasn't setting the quarantine attribute to downloaded files because of some macOS internal problems.
AppleDouble file formats store the attributes of a file in a separate file starting by ._, this helps to copy dile attributes across macOS machines. However, it was noticed that after decompressing an AppleDouble file, the file starting with ._ wasn't given the quarantine attribute.
Being able to create a file that won't have the quarantine attribute set, it was possible to bypass Gatekeeper. The trick was to create a DMG file application using the AppleDouble name convention (start it with ._) and create a visible file as a sym link to this hidden file without the quarantine attribute.
When the dmg file is executed, as it doesn't have a quarantine attribute it'll bypass Gatekeeper.
Create a directory containing an app.
Add uchg to the app.
Compress the app to a tar.gz file.
Send the tar.gz file to a victim.
The victim opens the tar.gz file and runs the app.
Gatekeeper does not check the app.
In an ".app" bundle if the quarantine xattr is not added to it, when executing it Gatekeeper won't be triggered.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
