Detecting MacOS Gatekeeper Bypass (CVE 2021–30657)
Cedric Owens and Patrick Wardle released great research yesterday showcasing a novel method of bypassing MacOS Gatekeeper. I highly recommend reading both articles. Apple patched this vuln yesterday in their updated release of BigSur but have not done so in Catalina or older versions of OSX. It is not clear if they will do so at some point in the future.
**Update (4/28)**: Apple updated their release notes on April 27th indicating this has also been fixed in Catalina (https://support.apple.com/en-us/HT212326)
Both Cedric and Patrick have released suggestions on detection methodologies (Patrick’s scan.py script is a particularly clever way to detect if this has occurred on a host in the past). Cedric’s suggestions on runtime detection mirror exactly what I found below, however, I wanted to break the detection reasoning down in a bit more detail. Most organizations leverage an EDR in some form, so I will start with data that is readily available from those tools.
Methodology
I started by running Patrick’s PoC.app which leverages the gatekeeper bypass to launch Calculator. Looking through process exec logs an interesting pattern caught my eye and started to make sense based on how these “apps” are created. Both Cedric and Patrick mention that to perform this bypass they are embedding bash scripts (not mach-O binaries) in their fake apps.
When launchd creates a child process to run the fake application, it does so by calling “sh” or “bash” and then the “app” which is distinctly different than launchd executing a mach-O binary. Lucky for us, in the logs the fake apps also look much different from how normal mach-O based applications are launched, take a look:
PoC.app
process_command: sh /private/var/folders/z5/[random]/T/AppTranslocation/[random]/d/PoC.app/Contents/MacOS/PoC
FakeApp.app
process_command: bash /private/var/folders/2_/[random]/T/AppTranslocation/[random]/d/FakeApp.app/Contents/MacOS/FakeApp
Google Chrome (or any other normal OSX app)
process_command: Google Chrome
This anti-pattern makes detecting abuse of this vuln fairly simple using just your process exec logs. Searching for a parent process of launchd (which may show up as xpcproxy depending on your logging tool) spawning a child process that begins with a call to a shell or script interpreter:
**Updated (4/28)** 2 updates: Python was added as a potential script interpreter (see below). It was discovered that a legitimate MS updater app launches itself using zsh and launchd as the parent, however, as Cedric mentions as well, the MS updater is not packaged as an “app” and therefor does not contain the directory path “*/Contents/MacOS/*” as a part of it’s file path.
parent_command = “xpcproxy com.apple.xpc.launchd.*” AND child_command = “sh */Contents/MacOS/*” OR “bash */Contents/MacOS/*” OR “zsh */Contents/MacOS/*” OR “python* */Contents/MacOS/*”
Thats it! Based on research JAMF published about Shlayer malware that has been utilizing this technique to bypass Gatekeeper in the wild, it also appears this logic would work in that case, however I have not tested it directly. If you do (or have) I would love to hear about it or any weaknesses to this logic that you uncover.
**Update (4/28)**: Cedric has also successfully PoC’d this technique using python2.7. According to Cedric this vuln could be abused by any scripting language (outside of osascript, which did not launch successfully) assuming the corresponding interpreter is present on the host. Given shell and python2.7 exist by default on OSX it is safe to assume these are the two most likely vectors malware would use.
Mandatory Detection Disclaimer: As with any detection logic your milage may very depending on your environment’s configuration. As always, this is meant to be a starter for potentially finding malicious use of this vuln in your environment, not a silver bullet. Happy hunting!
