On September 27th, 2019, a security researcher with the twitter handle @axi0mX published an exploit called checkm8, which can bypass Apple’s secure bootchain on specific Apple chipsets by making use of a combination of race conditions and flaws in the Apple Boot ROM.
What we know about the exploit
• The exploit can only be activated on a tethered device, during a restart in Device Firmware Upgrade (DFU) mode.
• Tethered means connected to a computer via USB or other cables. Software to activate the exploit would be running on the computer.
• The exploit can’t be activated remotely, nor via Bluetooth or other over-the-air connections.
• DFU mode is selected by pressing buttons on the device when it is starting. Which buttons are pressed depends on the device model. DFU mode cannot be selected without restarting the device, so the exploit cannot be activated without restarting the device.
• When the exploit is active, software packages can be loaded and run on the device by the connected computer.
• This activity, known as sideloading, is typically restricted to designated developer devices and trusted computers.
• The exploit bypasses the restriction.
• If the device is restarted normally or switched off, the exploit will be deactivated.
• After a normal startup, restrictions on sideloaded software will again be enforced, in general, meaning that the software won’t run.
Which devices are vulnerable
• iPhone models up to and including iPhone X are vulnerable to the exploit.
• iPad devices prior to the 2019 versions are vulnerable to the exploit.
• Apple Watch Series 1,2 and 3 are vulnerable to the exploit.
Example Attack Scenario
• The following scenario illustrates an attack based on this exploit and a defense against the attack.
Attack Steps
1. The user leaves their iPhone in their hotel room by mistake.
2. An attacker with a laptop and USB cable gains access to the room.
3. The attacker connects their computer to the user’s iPhone and activates the exploit, see above.
4. The attacker loads and starts a key logger on the iPhone.
5. The attacker unplugs the phone and leaves the room.
6. Later, the user returns to the room and picks up their iPhone.
7. Their iPhone is showing the lock screen.
8. The user enters their device passcode.
9. The key logger records the passcode as entered and sends it to an Internet service operated by the attacker.
Post-conditions
• The attacker has obtained the user’s device passcode.
Defense
The user could defend themselves against this attack at step 7, by restarting their iPhone. The operating system will identify the key-logger as an illegitimate sideload and won’t run it. Step 9 won’t happen and the post-conditions won’t be met.
Our Assessment
In the current state of the exploit, we believe the threat level is low and requires an opportunistic attack. This exploit is difficult to scale as it cannot be done remotely and requires physical access to the device. Despite articles referring to checkm8 as a jailbreak, it should be clarified this exploit is not a traditional jailbreak.
So far, no party has claimed to be able to use this exploit to access a device’s app data in the file system. The researcher also mentions the exploit cannot bypass Secure Enclave and security mechanisms offered by biometrics. It might be possible to access app data on a device that doesn’t have the Secure Enclave.
Our Recommendations
• For MDM enabled devices, enable device-level pin policy with appropriate complexity to ensure data on the device is properly encrypted. App-level encryption through the SDK app passcode can also be enabled to ensure application-specific data is protected even if the device level encryption layer is somehow bypassed.
• This exploit cannot be used to bypass the Secure Enclave. As such, we recommend avoiding the usage of older device hardware. iPhone 5 (released in 2012) and older devices do not have the modern security hardware components such as the Secure Enclave, which can protect data at rest.
• Remind and educate users of best practices for managing lost devices or devices suspected of tamper.
• For misplaced or lost devices, users should inform administrators or make use of the self-service portal (if available) to enterprise wipe the device.
• For devices suspected of tamper, since the exploit is not persistent, the user can restart the device to remove the exploit. The admin can also perform a reboot on the device remotely via Workspace ONE UEM console if the device is supervised and managed with Workspace ONE UEM.
• Though this exploit is not a traditional jailbreak, we recommend enabling compromised detection for vulnerable devices in case this exploit does evolve into an actual jailbreaking mechanism. Customers may also choose to make use of mobile threat defense providers in our Trust Network and their compromised detection offerings along with our API integrations to supplement coverage.
