Many third-party security platforms are failing to properly implement Apple’s code signing API, and the result could be malware passing itself off as signed software.
The “code signing bypass” was discovered by Okta engineer Josh Pitts, who first uncovered it in February 2018 before publicly disclosing it on June 12, 2018. It affects numerous security platforms, including those from Facebook and Google, and Apple isn’t accepting responsibility, at least not according to what Pitts said about his response from the macOS manufacturer.
Code signing involves a developer or software company embedding a digital signature into an application that says it was built by them and hasn’t been modified by any third parties. Code signing ensures that software is coming from reputable sources–most security software uses code signing verification to be sure an app is legitimate before allowing it to install.
In the case of several macOS security suites, Pitts said, the code signing check is being improperly used, which can allow certain executable files to present a valid signature for one part of an app that’s bundled with a bunch of malicious modules that the security software isn’t bothering to check.
Fake IDs and lazy bouncers
It’s like the college bar scene all over again: Students with fake IDs know that certain bars have bouncers with less than thorough inspection regimens, and that’s where they head when they want to slip by undetected.
In the case of macOS security, being lazy about inspecting IDs could result in a whole bevy of malware slipping by undetected–potentially anything an attacker could include in a FAT file can be used.
Pitts said that exploiting code signing checks just requires a few things:
- A FAT/universal file format executable that contains as its first item a properly signed Mach-O file formatted for i386, x86_64, or PPC.
- Malicious binaries that are adhoc signed and i386 compiled for an x86_64 macOS system.
- CPU_TYPE in the header file must be set to an invalid format, or one that isn’t native to the target machine’s chipset.
“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 said in his post.
SEE: Quick glossary: Malware (Tech Pro Research)
Formatting the particular files in the FAT executable is essential, as i386 causes problems for the code signing API, which “has a preference for the native CPU architecture (x86_64) for code signing checks and will default to checking the unsigned code if it is x86_64.”
In short, an executable that manages to do things right will look properly signed and be able to run whatever malware it contains with impunity.
Is Apple’s response the right one?
After Pitts informed Apple of the exploit, Apple told him that “third party developers should use kSecCSCheckAllArchitectures and kSecCSStrictValidate with SecStaticCodeCheckValidity API,” and that the company would update its developer documentation to reflect that requirement.
Pitts responded by telling Apple, and providing a proof of concept, that it was possible to bypass both flags and codesign strict checking, allowing the exploit to function even if the developer includes those flags.
According to Pitts, “Apple stated they did not see this as a security issue that they should directly address,” again saying that developers “need to do additional work to verify that all of the identities in a universal binary are the same if they want to present a meaningful result.”
Pitts’ disclosure timeline makes Apple out to be unwilling to accept responsibility for the exploit, instead shifting responsibility onto developers for improperly using its code signing API, but if the exploit can still be performed even with Apple’s recommended flags enabled, it doesn’t seem to be a developer issue.
For now there aren’t many actions to take aside from reviewing Pitts’ article to see if your antivirus software is affected. If so, be sure you’re installing the latest updates so that you get a fix when it’s available, and avoid installing apps from anywhere but trusted sources like the macOS App Store.
The big takeaways for tech leaders:
- A flaw in third-party macOS security software handling of code signing allows a malicious app to pass itself off as properly signed.
- Apple says the problem lies in the way third parties are implementing its API, but its suggestions for how to fix the issue don’t resolve it. Keep your macOS system secure by installing the latest antivirus updates and not installing apps from untrusted sources.
Also see
- Boost your Mac productivity with these 10 techniques (free PDF) (TechRepublic)
- Stupid, stupid MacOS security flaw grants admin access to anyone (ZDNet)
- Apple’s macOS 10.14 Mojave has big security and privacy updates: Here’s the list (TechRepublic)
- New MacOS backdoor connected to OceanLotus threat group (ZDNet)
- Hacker claims to have decrypted Apple’s Secure Enclave, destroying key piece of iOS mobile security (TechRepublic)
