Third-Party Mac Security tools bug allowed malware to appear as legit apple software

A recent vulnerability was discovered with the third party Mac security tools such as Google Santa, Little Snitch, xFence, Facebook OSquery, Yelp’s OSXCollector, Carbon Black’s Cb response and several other Objective See’s Tools.

Apple later informed that it was not a fault in their protocols but a flaw in the third-party Mac security tools. The third party Mac security tools failed to properly implement the security checks that allowed the software to be signed as apple software.

A software program has to undergo many security checks before it is allowed in the app store for the user. To authenticate the software apple conducts a series of checks and later signs the code. This Signature by Apple is a seal of approval that helps the user when trusting new software. With this signature the user does not have to worry about security breaches.

The Executable file is checked by Third party Mac security tools. The flaw was discovered when it was found that the Third Party security tools were not properly checking each component in the Fat/Universal file.

The multiple binary codes that a Fat file contains in form of a executable Mac file and is targeted towards a particular CPU type. Thus, the file can run on different CPU architecture types with having different application versions in the same code.

To pass as authentic software the malicious files could be constructed in a manner where the Third Party Mac Security Tools allowed the code with apple signature.

• The files can contain i386, x86_64 or PPC as CPU architecture for the first Mach-O in the Fat/Universal file that must be signed by Apple.
• The Malicious binary file must be ad-hoc signed and i386 compiled for an x86_64 bit target Mac OS.
• In the Apple Binary file, CPU type in the FAT header must be set to an individual type or a CPU type which is not native with the host chipset.

To correct the situation third party developers should use kSecCSStrictValidate and kSecCSCheckAllArchitectures with SecStaticCodeCheckValidity API. It will update the developer documentation for the code. With this apple also said that the developers need to check the full universal binary code and confirm that the identities are the same throughout to have a positive outcome. The developers should also use –R=’anchor apple’ flag to codesign to properly check all the binary files in the FAT file and not just the first binary.

Before disclosing the bug, the 3rd Party Application Vendors were contacted and this issue was resolved to minimize the impact. Some vendors may have been left out but the issue will be patched with a small update from the vendor side.

These files were updated with the new patch to stop malware to appear as apple software.

• VirusTotal – CVE-2018-10408
• Google – Santa, molcodesignchecker – CVE-2018-10405 [Fixed in Santa .0.9.25]
• Facebook – OSQuery – CVE-2018-6336 [Fixed in 3.2.7]
• Carbon Black – Cb Response – CVE-2018-10407
• Objective Development – LittleSnitch – CVE-2018-10470 [Fixed in Nightly Build  4.1 (5165]
• Objective-See – WhatsYourSign, ProcInfo, LuLu, KnockKnock, TaskExplorer (and others). – CVE-2018-10404 [WhatsYourSign 1.5.0]
• F-Secure  – xFence (also LittleFlocker) CVE-2018-10403
• Yelp – OSXCollector – CVE-2018-10406

Hits: 64