Kaspersky burns 11,000-line “NSA” exploit: Calls 14-step iPhone attack “definitely the most sophisticated attack chain we have ever seen”
Apex Predators aside and in other news, a major telco just got hacked because it didn't have MFA set up on a critical account...
Somewhere in a three letter government agency, a project manager is raiding a fresh bank of Secret Plans and Clever Tricks – for the kind of operation that needs a 14-step iPhone attack chain using two kernel exploits and 11,000 lines of code that exploit an undocumented feature.
This one, used on Kaspersky, got burned – after it had done its job.
To those napping on “Operation Triangulation” it’s Kaspersky’s public attempt to understand precisely how its team’s iPhones got pwned by an attacker that looks to have had advanced nation state capabilities. (Russia’s agencies have pointed the finger, predictably, at the NSA…)
The Russian cybersecurity company’s exploration of how it got breached saw it find and report a series of Apple zero days in rapid succession in 2023 – these had created a zero-click exploit chain that exposed a wide range of Apple products (including iPhones, iPods, iPads, macOS devices, Apple TV and Apple Watch) to compromise by the sophisticated attacker.
In a presentation that got the information security crowd chattering over the Christmas period, Kaspersky revealed more detail about the attack – which featured exploitation of an “obscure debugging feature in the Apple A12-A16 SoC’s [system-on-chips] that bypasses all of the hard-to-hack hardware-based memory protections on new iPhones. It’s not used by the firmware and we don't know how the attackers found out about it…”
As a result, the attackers were “able to write data to a certain physical address while bypassing the hardware-based memory protection by writing the data, destination address, and data hash to unknown hardware registers of the chip unused by the firmware” Kaspersky said.
Among other steps the attackers exploited an RCE bug, allocated CVE-2023-41990, in an undocumented, Apple-only ADJUST TrueType font instruction that had “existed since the early nineties”. They also used a JavaScript exploit “obfuscated to make it completely unreadable and to minimize its size” but still 11,000 lines of code long (“mainly dedicated to JavaScriptCore and kernel memory parsing and manipulation.”)
Quite how the attackers got access to the above instruction immediately got many observers chatting about whether it was an Apple backdoor.
(Apple insisted in July 2023 that “we have never worked with any government to insert a backdoor into any Apple product and never will”. Leaks by former NSA contractor Edward Snowden suggested that the NSA’s PRISM programme facilitated data collection “directly from the servers” of US technology providers including Apple, whilst further leaks provided details on an NSA “software implant for the Apple iPhone that utilizes modular mission applications to provide specific SIGINT [signals intelligence] functionality” that “includes the ability to remotely push/pull files from the device. SMS retrieval, contact list retrieval, voicemail, geolocation, hot mic, camera capture, cell tower location, etc.”)
nb: Intelligence services, everywhere, aim to hold on to carefully chosen and strategically useful exploitation capabilities over widely used software. Indeed, the UK’s GCHQ has helpfully spelled out precisely why and when it chooses to do that, rather than to disclose vulnerabilities to vendors.
Kaspersky’s researchers themselves were repeatedly mystified whilst investigating, saying in a technical breakdown that “while analyzing the exploit used in the Operation Triangulation attack, I discovered that most of the MMIOs [input/output between the CPU and peripheral devices] used by the attackers to bypass the hardware-based kernel memory protection do not belong to any MMIO ranges defined in the device tree.”
(Address ranges for MMIOs of peripheral devices in Apple products are stored in the DeviceTree format, which can be extracted from firmware.)
As Kaspersky’s Boris Larin put it: “I checked different device tree files for different devices and different firmware files: no luck. I checked publicly available source code: no luck. I checked the kernel images, kernel extensions, iboot, and coprocessor firmware in search of a direct reference to these addresses: nothing. How could it be that that the exploit used MMIOs that were not used by the firmware? How did the attackers find out about them? What peripheral device(s) do these MMIO addresses belong to?” – he eventually found that an exploit used in the attack writes to previously unknown MMIO registers related to a GPU coprocessor. Exploring the ARM firmware for this (Ed: One has to admire the persistence of the researchers in trying to understand this exploit) he wrote that “I could not find anything related to these registers in there.”
(Kaspersky’s team identified many of the multiple obscure steps in the attack chain but still have questions about some, per their blog post.)
Reviewing exploit code, the cybersecurity company was able to “match the ml_dbgwrap_halt_cpu function [shown in the exploit] to a function with the same name in the dbgwrap.c file of the XNU source code.
“This file contains code for working with the ARM CoreSight MMIO debug registers of the main CPU. The source code states that there are four CoreSight-related MMIO regions, named ED, CTI, PMU, and UTT. Each occupies 0x10000 bytes, and they are all located next to one another. The ml_dbgwrap_halt_cpu function uses the UTT region, and the source code states that, unlike the other three, it does not come from ARM, but is a proprietary Apple feature that was added just for convenience…”
Kaspersky's researchers present their findings
As for the question of how this was discovered, one observer, security researcher Hector Martin suggested that “dbgwrap is guessable. The actual mechanics of the cache debug registers are guessable, including the bit order table. I've guessed things more complicated than that before by black box trial and error. The question is how they got the hint of where to look. It's not implausible someone guessed such cache debug registers might exist and went looking for them. But I think it's more likely they got a hint somewhere. All they'd need is a block level MMIO map.
Martin added: “I could believe that was an insider leak, and I could also believe Apple screwed up and leaked it (or only the cache thing specifically) in some firmware/software. They're not very good at keeping secrets under wraps if you know where to look. I also have a strong suspicion that in certain circles there are lots of juicy internal Apple debug tools floating around that might have such information.”
An intriguing puzzle for security researchers and some impressive unravelling of the attack path by Kaspersky. Not everyone had time for the persistent buzz that surrounded the disclosure of this component of what the Russian firm called “Operation Triangulation” however.
As one observer, Andy Thompson put it on X: “The overwhelming majority of adversaries that are relevant threats to the majority of organizations are using known and published tools and methodologies, but information security Twitter will go on a binge about the sophistication of apex actors that frankly are only relevant to a tiny fraction of the world, and likely the segment that needs to get hacked anyways,” he said dismissively.
In news that somewhat corroborates Thompson’s view , this week telco Orange said its Spanish arm had been hacked after attackers breached its RIPE account. RIPE, a non-profit, allocates and registers blocks of Internet number resources to Internet service providers (ISPs) and other organisations. The attackers used stolen credentials to login to RIPE.
As security researcher Kevin Beaumont noted, no MFA was set up on the account: “RIPE don’t require it, and it isn’t enabled by default for new accounts either. Also, there is no sane password policy at RIPE — you can use borisjohnson as your password, in other words it is a powder keg.”
