A bug existed in third-party Mac security programs from Facebook, Google, VirusTotal, and more that allow malware to appear as legitimate programs code-signed by Apple. This bug is caused by the method the applications use to check if an executable is properly signed. This allows attackers to craft specially designed malware executables that could appear as signed by Apple even when they are not.
When a developer code-signs an application, it embeds a signature into the executable that can be used to verify that the application has not been tampered with and that it is from the organization you expect it to be from. Some security utilities use these embedded signatures as a way to whitelist executables and users use them as a way to feel assured that a program is safe to execute.
For example, if a program has a signature showing it was signed by Apple, you may feel more comfortable executing it, rather than an application that is not signed and provides no indication where it came from.
It’s all in how you check the exec
According to research published by Okta security researcher Josh Pitts, the vulnerability in third-party applications can be used by creating a specially crafted malicious Fat file to trick third-party apps into thinking that they are signed by Apple.
A “Fat file” is a executable Mac file that can contain multiple binaries that are targeted towards a particular CPU type. This allows one executable to contain different versions of the same application that can run on different CPU architecure.
Pitts research states that the malicious Fat file must be constructed in the following manner:
- 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 problem is that many third-party applications are not properly checking every component of the Fat file in order to check if the signature is valid. This causes the programs to verify only the first binary in the Fat file, which is the properly signed one by Apple, and then trust the rest of the sections of the file, even the malicious part.
This causes the app to appear as if it is properly signed by Apple by to execute malicious code.
Apple says it’s a developer problem
When Pitts contacted Apple about this issue, “Apple responded that third party developers should use kSecCSCheckAllArchitectures and kSecCSStrictValidate with SecStaticCodeCheckValidity API and developer documentation will be updated.”
When further pressed that these flags could be bypassed, Apple responded with “Third-party developers will 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 recommends that developers use the -R=’anchor apple’ flag to codesign in order to properly check all of the binaries in the Fat file and not just the first one.
In order to coordinate disclosure of this issue with 3rd party application vendors, Okta and Pitts contacted the CERT Coordination Center (CERT/CC). Along with CERT/CC all known third-party vendors were contacted prior to the disclosure of this bug. Pitts also provided a sample of a malicious Fat file that can be used by vendors to test their products.
The research stated that the following vendors and their applications were affected. I have also include the known updates to these tools that resolve the vulnerability.
- 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]
- Objective Development – LittleSnitch – CVE-2018-10470 [Fixed in Nightly Build 4.1 (5165]
- F-Secure – xFence (also LittleFlocker) CVE-2018-10403
- Objective-See – WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (and others). – CVE-2018-10404 [WhatsYourSign 1.5.0]
- Yelp – OSXCollector – CVE-2018-10406
- Carbon Black – Cb Response – CVE-2018-10407
F-Secure has already updated their XFence product and told internetnewsblog “We were contacted some time back, welcomed the disclosure, have fixed the problem, and an automatic update pushed it to the users of XFENCE beta last Saturday. This is the sort of research and process that results in better security for all.“
While the above is a list of known third-party application, Pitts expects that many other applications are also vulnerable.
For any vendor information that is missing above, feel free to contact us and we will update the above list with your info.
Update 6/12/18 17:51 EST: Updated with information from F-Secure.