I Can Be Apple, and So Can You
For almost 11 years, hackers have had an easy way to get macOS malware past the scrutiny of a host of third-party security tools by tricking them into believing the malicious wares were signed by Apple, researchers said Tuesday.
[…]
The technique worked using a binary format, alternatively known as a Fat or Universal file, that contained several files that were written for different CPUs used in Macs over the years, such as i386, x86_64, or PPC. Only the first so-called Mach-O file in the bundle had to be signed by Apple. At least eight third-party tools would show other non-signed executable code included in the same bundle as being signed by Apple, too. Affected third-party tools included VirusTotal, Google Santa, Facebook OSQuery, the Little Snitch Firewall, Yelp, OSXCollector, Carbon Black’s db Response, and several tools from Objective-See. Many companies and individuals rely on some of the tools to help implement whitelisting processes that permit only approved applications to be installed on a computer, while forbidding all others.
Developer Patrick Wardle spoke on the topic, explaining that the bypass was due to ambiguous documentation and comments provided by Apple regarding the use of publicly available programming interfaces that make digital signature checks function: “To be clear, this is not a vulnerability or bug in Apple’s code… basically just unclear/confusing documentation that led to people using their API incorrectly.” It’s also not an issue exclusive to Apple and macOS third-party security tools, as Wardle pointed out: “If a hacker wants to bypass your tool and targets it directly, they will win.”
For its part, Apple was said to have stated on March 20 that it did not see the bypass as a security issue that needed to be directly addressed. On March 29, the company updated its documentation to be more clear on the matter, stating that “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.”
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. The reason the malicious code, or “unsigned” code, must be i386, is that the code signing API 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.
[…]
However, to properly check for this type of abuse you need to add an anchor certificate requirement via the following commands:
- codesign -vv -R=’anchor apple’ ./some_application_or_mach-o # for Apple signed code
- codesign -vv -R=’anchor apple generic’ ./some_application_or_mach-o # for Apple signed code and Apple developer signed code
[…]
Typically, a developer would check the a Mach-O binary or Fat/Universal binary with the following APIs SecStaticCodeCheckValidityWithErrors() or SecStaticCodeCheckValidity() with the following flags:
These flags are supposed to ensure that all the code in a Mach-O or Fat/Universal file that is loaded into memory is cryptographically signed. However, these APIs fall short by default, and third party developers will need to carve out and verify each architecture in the Fat/Universal file and verify that the identities match and are cryptographically sound.
Update (2018-06-13): Objective Development:
Fortunately for us and our users, the consequences this has for Little Snitch are not as as bad as it first seems when reading the various headlines about this issue: What connections are allowed or denied by Little Snitch’s network filter is completely unaffected by this. The only thing that could happen is that Little Snitch would show inconsistent or incorrect information about an app’s code signature, but it would never actually allow connections that should not be allowed.
