Bypass Glitch Allows Malware to Masquerade as Legit Apple Files

Masquerading as an official Apple system file sounds like a wonderful way for malware to worm its way onto Macs – and a recently discovered code-signing bypass flaw allows bad code to do just that.

The way some developers have implemented Apple’s official code-signing API can be exploited by attackers. Essentially, Apple makes an API available to developers that want to create a security function that verifies Apple files as being legitimate (by making sure the file’s code is signed). However, many of these developers have not used the API properly, so it introduces a vulnerability into the security product or function that allows for unsigned malicious code to appear to be signed by Apple. The result is that malware can fool vulnerable security products and services into thinking that it’s just another legitimate Apple file – so it slips past their security checks and onto the targeted machine.

A host of security products, some open-source projects and security functions used by Google, Facebook and Yelp are among the affected code.

A Word About Code-Signing

Code-signing uses public key infrastructure to digitally sign files and bits of code in order to mark it as “trusted” and vendor-approved. In turn, verifying those signatures is a key process at the center of whitelisting, antivirus, incident response and threat-hunting efforts.

Okta, which reported the vulns, explained that in macOS, code-signing focuses on Mach-O files, which target a specific native CPU architecture within the Mac ecosystem. The bypass involves a lack of code-signing verification for Mach-O files that are gathered (or “nested”) into the Fat/Universal file format.

“This vulnerability exists in the difference between how the Mach-O loader loads signed code, versus how improperly used code-signing APIs check signed code,” explained Josh Pitts, staff engineer for Research and Exploitation at Okta, in an analysis released on Tuesday.

Making the Exploit Work

For the exploit to be successful, the first Mach-O binary in the Fat/Universal file must be legitimately signed by Apple; malicious binaries can then be appended (they must be ad-hoc signed and i386-compiled for an x86_64-bit target macOS, Pitts said).

The legitimate file also has to have the CPU type in the Fat header set to a format that’s invalid or not native to the platform (for example, PPC). By doing this, the Mach-O loader will skip over the validly signed Apple binary and instead execute the malicious code.

Meanwhile the code-signing API (Pitts tested “SecCodeCheckValidity”) will check the first binary – the legitimate Apple file – but will not check the certificate authority root of trust for the malicious file, instead marking it as approved and verified.

The researcher’s initial proof of concept demonstrated the ease by which the exploit works: It “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 [then] code-signing checks [are returned as being] valid.”

The code-signing APIs contain flags that are supposed to ensure that all of these files are cryptographically signed. “However, these 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,” Pitts said. He added that fixes are the “developer’s responsibility.”

Patches But Further Concerns

Known affected vendors and open-source projects have been notified and patches are available. These include: Carbon Black (CVE-2018-10407); Facebook (CVE-2018-6336); F-Secure (CVE-2018-10403); Google (CVE-2018-10405); Objective Development (CVE-2018-10470); Objective-See (CVE-2018-10404); VirusTotal (CVE-2018-10408); and Yelp (CVE-2018-10406).

“However, more third-party security, forensics and incident response tools that use the official code-signing APIs are possibly affected,” Pitts warned, advising developers to use his PoCs to check their code.

READ MORE HERE