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.
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.
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 and content manager who has been with SensorsTechForum since the project started. A professional with 10+ years of experience in creating engaging content. Focused on user privacy and malware development, she strongly believes in a world where cybersecurity plays a central role. If common sense makes no sense, she will be there to take notes. Those notes may later turn into articles! Follow Milena @Milenyim
Follow Me: