Lately I’ve had to deal with setups which had transparent full disk encryption and were pretty hardened. If you are wondering what ‘transparent full disk encryption’ means, that’s how I call solutions that encrypt your hard disk, but don’t require any interaction from the user to boot into the operating system. They usually accomplish this because they:
- use secure boot and a TPM with key sealing (good)
- they use proprietary software-only obfuscation to hide the key (bad)
- use an external hardware device to store the keys without secure boot or key sealing (bad)
Most of the time the goal is to break out of a preconfigured application and the usual tricks like these ones, don’t really work:
However getting access to safe mode / start up repair does partially work for some of these setups:
Partially, because most of the options were not present and those that were present only gave me a cmd.exe which was disabled with a local group policy. An interesting approach the defence side took was replacing explorer.exe with an executable which did nothing. Even if you managed to break out of their application you still had nothing, no desktop, no menu, no buttons etc. For a few setups where the ‘startup-repair’ options seemed to work the encryption drivers did not load, resulting in an environment with no access to the target disk. In case you were wondering about network attacks, those were a no go as well, since the firewalls were strictly configured for ingress and egress traffic, based on ip/port/application and yes the connection themselves used TLS with client certificates and not vulnerable to man in the middle attacks.
Usually when I encounter these environment it still is possible to perform a variety of Direct Memory Access (DMA) attacks using tools like inception or pcileech. In these cases however this was physically not possible, either because there were no DMA ports available or just because I didn’t have the correct hardware with me to perform the attacks.
A common issues with all those setups however was the fact that the disk encryption software did not seal the encryption keys to a hardware security device like a TPM. This enables an attacker to create an image from the hard disk and boot this image on another computer. If the attacker also got a hold of the enclosure (USB key, smart card, obfuscated algorithm, unencrypted partition) holding the encryption keys it becomes possible to boot the disk image and fully control the victim disk in an untrusted environment.
In this blog article we are going to have a look at some of the things that you can do when you can boot a disk image of an otherwise unpenetrable environment. Please keep in mind that in part we are reinventing the wheel for two reasons:
- Learning the nitty gritty details
- Having a portable and understandable solution
There are solutions available that probably would enable you to achieve the same result, but for my personal taste I prefer to have something much more lightweight that can be easily ported between QEMU versions. Additionally you could also achieve the same result with the quick & dirty approach of booting the image in VMWare, pausing the machine, editing the memory file, resuming the machine. However I prefer QEMU since it allows full control over the entire process, due to the build in GDB server as well as customising the inner workings by editing/adding code and recompiling it. The following existing projects already wrap QEMU with cool and handy features if you want to use these type of setups to analyse malware or other applications:
Enough introduction of what we are going to do, let’s dive in and start elevating our shells to SYSTEM ;)
Continue reading “attacking encrypted systems with qemu and volatility”