User data is not a bargaining chip. Apple has spent significant efforts to build its reputation by steadfastly fighting off the FBI and other law enforcement officials seeking arbitrary data collection opportunities on iPhone owners.
In 2016, Apple refused to weaken iOS defenses so that the FBI could unlock the San Bernardino shooter's iPhone. Having seized Syed Farouk's smartphone and missed ten times with a four-digit PIN code, law enforcement officers blocked the smartphone. Then the FBI demanded that Apple create a special OS in which it is possible to brute-force the security code ...
At first, things did not go in favor of Apple, the United States District Court for California sided with the law enforcement agencies. Apple filed an appeal, red tape began, and as a result of the meeting, the trial ended on this on the initiative of the FBI.
In the end, the feds got their way with Cellebrite, a private Israeli digital forensics company, for over a million US dollars . By the way, nothing was found in the smartphone.
In a strange way, four years later, history repeated itself almost exactly. In January 2020, not just anyone, but US Attorney General William Barr asked the company to help investigators gain access to the contents of two iPhones used during a shooting at a naval air base in Pensacola, Florida, in December 2019. Not surprisingly, Apple got another rejection.
It is worth emphasizing that in both cases it was not about a one-time transfer of information from Apple. This is just fine, the company transfers metadata, backups from iCloud with official and authorized requests from law enforcement agencies. The refusal is met with demands to create and provide a universal master key, a special iOS firmware that allows unlocking confiscated smartphones.
It is this circumstance that causes the greatest opposition from the Apple management and personally CEO Tim Cook, who reasonably believe that there are no and cannot be benign backdoors, and that comprehensive protection of your mobile platform is only the first freshness. A lockpick in good hands very soon becomes a lockpick in the hands of dubious ones, and perhaps it will be there from the very first day.
So, we now know that iOS does not have special loopholes created for law enforcement agencies. Does this mean the iPhone is immune to penetration and data theft?
BootROM vulnerability checkm8
At the end of September 2019, an information security researcher with the nickname axi0mX published the exploit code on Github for almost all Apple devices with A5 - A11 chips. The peculiarity of the vulnerability found is that it is at the hardware level and cannot be eliminated with any software updates, since it is hidden in the very mechanism of protection of secure boot BootROM, aka SecureROM.
The iOS boot model from Apple's WWDC 2016 presentation.
During cold boot, SecureROM is the first to run from read-only memory, which is the most trusted code in the Application Processor and therefore runs without any checks. This is the reason that iOS patches are powerless here. And it is also extremely important that SecureROM is responsible for the transition of the device to the recovery mode (Device Firmware Update) via the USB interface when a special key combination is pressed.
Switching iOS to DFU mode.
The Use-after-Free vulnerability occurs when you reference memory after it has been freed. This can lead to unpleasant consequences such as program crashes, unpredictable values, or, as in this case, the execution of third-party code.
First, to understand the exploit mechanism, we need to understand how the system recovery mode works. When the smartphone enters DFU mode, at the time of initialization, an I / O buffer is allocated and a USB interface is created to process requests to DFU. When the installation package 0x21, 1 arrives via the USB interface at the USB Control Transfer stage, the DFU code, after determining the address and block size, copies the I / O buffer data to the boot memory area.
Structure of USB Control Transfer Setup Packet.
The USB connection remains active as long as the firmware image is loaded, after which it ends normally. However, there is also an abnormal scenario for exiting the DFU mode, for this you need to send the DFU abort signal using the code bmRequestType = 0x21, bRequest = 4. At the same time, the global context of the pointer to the data buffer and the block size are preserved, thereby creating a classic situation of Use-after-Free vulnerability.
Checkm8 essentially exploits a Use-after-Free vulnerability in the DFU process to allow arbitrary code execution. This process consists of several stages, but one of the most important is known as heap feng shui , which shuffles the heap in a special way to facilitate exploitation of the vulnerability.
Run command ./ipwndfu -p on macOS.
In practical terms, it all boils down to putting the iPhone into DFU mode and running a simple ./ipwndfu -p command. The result of the action of the Python script is to unlock the entire file system of the smartphone with unauthorized access. This makes it possible to install iOS software from third party sources. Thus, attackers and law enforcement officers can gain access to all the contents of a stolen or seized smartphone.
The good news is that in order to jailbreak and install third-party software, physical access to the Apple phone is required, and besides, after the restart, everything will be back in place and the iPhone will be safe - this is the so-called. tethered jailbreak. If your smartphone was taken away from you at the border and then returned, it is better not to tempt fate once again and reboot.
iCloud and nearly secure backups
It has already been said above that in the last confrontation between the FBI and Apple over the shootout in Pensacola, the company handed over to law enforcement officers, iCloud backups from the phones of the suspects. The fact that the FBI did not turn up their nose suggests that this data, unlike the locked iPhone, was quite suitable for research.
It is naive to believe that this is an isolated case. In the first half of 2019 alone, investigators got access to nearly 6,000 full-fledged iCloud backups of Apple smartphone users 1,568 times . In 90% of requests from the state. structures, the company provided some data from iCloud, and there were about 18 thousand such requests in the same period.
This became possible after Apple quietly scrapped a project to provide end-to-end encryption of iCloud user backups two years ago. There is evidence that this was done following pressure from the FBI. However, there is also reason to believe that the refusal is motivated by the desire to avoid a situation where users, due to a forgotten password, cannot access their own iCloud data.
As a result of a compromise with law enforcement agencies and users, a mess has arisen in which it is not obvious which data in iCloud is reliably hidden, and which is so-so. At the very least, we can say that end-to-end encryption applies to the following categories.
- Home data.
- Medical data.
- ICloud Keychain (including saved accounts and passwords).
- Payment data.
- Accumulated vocabulary QuickType Keyboard (requires iOS v.11).
- Screen Time.
- Siri data.
- Wi-Fi passwords.
Anything else, including Messages , may be read by Apple employees and authorities.
New vulnerability at hardware level
A week ago, the Chinese development team Pangu Team reported that it had found a fatal malfunction, this time in the SEP (Secure Enclave Processor) chip. All iPhones with A7-A11 processors are at risk.
SEP stores key information, literally. These include cryptographic features, authentication keys, biometrics, and an Apple Pay profile. It shares some of the RAM with the Application Processor, but the other part (known as TZ0) is encrypted.
SEP boot sequence.
SEP itself is an erasable 4MB AKF processor core (probably Apple Kingfisher), patent No. 20130308838 . The technology used is similar to ARM TrustZone / SecurCore, but unlike it contains proprietary code for the Apple KF cores in general and SEP in particular. He is also responsible for generating UID keys on A9 and newer chips, to protect statically user data.
SEP has its own boot ROM and is write-protected just like SecureROM / BootROM. That is, a vulnerability in SEPROM will have the same unpleasant and fatal consequences. By combining the SEPROM hole with the checkm8 exploit mentioned above, you can change the I / O mapping register to bypass the memory isolation protection. In practical terms, this enables attackers to lock the phone without being able to unlock it.
The Pangu hackers have demonstrated that they can exploit a bug in the memory controller that controls the contents of the TZ0 register. They did not disclose all the details and source code, hoping to sell their find to Apple.
The information security researcher axi0mX, already known to us, wrote on Twitter that the vulnerability in SEPROM can only be exploited with physical access to the smartphone, as in the case of checkm8. More precisely, the very possibility of manipulating the contents of the TZ0 register depends on the presence of a hole in the SecureROM / BootROM, since after a regular boot of the iPhone, the value of the TZ0 register cannot be changed. New iPhone models with SoC A12 / A13 are not affected by the new vulnerability.
Used materials
- The FBI Wanted a Back Door to the iPhone. Tim Cook Said No
- Checkm8 exploit technical analysis
- ! checkm8
- Demystifying the Secure Enclave Processor
- Team Pangu demonstrates unpatchable Secure Enclave Processor (SEP) chip vulnerability in iOS
