MacMalware
MacMalware

The developers and vendors of numerous third-party security, forensics and incident response products for Mac computers have started issuing patches after researchers realized their software was not properly interacting with Apple's code-signing API. Without the patch, attackers can craft malicious files capable of bypassing the code-signing process, making it appear that their code is legitimate software approved by Apple.

Researchers at Okta discovered the flaw in macOS and OSX security products from VirusTotal (CVE-2018-10408), Google (Santa, molcodesignchecker -- CVE-2018-10405), Facebook (Osquery -- CVE-2018-6336), Objective Development (LittleSnitch -- CVE-2018-10470), F-Secure (XFENCE -- CVE-2018-10403), Objective-See (WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer and more -- CVE-2018-10404), Yelp (OSXCollector -- CVE-2018-10406), and Carbon Black (Cb Response -- CVE-2018-10407). However, even more tools may possibly be affected.

"Security, incident response, and forensics processes and personnel use code signing to weed out trusted code from untrusted code. By verifying signed code, detection and response personnel can speed up investigations by separating trusted code from untrusted code," states Josh Pitts, staff engineer, research and exploitation at Okta, in a company blog post published today. "To undermine a code-signing implementation for a major OS would break a core security construct that many depend on for day-to-day security operations."

Pitts explains that the vulnerability arises out of disparity between the way the Mach-O loader (Mach-O = Mach object file format) loads signed code and how flawed code-signing APIs check signed code. Attackers can exploit this difference using Universal or Fat Binary files, which contain several Mach-O files.

According to Pitts, the exploit works as long as the first Mach-O in the Fat/Universal file is legitimately signed by Apple, the malicious binary is adhoc-signed and i386 compiled for an x86_64 bit macOS, and the CPU_TYPE in the binary's Fat header is set to an invalid type or a CPU type that's not native to the host chipset.

If these conditions are met, the faulty API will fail to check the CA root of trust for all but the very first binary. In other words, the malicious code simply hitches a ride with the genuinely signed Mach-O code, and is never verified.

The Okta blog post shows proofs-of-concept for various affected products. Okta says it first disclosed its findings on February 22 and notified all third-party developers known to be affected on April 9. SC Media has reached out to all of the named vendors and developers for comment.

“We're grateful to the researcher who brought this to our attention," said a Facebook spokesperson. "We have fixed the issue in the latest version of Osquery, which is already available for download.”

“We were contacted some time back, welcomed the disclosure, [and] have fixed the problem, and an automatic update pushed it to the users of XFENCE beta last Saturday," said a statement from F-Secure. "This is the sort of research and process that results in better security for all.”

"This vulnerability was responsibly disclosed to us and, as an interim solution, we have disabled the code-signing check functionality, which can be bypassed by this vulnerability," said a spokesperson from Yelp. "Yelp's data and users were never at risk due to this vulnerability, but we will disclose this change to other OSXCollector users who may have relied on this functionality. A more comprehensive fix may be released in the future."

"VirusTotal has fixed the issue, in keeping with industry best practices," said a spokesperson from VirusTotal, who provided a link to an online example showing how VT now identifies attempts to bypass the code-signing process using Okto's method as invalid signature verification.

Carbon Black declined to comment.

as long as the initial Mach-O is genuine, the attackers can sneak through