VBootkit vs. Bitlocker in TPM mode
So at HITB in Dubai this week - some researchers announced a proof of concept 'bootkit' for Vista. A bootkit is a rootkit that is able to load from a master boot record and persist in memory all the way through the transition to protected mode and the startup of the OS. It's a very interesting type of rootkit.
eEye's 'Bootroot' was the first bootkit that I am aware of for Windows and you could load it by booting a machine off of a CD or Floppy or PXE device. Literally that was all it took to get 0wn3d. You walk up to a machine, insert the CD, hit the reset button - wait for the CDROM light to go off and then eject the CD and walk away. The whole attack usually takes less than 30 seconds. Think about how powerful something like that could be in a typical office or cube farm when an employee leaves his machine to go get coffee? Bootroot also patches the MBR on the HDD after loading from the CD's boot record so that it could persist reboots from the main HDD in the system. When the victim comes back to their PC and sees their PC has been rebooted - they may just think it bluescreened or there was a brief power loss resulting in a reboot.
Well the new 'VBootkit' (and there is some controversy - many believe this work is based heavily on eEye's bootroot code) for Vista works in essentially the same way - but it doesn't appear to patch any of the on disk binaries - once it is read from the boot record of the CD or PXE device it goes memory resident and patches up key parts of memory (starting with hooking INT13) throughout the boot process to maintain stealth. It includes some interesting new kernel 'shellcode' (as they call it) that periodically (every 30s?) elevates any instance of CMD.EXE that it finds to give it SYSTEM rights by pointing the token member of the EPROCESS block for a given instance of CMD to the token used by the 'services.exe' process (I bleieve).
So I had an interesting discussion with a former Bitlocker Drive Encryption (BDE) Sr. SDE (Software Development Engineer) this morning (Jamie Hunter) about whether BDE would mitigate these types of attacks if used properly and I'm very pleased to announce that it does!! This is a threat that the BDE team definitely anticipated and actively planned for!
Before explaining how BDE mitigates this attack the following picture may help set some context for the scenario.
This is what a 'normal' OS boot from a hard drive looks like when BDE has been configured to use a TPM 1.2 module.
(NOTE: There may be some slight innacuracies in the 'All boot blobs unlocked' column according to Jamie but they aren't really important for the concept I'm trying to illustrate. :))
When BDE is enabled in TPM 1.2 mode each of the steps in the PreOS and StaticOS phases depicted above is being 'measured' by the TPM and the results of these measurements are stored in PCR[4] of the TPM module. This is described by Jamie in his blog on multi-boot security here.
From his blog:
"In "Early Boot", all boot components write values (measurements) to the TPM as the boot process proceeds. An example of this is that the BIOS will measure the boot code in the MBR, and write this to PCR[4] of the TPM. If the MBR is correct, the correct value will be in PCR[4]. If the MBR has been modified, the wrong value will be in PCR[4]. In either case, the MBR (legitimate or malicious) will be measured and will be executed. The TPM accumulates these measurements in a manner that cannot be undone unless the hardware is reset. It is important to ensure that all measurements are correct (therefore no modification to code) to successfully have the necessary PCR pre-conditions to allow the TPM to unseal the VMK.
In "Mid Boot", the time comes where the VMK is required to transition from "Mid Boot" to "OS Boot". BOOTMGR communicates with the TPM sending it a block of data previously encrypted by the TPM, and requests that the TPM decrypts the block of data. The TPM checks the values of PCR’s along with the values and policy conditions encoded into the block of data. The TPM also verifies the MAC (Message Authenticity Check) to ensure that the block of data was not tampered with. A legitimate BOOTMGR can obtain VMK, or know that it cannot obtain a VMK. A modified BOOTMGR will only know that it cannot obtain a VMK. If the VMK cannot be obtained, then there is nothing the modified BOOTMGR can do to open the black box. It is obvious therefore that the legitimate BOOTMGR must be used to retrieve the VMK at this point."
In a VBootkit system boot - I believe the boot process flow looks like this (any mistakes are mine)
In the picture above - you can see that the boot process has been detoured a bit by the presence of a Vbootkit CD causing an additional MBR to be read during the OS boot (this MBR presumably then jumps back to the one on the HDD after hooking INT13).
Well it is my understanding, based on my discussion with Jamie - that this will cause BDE in TPM mode to fail to boot the OS because the 'measurements' stored in the PCR in the TPM will be incorrect or will be unexpected in value - which will cause the TPM to fail to unseal the VMK which will lead to a boot failure.
What this all means is that when the boot manager (BOOTMGR.EXE) goes to unseal the VMK stored in the TPM 1.2 module - the TPM will respectfully decline. :)
It would appear that all the user would have to do to resolve this (assuming the MBR on the HDD hasn't been altered - as is the case with VBootkit) is reboot the machine (as presumably the attacker would have removed the VBootkit CD from the CDROM drive and walked away) to proceed down the proper boot path allowing the expected measurements to accumulate in the TPM leading to it unlocking the VMK for the user so that he can decrypt the volume and boot Windows.
Can't wait to test this out to see if it works as advertised. :) I may have to wait a while - the researchers haven't released a version of the VBootkit that works on RTM builds - let alone x64 builds.
Comments
Anonymous
January 01, 2003
"So at HITB in Dubai this week - some researchers announced a proof of concept 'bootkit' for Vista. AAnonymous
January 01, 2003
This week there's been a lot of hype about vBootKit, which resulted in a general conversation about expectationsAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Beaucoup de bruit récemment autour d'un rootkit s'installant dans le MBR. Analyse de Symantec AnalyseAnonymous
January 01, 2003
Na konferencji Hack In The Box zaprezentowany został VBootkit2 (materiały konferencyjne), w rezultacie czego można przeczytać tego typu informacje: Researchers show how to take control of Windows 7, albo Windows 7 z nieusuwalnym exploitem (autor artyAnonymous
January 01, 2003
One of the guys in our group, Robert Hensing has an interesting post about VBootkit and whether BitLockerAnonymous
January 01, 2003
Over the past few weeks I’ve been reading a few stories on vulnerabilities found in various operating