In short, unsigned, non-notarized script-based applications would be allowed if their script did *not* specify an interpreter! 🤯🤣
Meaning attackers could trivially bypass a myriad of foundational macOS security mechanisms via:
#!
<any malicious commands>
The issue begins in user-mode, where xpcproxy invokes posix_spawnp to launch the interpreter-less script-based application.
This initially errors out (no interpreter → ENOEXEC), but then posix_spawnp "recovers" and (re)executes the script ...this time directly via /bin/sh:
Later, the AppleSystemPolicy kext intercepts the process launch to ensure its conformant (signed, notarized, etc).
But now it's looking at /bin/sh without "hey I'm really executing a script" variables set.
...so execution of the malicious script is inadvertently allowed! 🤦♂️
This is 2nd bug abusing script-based apps to bypass Gatekeeper et. al. (The other being CVE-2021-30657 objective-see.com/blog/blog_0x64…).
Though Apple is struggling to secure macOS, BlockBlock (objective-see.com/products/block…) provided protection with no a priori knowledge of this new flaw 🤩
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The majority of Mac infections are "user-assisted", which Apple combats via:
✅Notarization
✅Gatekeeper
✅File Quarantine
...these have proven problematic for attackers
But oops, this bug sidesteps all, allowing unsigned (unnotarized) items to be launched ...with no alerts!😭
Q: Can our free open-source tools protect you ...with no a priori knowledge of this insidious threat?
When the malicious script in the infected Xcode project is executed and attempts to connect to the attacker's remote C&C server for tasking (via /bin/bash), LuLu will intercept this, and alert you:
If we allow the malicious payload (EggShell), to be downloaded from the server ....when it attempts to persistently install itself as a Launch Agent, BlockBlock will alert you: