Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Full disk encryption for an unintended computer is a surprising difficult problem to solve. A classic way of doing this is using a TPM to store an encryption key but only having the encryption key accessible if the computer is in the right state via policy sessions. Because of the policy, it's not possible to modify the running code. Because of the FDE, it's not possible to modify the file system, making for a secure system.

The above approach has a problem with bus sniffing to get the key but working very well otherwise.

An unattended disk encryption setup still allows a user to view the output of the boot process or manually enter the key if something goes wrong. Usually, a screen is presented for interacting with this functionality but quickly goes into the boot process if the TPM is active and working.

In the automatic flow, there is room for logic bugs. If an attacker can interact with the system after decryption but before the full load of the OS, then they could cause havoc.

In 2016, Debian's cryptsetup startup script allowed for holding the ENTER key to gain root access to an early boot environment. Since this was post decryption, an attacker with a root shell could modify the file system or do whatever they want to compromise the system.

The author decided to perform fuzzing to see what would happen. This was using an Atmel Microcontroller to enter key presses very fast, in a similar way to a rubber ducky. The program pressed the ENTER key every 10 milliseconds, which is much faster than just holding down the key on a keyboard.

By doing this, the key presses restrict the auto decryption and autoboot from happening. Because of all the failures, it goes into a recovery mode with a root shell in an early boot env. Once there, we can call basic TPM commands to decrypt the drive, bypassing the FDE.

Why does this occur? It's super complicated. An agent plugin is used for systemd with a pool of different responders from these plugins. When using both dracut and clevis at the same time, Clevis implements a systemd password agent for unlocking, but the user may also enter a password using the normal interactive agent. For whatever reason (which I don't fully get), this puts it into a very weird state that drops us into an emergency shell at the end.

A super interesting flaw in the low level process. It's fascinating that simply pressing enter can bypass the boot process. This architecture seems to be at fault; I'd wonder if similar types of bugs exist in this system from this design.