Cryptographic Oracles - A Practical Example
As security researchers, we sometimes view cryptographic weaknesses as more academic curiosity than practical threat. In this post, I'd like to discuss an example of a practical cryptographic oracle attack I was able to conduct to gain full access to a TrustZone secured and encrypted firmware.
A cryptographic oracle is a service that performs encryption and/or decryption on behalf of an attacker. It allows an attacker to read from or write into an encrypted system without knowledge of the encryption key. This effectively destroys the confidentiality and integrity assurances intended by the encryption.?
On to the practical example. The target device employs a secure boot Linux running on a Qualcomm ARM chipset with most of the firmware eCryptfs encrypted and keys stored in on-chip secure fuses (making the keys very difficult to extract even with specialized tooling). I say most is encrypted, but there are some areas that, either by necessity or by design, are not encrypted. This includes the kernel and a partition containing factory reset utilities. Interestingly, the device uses file-level encryption (eCryptfs) rather than full disk encryption (luks). I should also mention that the target device is used to provide secure remote access to sensitive networks. It is remotely managed and is designed to resist firmware tampering. In fact, all incoming an outgoing data transits an IPSec VPN tunnel - there are no open ports or non-VPN traffic transiting the device. So all the interesting userland binaries and config files are encrypted. There is no end-user interface for configuration and management - which severely limits our usual attack vectors.
The LineageOS folks have a good write-up on the modern Qualcomm secure boot process that is well worth a read.
https://lineageos.org/engineering/Qualcomm-Firmware/
The challenge is - how do I gain access to the encrypted firmware binaries and 'root' the system in order to gain management control? Many similar embedded devices feature factory serial debug ports used for provisioning which can be leveraged to gain access to the running system. In this case, however, the serial debug ports are disabled. Long story short, this device uses an eMMC flash to store the firmware which makes firmware extraction as "easy" as desoldering the flash and reading it out using a commodity memory reader. Albeit, the firmware is still mostly encrypted and I still don't have access to the key.
Enter the cryptographic oracle.
A very simplified Linux boot sequence looks something like this:
领英推荐
The initial ramdisk image is typically packaged with the kernel image and contains the minimum set of drivers and utilities to bring up the rest of the hardware and pivot to the on-disk operating system. In this case, the ramdisk image contains an init script with a critical flaw.
The mount_secure function, as it's name suggests, is used to identify and mount the eCryptfs directories. When it encounters a file in a directory that it expects to be encrypted which is not [1], it helpfully encrypts the file for us [2]. That's our crypto oracle!?
# [1]
? ? # check all files in directory
? ? allfiles=`find . -type f`
? ? to_rm=""
? ? for f in $allfiles; do
? ? ? ? is_enc $f
? ? ? ? rc=$?
? ? ? ? # if file is not encrypted, move to shadow dir
? ? ? ? if [ $rc -eq 0 ]; then
? ? ? ? ? ? fdir=`$DIRNAME $f`
? ? ? ? ? ? mkdir -p $sdir/$fdir
? ? ? ? ? ? cp $f $sdir/$fdir/
? ? ? ? ? ? to_rm="$to_rm $f"
? ? ? ? fi
? ? done
? ? if [ ! -z "$to_rm" ]; then
? ? ? ? # first make sure copy is written to disk, then delete original
? ? ? ? sync
? ? ? ? sleep 1
? ? ? ? sync
? ? ? ? rm -f $to_rm
? ? fi
# [2]
? ? # now mount the encrypted directory
? ? mount -t ecryptfs -i $dir $dir \
? ? ? ? -o noatime \
? ? ? ? -o ecryptfs_cipher=aes \
? ? ? ? -o ecryptfs_key_bytes=32 \
? ? ? ? -o ecryptfs_sig=$keyid
? ? # move files back from shadow dir, save encrypted
? ? cd $sdir
? ? allfiles=`find . -type f`
? ? for f in $allfiles; do
? ? ? ? fdir=`$DIRNAME $f`
? ? ? ? echo_log "encrypting $dir/$fdir/$f"
? ? ? ? cp $f $dir/$fdir/
? ? done
But how do I leverage this to gain full control of the system? This is now just a matter of identifying a candidate executable or script to overwrite that is called during startup. In this case, I chose to overwrite the /system/customer.rcS script, which is called upon the ramdisk transferring control to the on-disk init, to include a netcat reverse shell. The firmware itself does not include the netcat executable, so I cross-compiled a static executable and included it in the modified system partition of the firmware. Write to flash, solder the eMMC chip back onto the board, et voila! Without knowing the encryption key, I've managed to insert my own backdoor into an ARM secure boot firmware. With a remote root shell, I am now able to view and pull down the decrypted files for analysis as well as modify the IPSec and ACS configuration to point to my own infrastructure in order to gain management control over the device.?
Modern encryption algorithms are quite secure and cryptographic vulnerabilities often boil down to implementation weaknesses. In my opinion, the use of file-level encryption instead of full-disk encryption is what ultimately led to this vulnerability. The use of file-level encryption resulted in this crypto oracle "helper" function being included in an otherwise quite robust system.