Beating Bitlocker In 43 Seconds

How long does it take to steal your Bitlocker keys? Try 43 seconds, using less than $10 in hardware. Encrypting your hard drive is good security. If you’re running Windows, the most popular system is BitLocker, which has come with Windows since Vista. We’ve known for some time that Bitlocker could be defeated with direct access to the hardware. Microsoft claims that the process requires an attacker with skill and lengthy access to the hardware. [Stacksmashing] wanted to define lengthy, so he gave it a try. The result is a shockingly fast attack.

Anyone who uses Windows has probably run into Bitlocker. Your hard drive is encrypted, and Bitlocker runs silently in the background, decrypting data on demand.  The problem is key storage. In a simplified sense, encryption keys are stored in the Trusted Platform Module (TPM). When your computer boots, it reads the key from the TPM over the LPC (low pin count) bus, which is one of the last remnants of the original ISA bus.

Continue reading “Beating Bitlocker In 43 Seconds”

Bypassing Bitlocker With A Logic Analzyer

Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer and has pointed out and successfully exploited a rather obvious weakness in the BitLocker full volume encryption system, which as the linked article says, allows one to simply sniff the traffic between the discrete TPM chip and CPU via an SPI bus. The way Bitlocker works is to use a private key stored in the TPM chip to encrypt the full volume key that in turn was used to encrypt the volume data. This is all done by low-level device drivers in the Windows kernel and is transparent to the user.

TPM chip pins too small? Just find something else on the bus!

The whole point of BitLocker was to prevent access to data on the secured volume in the event of a physical device theft or loss. Simply pulling the drive and dropping it into a non-secured machine or some other adaptor would not provide any data without the key stored by the TPM. However, since that key must pass as plaintext from the TPM to the CPU during the boot sequence, [Guillaume] shows that it is quite straightforward — with very low-cost tools and free software — to simply locate and sniff out this TPM-to-CPU transaction and decode the datastream and locate the key. Using little more than a cheapo logic analyser hooked up to some conveniently large pins on a nearby flash chip (because the SCK, MISO, and MOSI pins are shared with the TPM) the simple TIS was decoded enough to lock onto the bytes of the TPM frame. This could then be decoded with a TPM stream decoder web app, courtesy of the TPM2-software community group. The command to look for is the TPM_CC.Unseal which is the request from the CPU to the TPM to send over that key we’re interested in. After that just grabbing and decoding the TPM response frame will immediately reveal the goods.

Continue reading “Bypassing Bitlocker With A Logic Analzyer”

This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!

An issue was discovered in libarchive through Google’s ClusterFuzz project. Libarchive is a compression and decompression library, widely used in utilities. The issue here is how the library recovers from a malformed archive. Hitting an invalid header causes the memory in use to be freed. The problem is that it’s possible for file processing to continue even after that working memory has been freed, leading to all kinds of problems. So far an actual exploit hasn’t been revealed, but it’s likely that one is possible. The problem was fixed back in May, but the issue was just announced to give time for that update to percolate down to users.

Of note is the fact that this issue was found through Google’s fuzzing efforts. Google runs the oss-fuzz project, which automatically ingests nightly builds from around 200 open source projects and runs ClusterFuzz against them. This process of throwing random data at programs and functions has revealed over 14,000 bugs.
Continue reading “This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!”

Breaking Disk Encryption With RAM Dumps


If you haven’t gotten a chance yet, do watch the video of this attack. It’s does a good job explaining the problem. Full drive encryption stores the key in RAM while the computer is powered on. The RAM’s stored data doesn’t immediately disappear when powered off, but fades over time. To recover the keys, they powered off the computer and booted from a USB disk that created an image of the RAM. You can read more about the attack here.

How can you reduce this threat? You can turn off USB booting and then put a password on the BIOS to prevent the specific activity shown in the video. Also, you can encrypt your rarely used data in a folder on the disk. They could still decrypt the disk, but they won’t get everything. I don’t think this problem will truly be fixed unless there is a fundamental change in hardware design to erase the RAM and even then it would probably only help computers that are powered off, not suspended.

The potential for this attack has always been talked about and I’m glad to see someone pull it off. I’m hoping to see future research into dumping RAM data using a USB/ExpressCard with DMA access.