Nefarious actors who successfully exploit a newly discovered vulnerability in Apple code signing can potentially deceive third-party tools into believing their code is Apple approved. Today, the Okta Research and Exploitation (REX) researcher who uncovered the security issue publicly disclosed the vulnerability that could allow threat actors to bypass a core security function to impersonate Apple.
Once researcher Josh Pitts contacted Apple, the CERT Coordination Center and all third-party developers, he recommended that a public blog post was the best means of reaching third parties that use code signing application programming interfaces (APIs) in a private manner.
Code signing is the process by which public key infrastructure is used to digitally sign compiled code and scripting languages in order to validate that the code has not been modified. Pitts discovered a vulnerability that breaks the trust in code signed by Apple used in MacOS security.
Recognizing that code signing has had a slew of security issues, Pitts wrote in his public disclosure, "Unlike some of the prior work, this current vulnerability does not require admin access, does not require JIT’ing code, or memory corruption to bypass code signing checks. All that is required is a properly formatted Fat/Universal file and code signing checks return valid."
If exploited, all third-party security, forensic, and incident response tools that use the code-signing API would be affected, along with the millions of consumers and businesses that use Mac machines.
"By exploiting this vulnerability, threat actors can trick even the most security-savvy people and bypass a core security function that most end users don’t know or think about as they go about their digital activities. And, with the proliferation of apps for the workplace and personal use in everybody’s daily lives, bad actors can easily abuse this vulnerability," Matias Brutti wrote in an Okta REX blog post today.
On 22 February 2018, Pitts submitted a proof of concept that was able to bypass third-party security tools, and Apple responded on 1 March advising the researcher to use kSecCSCheckAllArchitectures and kSecCSStrictValidate with SecStaticCodeCheckValidity, adding that API and developer documentation will be updated.
Despite additional information submitted on 6 March and 16 March to it, Apple stated on 20 March that it did not see this as a security issue that needed to be directly addressed. According to Pitts, on 29 March, "Apple stated that documentation could be updated and new features could be pushed out, but: '[…], 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.'”