Malicious Code Can Look Like It Has Been Signed by Apple

Malicious Code Can Look Like It Has Been Signed by Apple

Security researchers just discovered a code-signing bypass vulnerability that allows malicious code to masquerade as an official Apply system file. In other words, some of the implementations of Apple’s official code-signing API can be exploited by hackers.




Apple has made an API available to developers who wish to build a security function that verified Apple files as legitimate. The issue stems from the way some developers have implemented the API, thus introducing a vulnerability into the security product.

The flaw allows for unsigned malicious code to look like it has been signed by Apple. As a result of this “misunderstanding”, malware can trick vulnerable security products and services into believing it is just another legitimate Apple file.

Related Story: Apple Patch Remedies Critical High Sierra Vulnerability (CVE-2017-7149)

Who is affected by this vulnerability? A host of security products, several open-source projects and security functions used by Google, Facebook and Yelp.

More about the Vulnerability

As explained by researcher Josh Pitt at Okta, the flaw exists in the difference between how the Mach-O loader loads signed code versus how improperly used Code Signing APIs check signed code and is exploited via a malformed Universal/Fat Binary (a binary format that contains several Mach-O files with each targeting a specific native CPU architecture).

It should be noted that there are several 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.

The initial proof-of-concept demonstrated how easy it is for the flaw to be exploited successfully – the exploit doesn’t even require admin access nor does it 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 researcher pointed out.

Patching Is the Developer’s Responsibility

In addition, the code-signing APIs have flags that should ensure that all of these files are cryptographically signed. The truth is different, as “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.” As to who is responsible for the patching of the issue, Okta researcher says it is the developer’s responsibility.

Related Story: ZipperDown Vulnerability Affects About 10% of iOS Apps

Known affected vendors and open-source projects are alerted and patches are available. Here is a list of affected vendors and the applying patches:

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)

There may be even more third-party security, forensics and incident response tools that use the official code-signing APIs, meaning there are more affected parties. The researcher urges developers to check their code using his proof-of-concept.




Milena Dimitrova

An inspired writer, focused on user privacy and malicious software. Enjoys 'Mr. Robot' and fears '1984'.

More Posts - Website

Leave a Comment

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

Share on Facebook Share
Loading...
Share on Twitter Tweet
Loading...
Share on Google Plus Share
Loading...
Share on Linkedin Share
Loading...
Share on Digg Share
Share on Reddit Share
Loading...
Share on Stumbleupon Share
Loading...