By Terry Gold, founder, IDanalyst LLC.

Full disk-encryption is viewed by some enterprises as a cure all for laptop security. Many organizations have requirements that at least some systems be encrypted – especially those that are used by individuals that might have access to sensitive and/or proprietary information. Taking things a step further, many organizations are moving towards a model where all of their corporate-owned laptops are encrypted by default.

When full-disk encryption is deployed, it is assumed to be a black-box panacea for all data security issues. Like any tool or system designed for security, however, full-disk encryption is by no means bulletproof. Unfortunately, full-disk encryption is often implemented but rarely verified or tested. The vulnerabilities, configuration oversights and potential weaknesses of different technologies and implementations are only infrequently discussed and worse still, are rarely understood.

Terry Gold caught up with Tom Kopchak, a security researcher with Hurricane Labs, who demonstrated at Security B Sides in Las Vegas how he was able to subvert a popular full-disk encryption product in just a few minutes. Tom states that he did this because “one of our customers was interested in having us evaluate the security of their full disk encryption deployment as part of their regular penetration test schedule.”

Multi-factor authentication solutions, such as smart cards, can be used in conjunction with full-disk encryption for a better, more secure solution.

What were you expecting to find going into this engagement?

I did not necessarily expect there to be any groundbreaking findings for this test, as the prospects of gaining access to a fully encrypted machine without any ancillary information seemed very unlikely. I am confident that anyone in my position that had been asked to do the same testing would have felt similarly.

What were your initial thoughts on strategy and how did you decide to approach the test?

The objective of the penetration test was to simulate an attack on my client’s encrypted data and ultimately see if and how I could be successful in decrypting it given the controls that they had in place. I decided to approach the entire penetration test as a forensic investigation. This was done to preserve the original state of the machine as evidence, which proved to be a critical step in the overall success of my work.

Before we get into details, can you highlight your technical approach?

Using drive images and a forensic writeblocker, I was able to use several hard drives to create physical snapshots of the machine. After the initial drive image, the source drive remained untouched – and for all intents and purposes uncompromised. All of my work was performed on a series of scratch disks.

And ultimately, what did you find?

Well, I was able to accomplish the objective. Further, I was able to take it from several hours down to just a few minutes. Also, moving away from reliance on knowledge-based credentials for Windows Login, such as passwords, can mitigate the attack. In part, going with a hardware token with PKI could have helped stop this particular attack.

Tell us about how you simulated the attack?

The first stage of the test was reconnaissance; much like an actual attacker would approach an unfamiliar machine that they had obtained. The physical hardware was a standard business laptop, with normal interfaces — USB, serial, FireWire, PCMCIA, etc. I was also able to gather some information about the encryption products being used based on the startup prompts when the machine was powered on. Beyond that, there really was not much other information at my disposal to help with the assessment – so I needed to get creative.

Initially, the chances of success looked grim. The machine would display a pre-boot authentication prompt when powered on, requesting credentials to proceed with the bootup process. I am not entirely sure if this was just a hunch or if the wording on any of these pre-boot authentication screens hinted at expiration or re-authentication, but at some point, I decided to re-image the machine and experiment with manipulating the system clock. That is where things started to get interesting.

Based on when we acquired the machine, I was able to take an educated guess on when the system was last successfully used. I selected times close to this window to see if the system behaved any differently. To my complete surprise, there was a change — a message was displayed stating that access to the system would be locked in the next day if a connection to the central server was not established. Once I acknowledged this message, Windows started to boot. I could not believe what I was seeing.

Once the operating system loaded, my target changed from the encryption to the operating system, which was the newly uncovered weakest link. The presence of a functioning operating system means that decryption is taking place – it did not matter that the data on the disk was encrypted. When working with an encrypted system, memory forensics techniques can be very helpful.

I was able to leverage a technology called direct memory access, which permits access to the lower 4 GB of system memory independently of the CPU. This allowed me to dump the memory of the system over the firewire bus, and use a tool to modify the running contents of memory to bypass the password verification code in the operating system. This allowed any password to be accepted as valid for the administrator account on the machine.

If an organization were to use stronger credentials for access to the machine, would this have prevented you from reaching your objective?

Depending on how the system was configured, yes.

What are your recommendations for organizations looking to deploy or enhance their full-disk encryption environments to be more secure?

Enforce Pre-boot authentication: Pre-boot authentication is absolutely mandatory – on every boot. As I demonstrated, if there is any window where pre-boot authentication is not required, that window can be discovered. Once the operating system loads, the presence of encryption is often a non-issue. By far, this is the most important step towards protecting your encrypted systems and data. Also, by leveraging a hardware token using PKI, say a smart card, and it was authenticating the certificate at pre-boot, and then again at Windows login — while disabling CTRL+ALT+DLT so a password cannot be used — would have given me serious problems.

Disable direct memory access interfaces: Laptops come with many direct memory access capable interfaces, and these are typically enabled by default. In my test, the DMA interface used was Firewire, but other interfaces such as PCMCIA and ExpressCard can be used as well. All modern operating systems support plug and play and will allow device drivers to be loaded automatically when a system running a memory acquisition tool is connected. More often than not, these interfaces are not typically used, and can be disabled in the BIOS with minimal to no impact. Disabling these interfaces prevents an attacker from accessing the memory of a powered on system that is left unattended.

It’s not specific to this vulnerability, but there are some recurring themes that can easily be in scope when getting to data on machine.

Hibernation modes: Both standby and hibernation allow a system to be powered on without pre-boot authentication being required. There are also tools on the market that enable an attacker to get encryption keys out of memory. In most cases, both should be disabled as a reasonable step to prevent a system from being stolen in a state that gives the attacker an advantage.

Memory exploitations: Procedures should be reviewed and mitigated as part of a pre-deployment review process. Hackers will almost always explore this as low hanging fruit.

Getting around Windows authentication: This is not very hard to do, and there are multiple methods that can be used to circumvent Windows authentication. Although some passwords are stronger than others, there are several techniques that can be used to circumvent even a strong password.

What advice can you give to organizations considering full-disk encryption?

• Testing and verification is the best option for securing full-disk encryption. Do not assume a given solution is secure out of the box, or that the default settings are optimal.
• As for policy, powered-on machines should never be left unattended.
• Whenever possible, have your implementation verified by an independent third party. Someone who is both familiar with full disk encryption security concerns and not associated with the vendor whose solution you are deploying should perform this assessment.

Any advice for vendors?

Customers trust vendors to provide a data protection solution. Vendors need to be aware of the vulnerabilities in their products and any configuration options that may put their customers’ data at risk. When possible, settings that reduce the security of an implementation should have clear warnings of the risks associated with these selections.

What should be learned and what action do you hope will come from this?

I do not expect that we will see a dramatic, overnight change in how full-disk encryption is deployed, managed and verified. But I am hoping that this technology is more thoroughly reviewed and verified, and that organizations begin to take additional measures to further protect their data. Even small steps can make a big difference towards protecting sensitive data. In the end, it is a benefit for everyone – both organizations that must protect data as well as their customers and employees.

What is Hurricane’s next step in this?

Education is critical. As part of this research and my presentation, I have been working to draw attention to this often overlooked aspect of an organization’s defenses. We have seen an increased interest in this type of verification from our customers as well – many of them are looking at full disk encryption differently as a result.

For more  information? Visit Hurricane Labs expanded briefing at: https://hurricanelabs.com/fde/