SIGNED, SEALED, DELIVERED —

For almost 11 years, hackers could easily bypass 3rd-party macOS signature checks

Technique caused security apps to falsely show untrusted apps were signed by Apple.

Screenshot of software requesting system privileges.
Enlarge / The Little Snitch firewall was one of at least eight third-party Mac security tools affected by a code-signing bypass.

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.

Digital signatures are a core security function for all modern operating systems. The cryptographically generated signatures make it possible for users to know with complete certainty that an app was digitally signed with the private key of a trusted party. But, according to the researchers, the mechanism many macOS security tools have used since 2007 to check digital signatures has been trivial to bypass. As a result, it has been possible for anyone to pass off malicious code as an app that was signed with the key Apple uses to sign its apps.

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.

The Stuxnet worm that targeted Iran’s uranium enrichment program eight years ago relied on digital signatures belonging to legitimate software developers. Last year, researchers said fraudulent code-signing was more widespread than previously thought and predated Stuxnet by about seven years. Most of those attacks involved obtaining Microsoft Windows-trusted signing certificates belonging to legitimate developers. The Apple forgery, by contrast, required no such certificate theft.

“It’s really easy,” Joshua Pitts, a senior penetration testing engineer at security firm Okta, said of the technique. When he discovered it in February, he quickly contacted Apple and the third-party developers. “This really scared the bejeebus out of me, so we went right to disclosure mode.”

Pitts said tools built into macOS weren’t susceptible to the bypass, which has been possible since the release of OS X Leopard in 2007. Okta has published more about the bypass here. The post demonstrated how the bypass caused the affected tools to show that a file named ncat.frankenstein was signed by Apple, even though it wasn't.

This is not the first time researchers have found a way to bypass signature checks in third-party tools. In 2015, for instance, a researcher published this hack subverting whitelisting in Google Santa. Patrick Wardle, the developer of the Objective-See tools and Chief Research Officer at Digita Security, said third-party tools including his own can almost always be bypassed when hackers directly or proactively target them.

“If a hacker wants to bypass your tool and targets it directly, they will win,” Wardle said. He went on to say that the bypass was the result of ambiguous documentation and comments Apple provided for using publicly available programming interfaces that make the signature checks work.

“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,” Wardle told Ars. “Apple updated [its] documents to be more clear, and third-party developers just have to invoke the API with a more comprehensive flag (that was always available).”

Listing image by Frank Lindecke / Flickr

Channel Ars Technica