Audio transcript
There are some readers here who will understand the import of the statement above and not believe it, and there are others who are not in a position to understand it all. For both camps, I’ll attempt to explain the details around what is (confirmed and corroborated by others) arguably one of the most critical security events to happen in the last decade of IT security.
What’s completely astonishing is the almost complete lack of media coverage (ARS Technica alone did a great piece) of this issue since its announcement by Kaspersky on the 27th of Dec 2023. Is this due to the holiday period (news of the original Meltdown and Spectre vulnerabilities was also released during the Dec/Jan holidays and seemed to have had a much greater reception in the media) or the fact that it’s Kaspersky (supposedly Russian-backed) that found and announced the issue?
No matter your thoughts on Kaspersky and its alleged ties to the Russian government, their research has been confirmed by others.
I reference information in this blog post from @sggrc’s Security Now 955 show as well as publicly available information from Kaspersky themselves and other 3rd parties/media.
Problem Statement
Kaspersky has found a hardware/silicon-based backdoor in 5 generations of Apple mobile silicon, starting with the A12 CPU (iPhone X) and continuing to the A16 CPU (iPhone 14/15). These CPUs have been used in other Apple products like the iPad, Watch and TV, so the iPhone is not the only affected product.
This backdoor allows complete remote access to, and control of, the affected devices … let that statement stew for a few minutes. And then understand that this allows a 3rd party to see and control anything on your Apple-based phone.
History
The issue now commonly referred to as CVE-2023-38606, was announced by Kasperky on Dec 27 2023. It refers to a hardware backdoor that was found in Apple CPUs designed and manufactured over a 5 year period. They state the following in their announcement:
The discovered vulnerability is a hardware feature, possibly based on the principle of “security through obscurity,” and may have been intended for testing or debugging. Following the initial 0-click iMessage attack and subsequent privilege escalation, the attackers leveraged this hardware feature to bypass hardware-based security protections and manipulate the contents of protected memory regions. This step was crucial for obtaining full control over the device. Apple addressed the issue, identified as CVE-2023-38606.
ARS Technica
Like Steve Gibson on the SN podcast, I take issue with Kaspersky’s characterisation of this being a vulnerability, which infers a bug as a result of a mistake in coding or design. To be very clear here, this backdoor was NO mistake – it was intentionally designed into the CPU.
Nonetheless, it does not diminish the severity of the issue.
So how did Kaspersky find this issue?
They had been following the propagation of Operation Triangulation, an APT (advanced persistent threat or complex malware that involves multiple stages of infection and attack using a variety of methods) which targets iOS devices through zero-click exploits distributed through iMessage. In other words, no action needs to be taken by the victim – they simply need to receive the attack message to be compromised. And this attack effects any Bionic CPU-based product from iPhones all the way to Apple Watches.
In the process of tracking the Triangulation malware (more details here), Kaspersky found that the method for the initial attack vector sourced from an undocumented hardware feature that few, if anyone, outside of Apple and chip suppliers such as ARM Holdings knew of.
There are 2 aspects of Triangulation to consider:
- how did the hardware backdoor come about?
- how did the attackers know about the backdoor and come to use it in their malware?
On the first question, It’s quite impossible for Apple to not have known about the backdoor in a CPU that their own engineers designed. Or might one suggest the even more ludicrous possibility that there are chip designers within Apple that have ulterior motives and that have slipped a backdoor past development, design, QA and all the other steps required to bring a CPU to market?
On the 2nd point, the task of finding the backdoor at all is made almost impossible by the complexity of the design of the backdoor (Apple are generally regarded as good and efficient at designing secure systems) – Steve Gibson goes through some aspects of the backdoor in SN 955, and specifically why it’s close to impossible to discover it without prior knowledge. So we can quite validly assume that the attackers did not discover or identify the backdoor themselves. We may never know then how they come to access the backdoor ….
Kaspersky says:
The exploit’s sophistication and the feature’s obscurity suggest the attackers had advanced technical capabilities,” Kaspersky researcher Boris Larin wrote in an email. “Our analysis hasn’t revealed how they became aware of this feature, but we’re exploring all possibilities, including accidental disclosure in past firmware or source code releases. They may also have stumbled upon it through hardware reverse engineering.
Kasperskey
But at minimum, it could be posited that Apple was required by some agency to create the backdoor for “purposes”. Lateral thinking commence …
Overview of the attack
Details disclosed by Kaspersky on Wednesday Dec 27th, said that “Triangulation”—the name Kaspersky gave to both the malware and the campaign that installed it—exploited four critical zero-day vulnerabilities, meaning serious programming flaws that were known to the attackers before they were known to Apple. These include:
Besides affecting iPhones, these critical zero-days and the secret hardware function resided in Macs, iPods, iPads, Apple TVs, and Apple Watches. What’s more, the exploits Kaspersky recovered were intentionally developed to work on those devices as well. Apple has patched those platforms as well. Apple declined to comment for this article.
- Kaspersky initially became aware of issue due to finding Triangulation malware on their own staff devices
- Kaspersky’s researchers affirmatively and without question found a deliberately concealed, never documented, deliberately locked but unlockable with a secret hash, hardware backdoor which was designed into all Apple devices starting with the A12, A13, A14, A15 and A16
- Triangulation attackers used the aforementioned 4 CVEs in an attack chain, along with the hardware backdoor capability under discussion here, to implement their zero-day 0-click malware
The technical details (gloss over or skip this if you’re not a programmer)
IANAP (I am not a programmer), but I’ll relay some of the technical details as described by @sggrc in SN 955.
- Attackers send a malicious iMessage attachment, which the application processes without showing any signs to the user
- This attachment exploits the remote code execution vulnerability CVE-2023-41990 in the undocumented, Apple-only ADJUST TrueType font instruction. This instruction had existed since the early 90’s until a patch removed it.
- It uses return/jump oriented programming and multiple stages written in the NSExpression/NSPredicate query language, patching the JavaScriptCore library environment to execute a privilege escalation exploit written in JavaScript
- This JavaScript exploit is obfuscated to make it completely unreadable and to minimize its size. Still, it has around 11,000 lines of code, which are mainly dedicated to JavaScriptCore and kernel memory parsing and manipulation.
- It exploits the JavaScriptCore debugging feature DollarVM ($vm) to gain the ability to manipulate JavaScriptCore’s memory from the script and execute native API functions
- It was designed to support both old and new iPhones and included a Pointer Authentication Code (PAC) bypass for exploitation of recent models
- It uses the integer overflow vulnerability CVE-2023-32434 in XNU’s memory mapping syscalls to obtain read/write access to the entire physical memory of the device
- It uses hardware memory-mapped I/O (MMIO) registers to bypass the Page Protection Layer (PPL). This was mitigated as CVE-2023-38606
- After exploiting all the vulnerabilities, the JavaScript exploit can do whatever it wants to the device including running spyware. But the attackers chose to:
- (a) launch the IMAgent process and inject a payload that clears the exploitation artifacts from the device;
- (b) run a Safari process in invisible mode and forward it to a web page with the next stage.
- The web page has a script that verifies the victim and, if the checks pass, receives the next stage: the Safari exploit.
- The Safari exploit uses CVE-2023-32435 to execute a shellcode.
- The shellcode executes another kernel exploit in the form of a Mach object file. The shellcode reuses the previously used vulnerabilities: CVE-2023-32434, CVE-2023-38606. It is also massive in terms of size and functionality, but completely different from the kernel exploit written in JavaScript. Certain parts related to exploitation of the above- mentioned vulnerabilities are all that the two share. Still, most of its code is also dedicated to parsing and manipulation of the kernel memory. It contains various post-exploitation utilities, which are mostly unused
- The exploit obtains root privileges and proceeds to execute other stages, which load spyware
So the view we have from 10,000 feet is of an extremely potent and powerful attack chain which, unbeknownst to any targeted iPhone user, arranges to load, in sequence, a pair of extremely powerful and flexible attack kits. The first of the kits works to immediately remove all artifacts of its presence to erase any trace of what it is and how it got there. It also triggers the execution of the second extensive attack kit which obtains root privileges on the device and then loads whatever subsequent spyware the attackers have selected
@sggrc
What the above demonstrates is an attack group that has stunning programming and technical code capabilities. And to be clear, Kaspersky did not discover the Apple CPU backdoor themselves, they only found out about it due its use by the Triangulation malware.
Kaspersky further says:
What we want to discuss is related to the vulnerability that has been mitigated as CVE-2023-38606. Recent iPhone models have additional hardware-based security protection for sensitive regions of the kernel memory. This protection prevents attackers from obtaining full control over the device if they can read and write kernel memory, as achieved in this attack by exploiting CVE-2023-32434. We discovered that to bypass this hardware-based security protection, the attackers used another hardware feature of Apple-designed SoCs (systems on chip).
If we try to describe this feature and how the attackers took advantage of it, it all comes down to this: they are 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.
Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake. Because this feature is not used by the firmware, we have no idea how attackers would know how to use it.
Kaspersky
Steve Gibson puts things plainly here:
So let’s get this very clear because it’s an important point: There is nothing whatsoever obscure about this. The use of this backdoor required a priori knowledge — explicit knowledge in advance of its use. And that knowledge had to come from whatever entity implemented this. Period.
@sggrc
Steve is saying that the knowledge of the backdoor had to have come from Apple (assuming they implemented the backdoor, which again is the only logical conclusion). Whether knowledge of the backdoor was a leak, or intentional, is unknown.
Kaspersky has done a brilliant job of disassembling the Triangulation malware, however the source of, and reason for, the backdoor used for the initial attack vector in the malware, remains a mystery.
It’s unlikely (as Kaspersky opines) that this backdoor was left in by mistake. There are too many checks and balances, in the design and manufacturing process of silicon, for deliberate functions like this to go unnoticed.
Bugs can happen yes, but not a deliberate design, which this clearly and unequivocally is.
Conclusion
Some points to wrap up
- unless Apple fesses, we may never know the source of, and reason for, this backdoor in their CPUs
- we don’t know how the Triangulation malware attackers came to be in possession of the details of the backdoor, we do know however with reasonable surety that they would not have been able to find it themselves
- the backdoor was not accessible from firmware and was undocumented but people within Apple knew of this backdoor. They knew that this backdoor was present and they knew how to access it. And somehow that secret escaped from Apple’s control
- Apple have since patched all relevant CVEs so affected devices should now be secure from this issue
- there is nothing to stop Apple from implementing similar backdoors in future silicon as long as they can keep it a secret
- are ARM (who design/make some of the related silicon) involved?
- do other silicon manufacturers have anything similar in play?
The impact of the backdoor on Triangulation’s ability to propagate their malware can not be overstated. The backdoor was pivotal in allowing Triangulation’s malware to spawn without requiring action on an iOS user’s part. And the malware’s capabilities were impressive to put it bluntly, allowing complete compromise of iOS devices.
Kaspersky, no matter their reputation or allegiances, have done some stellar work in uncovering this issue, no matter its source or reasoning. But them finding out about the hardware backdoor may not be the obviously good thing it appears to be – involved parties now know that they need to take additional care when designing potential new backdoors; and these may never be found.