Okta warns of Apple code-signing vulnerabilityEnterprise security vendor Okta, has taken a bite out of Apple’s much vaunted security model. It has identified a vulnerability that allows anyone to make their code look as if it is Apple approved. Any user downloading and installing this code could be opening their machine up to malware or worse.

The details were released in a pair of blogs from researchers Matias Brutti and Josh Pitts. Brutti’s blog – I Snuck a Bad Apple into the Basket and Nobody Noticed– is an overview of the vulnerability and its risk. Brutti says: “Okta REX has discovered a vulnerability in what is known as ‘code signing,’ effectively allowing any bad actor to impersonate Apple and allow malicious code to live undetected in a macOS machine indefinitely (or at least until it’s re-imaged or the offending file is removed).”

Matias Brutti, Okta’s senior manager of research and exploitation
Matias Brutti, Okta’s senior manager of research and exploitation

What is most worrying about Brutti’s blog is the statement: “All third-party security, forensics, and incident response tools that used the official code signing API are affected. We’ve worked with the top security vendors in this space, including  Google (Santa) and Facebook (OSquery), as well as tools like Carbon Black, VirusTotal, and Objective-See tools like WhatsYourSign, ProcInfo, KnockKnock, LuLu, and TaskExplorer (among several others).”

The number of vendors affected is surprising. It shows how a simple vulnerability, details below, can be overlooked by so many security teams. This is a problem that won’t go away. The good news is that all of those vendors above, including Apple, have issued patches to deal with this. However, that doesn’t mean that there is no malicious code out there. It is important that IT teams apply all patches to stop bad code from executing.

What is this all about?

Code-signing is a process by which developers use a public key to sign their code. It means that the code can be traced back to the original developer and trusted. It has taken some time but now the majority of commercial software is signed by the vendor. This is, however, still a weak spot for internal code with very few enterprise developers securing their software.

Josh Pitts, Senior Penetration Testing Engineer, Okta
Josh Pitts, Senior Penetration Testing Engineer, Okta

Pitts blog – I can be Apple, and so can you– explains why we are using code signing. It also talks about the technical details of the vulnerability and how it works. It is surprisingly simple. There are just three conditions that have to be met:

  1. The first Mach-O in the Fat/Universal file must be signed by Apple, can be i386, x86_64, or even PPC.
  2. The malicious binary, or non-Apple supplied code, must be adhoc signed and i386 compiled for an x86_64 bit target macOS.
  3. 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.

To make this work, the developer appends their adhoc signed code to the properly signed code. Setting the invalid CPU_TYPE then causes the properly signed code to be ignored at runtime but does cause the adhoc code to execute.

Who is affected?

Pitts lists all the vendors who are affected by this vulnerability and the CVE numbers assigned to them. It is important to note that updates to address this have been issued. Organisations need to ensure that they are running the latest versions of the tools and apply the patches.

The list of affected vendors and CVE numbers is:

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

What does this mean

This is more than just another software vulnerability. Code signing is seen as a critical element of making sure that software can be trusted. The software industry has worked hard over the last 15 years to promote the benefits for code signing. When it breaks, it does more than allow hackers and others to subvert software and infect systems. It also leaves users unable to be certain that they can trust the applications that they are running.

For Apple users this vulnerability has a more serious meaning. There is still limited take-up of endpoint security tools for Apple devices. It is still common to hear people talk about their Mac as being secure and unlikely to be attacked. These are outdated and dangerous views. Attacks on MacOS and iOS have increased significantly over the last few years. Much of the belief of invincibility lies around Apple’s software checking process. This news shows how easily a process can end up failing and quickly users can be put at risk.

Everyone involved has reacted quickly to resolve this but there may still be some developer tools out there that have not understood the risk. It will be interesting to see how Apple tracks them down and if it uses this to do a sweep of all apps in its App Store.


Please enter your comment!
Please enter your name here