Code Signing Flaw Affects all Mac OS Versions Since 2005

Okta Rex (Research and Exploitation) researcher Josh Pitts has discovered a method of exploiting the code signing mechanism in MacOS. If exploited, the flaw could allow malicious untrusted code to masquerade as legitimate trusted code and bypass checks by other security software.

Code signing attacks are not new. However, writes Pitts in public disclosure published today, “Unlike some of the prior work, this current vulnerability does not require admin access, does not require JITíing code, or memory corruption to bypass code signing checks. All that is required is a properly formatted Fat/Universal file and code signing checks return valid.” Any Mac operating system since the 2005 introduction of OS X Leopard is vulnerable to this flaw.

Code signing works by cryptographically confirming that new code is authentic and not malicious code authored by a bad actor impersonating the original developer. While almost anything, from binaries to PowerShell scripts, can be signed on Windows, on MacOS code signing focuses on the Mach-O binary and application bundles to ensure only trusted code is executed in memory.

“Security, incident response, and forensics processes and personnel use code signing to weed out trusted code from untrusted code,” explains Pitts. “By verifying signed code, detection and response personnel can speed up investigations by separating trusted code from untrusted code.”

Pitts discovered, however, that the code signing mechanism in MacOS can be manipulated. All it requires is access to a genuinely signed Fat/Universal file. Other conditions require that the first Mach-O in the file must be validly signed by Apple; the added malicious code must be adhoc signed and i386 compiled for an x86_64 bit target macOS; and the CPU_TYPE in the Fat header must be set to an invalid type or CPU Type that is not native to the host chipset.

Okta Rex told SecurityWeek that this technique bypasses the gambit of whitelisting, incident response, and process inspection solutions by appearing to be signed by Apple’s own root certificate.

The simple explanation is that the mechanism accepts the Apple signing, but skips this code and executes the malicious code. “By setting the CPU_Type to an invalid type or valid not native CPU type (example: PPC), the Mach-O loader will skip over the validly signed Mach-O binary and execute the malicious (non-Apple signed) code,” writes the researcher.

In effect, the good code is skipped because CPU_TYPE is wrong; but the subsequent malicious code is run because the code signing API has a preference for the native CPU architecture (x86_64) for code signing checks and will default to checking the unsigned code if it is x86_64.

Okta Rex contacted Apple on February 22, 2018 with a report and proof of concept examples that were able to bypass third-party security tools. Apple responded in March by saying it did not see this issue as a security problem that it should directly address.

Okta Rex disagreed, and informed Apple that it would notify third-party developers itself so that they could address the issues at their end. By early April it had notified — through CERT/CC — all known affected third party developers. These include VirusTotal, Google, Facebook, Objective Development, F-Secure, Objective-See, Yelp, and Carbon Black.

The researcher also recommended to CERT/CC on April 18 “that a public blog post is the best method for reaching third parties that use code signing APIs in a private manner.”

The researcher is not aware of any prior abuse of this technique by bad actors. Nevertheless, by exploiting this vulnerability, a threat actor could trick third-party security tools into believing their code is Apple-approved, letting malicious code live on a macOS machine until it’s patched.