Protecting Apple Devices from the checkm8 Exploit
On September 27th, 2019, a security researcher with the twitter handle @axi0mX published an exploit called checkm8. If a combination of rare conditions and flaws in the Apple Boot ROM occur, checkm8 can bypass Apple’s secure bootchain on specific chipsets. Today's post addresses this exploit, assessing how it works, how to avoid it, and its overall risk.
What We Know About the Exploit
Expand the following drop-down menus to learn which devices are vulnerable, and how this exploit works.
- Vulnerable Devices
The following device types are vulnerable:
iPhone models up to and including iPhone X
iPad devices prior to the 2019 versions
Apple Watch Series 1,2 and 3
The exploit can only be activated on a tethered device during a restart in Device Firmware Upgrade (DFU) mode:
- Tethered Device - A device connected to a computer via USB or other cables. For checkm8, the device is tethered to a computer running the software that activates the exploit.
- The exploit can’t be activated remotely, via Bluetooth, or other over-the-air connections.
- Device Firmware Upgrade (DFU) - A mode selected during device start. The buttons used to activate DFU mode vary by device model. Since activating DFU mode requires a device restart, the exploit can only be activated during a device restart.
If the device is restarted normally or switched off, the exploit deactivates. After a normal startup, restrictions on sideloaded software get re-enforced, meaning the software won’t run.
- What Happens
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 checkm8 exploit bypasses this restriction.
Example Attack Scenario
The following scenario illustrates an attack based on this exploit and a defense against the attack:
- A user leaves their iPhone in their hotel room by mistake.
- An attacker with a laptop and USB cable gains access to the room.
- The attacker connects their computer to the user’s iPhone and activates the exploit, see above.
- The attacker loads and starts a key logger on the iPhone.
- The attacker unplugs the phone and leaves the room.
- Later, the user returns to the room and picks up their iPhone.
- Their iPhone is showing the lock screen.
- The user enters their device passcode.
- The key logger records the passcode as entered and sends it to an Internet service operated by the attacker.
Now the attacker has obtained the user’s device passcode. 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.
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.
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.
Additional Authors and Contributors
Jim Hawkins, VMware, Staff Engineer
Lucas Chen, VMware, Product Line Manager
Jason Doyle, VMware, Staff Engineer
Tom Bertling, VMware, Senior Security Architect