Mac OS Vulnerability Allowed Malware To Bypass Apple Signature
On Tuesday, Josh Pitts, a security researcher and staff engineer at Okta reported in detail about a Mac OS vulnerability. Precisely, he addressed the issues revolving around Apple’s third-party code-signing checks. He pointed out how third-party developer’s interpretation of code signing API bypassed Apple’s signature and misinterpreted unsigned malicious codes as being signed by Apple.
Because of this misinterpretation, hackers had a wide opportunity to dump malicious codes that any third-party developers may use by misinterpreting them as being Apple verified. In this way, malware could easily access Apple customers devices. Precisely, this code-signing bypass was mainly affecting Mac OS and some older versions of OSX.
Patrick Wardle, CRO DigitaSecurity and Objective-See tools developer, does not consider this problem as a ‘vulnerability’. According to him, bypassing signatures is always easy for hackers.
“If a hacker wants to bypass your tool and targets it directly, they will win,” says Wardle. “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.”
Tricking Code-Signing Was ‘Easy’ And ‘Trivial’
Apple requires third-party developers to use code-signing API. However, the process by which Mac OS security tools checked for digital signature was trivial to bypass. Anyone knowing this ease of evading Apple signature could then throw in malware as a signed app. As Mac OS used the same process since 2007, the risk of malware and hacking was there for the past 11 years.
Josh Pitts has explained well how anyone could leverage flaw to spread malware. He himself demonstrated the flaw where his file ‘ncat.frankenstein’ appeared digitally signed, even though it wasn’t Apple verified. According to him, the vulnerability works in certain conditions. If a hacker knew about them, he could bypass codesign.
“On macOS/iOS, code signing focuses on the Mach-O binary and application bundles to ensure only trusted code is executed in memory,’ says Josh Pitts. “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.”
Josh Pitts first discovered the problem in early 2018, when he reported the details to Apple. However, Apple, at that time, didn’t consider this as a security issue. But, as he continued communicating with Apple over the matter, things changed. He has shared a detailed timeline showing how his efforts started on February 22, 2018, however it took a while to disclose this matter to the public on June 12, 2018.
Let us know your thoughts in the comments below.