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!

The process for starting a computer has many stages. With UEFI, the process is a little more streamlined but is still quite verbose. After the initial bootloader, the UEFI bootmanager is launched. From there, the OS and many other things can be launched properly.

The partition for the boot manager (EFI file) is stored in a FAT file system. Because of this, they do not have ACLs or any security information on the files. In order to account for this issue with the EFI partition, Windows does behind-the-scenes magic to ensure that the EFI partition is not overwritten.

The problem comes down to how these protections were put in place. As stated before, Windows does behind-the-scenes magic to ensure that the partition is not overwritten. But, this magic is likely hard to implement.

The protections extend to not mounting the EFI System partition; the OS simply rejects this from happening. As it turns out, an attacker can call the CreateFile and specify the partition in this API without mounting the drive.

The first problem is that the GUID of the volume is random. Using FindFirstVolume and FindNextVolume, enumerating the volumes can find the GUID for the EFI volume.

The call to GetSecurityInfo results in a file descriptor. Sadly, any attempts to open the file for reading or writing result in access denied. So, Microsoft thought about a lot of these things!

Although this seems counter-intuitive, the key is to not request any access. Instead, call CreateFile with no permissions but specify CREATE_ALWAYS. This flag will truncate the file to a size of zero, if it exists, prior to opening the file.

Here's the problem: the access check does not happen upon the CreateFile call; it happens only when the handle is created. By making this call, it will open up the EFI partition and wipe it!

This attack ends up being a denial of service and nothing else. But, it completely destroys the computer. When trying to demonstrate impact, the authors had issue reproducing the issue depending on the virtualization platform being used.

The law of chromatic superior is something that I really stick to while testing. If two things act differently, then they must be different! With security testing, this means that two things are implemented differently, meaning they should BOTH be tested. If two pieces of functionality do the same thing in theory, there's a good chance that one of them is implemented poorly, leading to a security bug.