Breaking bitlocker again
It is rare that anything new happen in the world of itsecurity- its mostly just an endless cycle of variants of the same vulnerabilities being exploited again and again.
Thats why I appreciate when something new happen, and the yellowkey exploit was for once an attack I havent seen before.
I have myself done a bitlocker bypass before()- but this one was new to me.
It expanded the attack surface onto an area I had not looked into before- the recovery enviroment.
The recovery enviroment is stored on a partition that bitlocker do not encrypt and the tpm is not locked untill you use any functionality thats not the startup repair.
If you somehow get code running without causing the tpm to lock, you have access to the encrypted drive.
Microsoft killed yellowkey by removing the autoexecution of a newly introduced component- that could be manipulated into doing file operations by rolling back a transaction stored on a usb drive.
I suspect they copied the recovery enviroment from the unreleased Windows Cloud made for thin clients- that also explain why the bare metal recovery efi image identify as Windows 365 when downloading what to boot on its ramdrive from the Microsoft server.
The transaction rollback enabled a file deletion- enabling launching a command prompt by holding down control when launching recenv.exe- an elegant attack.
So when my friend asked if I wanted to help try and restore the vulnerability- I figured why not give it a try.
Microsofts fix is just killing a specific vulnerability but not the underlying design issue- so id be surprised if it wasnt doable.
After 24 hours a new attack was born- I call it bitskrieg.
Lets walk through it:
We start with a windows 11 virtual machine, secure boot enabled, vbs, tpm and bitlocker on the c: drive.
We skip the Microsoft Account requirement during install by pressing shift+F10 and typing: start ms-cxh:localonly
Isolated core enabled and a padlock on the drive.
We set an administrator password that is to be considered unknown to a potential attacker.
The security boundary we want to cross is then retreiving the bitlocker encrypted files without any valid credentials.
The boundary is applicable both with physical access and in the cloud as a virtual machine.
The protection is based on:
The TPM will hash the execution sequence prior to arriving at the login screen- only when it have not changed it will unlock.
That is why we cannot simply boot from an usb drive and have it unlock- the booting sequence will then differ and the tpm refuse to unlock the drive.
Lets first test what happen if we try to use the boot menu:
Allright- now lets break it, first we hold down shift while restarting at the login screen twice.
Select troubleshoot, advanced options then command prompt.
We get a screen saying that the c: drive is locked, thats fine - choose skip this drive and input:
bcdedit /set ems 1
bcdedit /set emsport 1
then do on the host:
Set-VMComPort vmname comportnr \\.\pipe\bitskrieg
Now, close the command prompt in the vm and select shut down.
Power on, then again we hold shift while selecting restart twice.
We end up at this screen:
Now on the host start putty as admin and open:
\\.\pipe\bitskrieg using a serial connection
We should see:
Press enter, input cmd:
Press esc, tab- then enter:
We now have full access to the decrypted harddrive:
Want to publish your own Article?
Upgrade to Premium