macOS Signature Validation Flaw Allows a Malicious Code Appeared to be Signed by Apple

A flaw in third-party macOS APIs could allow attackers to impersonate the malicious programs to be signed by Apple. The vulnerability affects many vendors and open source projects.

The vulnerability resides in how third-party vendors such as Google and Facebook checks the signed code to verify the integrity of the file.

Developers use to codesign the application to ensure the trust of origin and the code has not tampered. Security, incident response, and forensics processes and personnel use code signing to isolate the malicious code form trusted code.

Where the Vulnerability Resides

Security researchers Josh Pitts, from Okta, identified the vulnerability in third-party developers’ interpretation of code signing API allowed for an unsigned malicious code to appear to be signed by Apple.

According to Okta the affected vendors are Google, LittleSnitch, F-Secure-xFence, Yelp OSXCollector, VirusTotal, Carbon Black.

Pits explained the “vulnerability exists in the difference between how the Mach-O loader loads signed code vs how improperly used Code Signing APIs check signed code and is exploited via a malformed Universal/Fat Binary.”

The code signing API verifies the first binary in the Fat/Universal to see who signs the executable without passing the flags SecRequirementRef, SecCSFlags, and SecCodeCheckValidity.

To verify no tampering via the cryptographic signature and verify binaries Fat/Universal file to verify no tampering via containing cryptographic signature but without checking the CA root of trust.

Conditions for the vulnerability to work

• The first Mach-O in the Fat/Universal file must be signed by Apple, can be i386, x86_64, or even PPC.
• The malicious binary, or non-Apple supplied code, must be adhoc signed and i386 compiled for an x86_64 bit target macOS.
• The CPU_TYPE in the Fat header of the Apple binary must be set to an invalid type or a CPU Type that is not native to the host chipset.

Patches have been released an as soon the issue shared to the public, Pits says the “APIs fall short by default, and third-party developers will need to carve out and verify each architecture in the Fat/Universal file and verify that the identities match and are cryptographically sound.”

VirusTotal – CVE-2018-10408
Google – Santa, molcodesignchecker – CVE-2018-10405
Facebook – OSQuery – CVE-2018-6336
Objective Development – LittleSnitch – CVE-2018-10470
F-Secure – xFence (also LittleFlocker) CVE-2018-10403
Objective-See – WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (and others). – CVE-2018-10404
Yelp – OSXCollector – CVE-2018-10406
Carbon Black – Cb Response – CVE-2018-10407

The vulnerability went unnoticed for years and there is no evidence of this vulnerability being abused. If you are using any of the above-listed tools it is recommended to check for the updates.