A bug in the way that some third-party tools treated the Apple code-signing API in macOS and older versions of OS X could allow an attacker to make malicious files seem like legitimately signed ones and slip them past many security tools.
The weakness affects a number of apps, including VirusTotal and Santa from Google, Facebook’s OSQuery, Carbon Black’s Cb Response, and several tools from Objective-See, among others. Researcher Josh Pitts, who discovered the issue, found that in some cases poorly implemented code-signing APIs will treat unsigned files that are grouped with files signed by Apple as the same. Using this weakness, an attacker could bypass the code-signing checks that the third-party tools use to ensure that files are legitimate and get malicious code onto a target machine. There have been several other instances of vulnerabilities in OS-level code-signing checks, but Pitts said this weakness is simpler to exploit.
“Unlike some of the prior work, this current vulnerability 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 code signing checks return valid,” Pitts, a researcher at Okta, said in a post explaining the issue.
“This 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.”
“Unlike some of the prior work, this current vulnerability does not require admin access."
Code signing is an important signal for operating systems and third-party apps that a given file is legitimate and should be trusted. Security tools often will implicitly trust signed files, especially those signed by a platform vendor such as Apple. The method that Pitts developed exploits that inherent trust by bundling ad-hoc signed files with one or more signed by Apple. In order for the attack to work, the first file in the bundle has to be signed by Apple.
“Without passing the proper SecRequirementRef and SecCSFlags, the code signing API (SecCodeCheckValidity) will check the first binary in the Fat/Universal file for who signed the executable (e.g. Apple) and verify no tampering via the cryptographic signature; then the API will check each of the following binaries in the Fat/Universal file to ensure the Team Identifiers match and verify no tampering via containing cryptographic signature but without checking the CA root of trust,” Pitts wrote.
Pitts notified Apple of his findings in February and a month later the company said it didn’t see this as a security problem it needed to fix and it would be up to the third-party app developers to make changes to their tools. He contacted all of the affected vendors and also notified the CERT/CC.
Pitts recommends that users install updated versions of the affected third-party apps as they become available.