SSD Encryption Vulnerabilities: Osquery Identifies Windows Machine Vuln

Dark Reading and Forbes, among various other sources, have recently reported that Windows computers using the hardware encryption feature of many different types of solid-state drives (SSDs) are vulnerable to attacks that defeat it completely. These vulnerabilities, discovered by Radboud University researchers Carlo Meijer and Bernard van Gastel, affect multiple models including some made by the popular brands Crucial and Samsung.

Managing the hardware encryption of these SSDs directly is not very common in enterprise environments, but it is worth verifying your encryption process to be certain. For example, Bitlocker, part of Windows, will leverage hardware encryption by default when it is available, making your environment vulnerable even if you believe you are bypassing the SSD’s hardware encryption. Below, we'll look at how you can identify which systems are running Bitlocker, and if they've been configured to default to the SSD's hardware encryption. We'll then review some possible steps to fix configurations to remove the vulnerability for good.

Identify systems using hardware encryption with Bitlocker manually

The first way you can identify systems running Bitlocker with hardware encryption is by running the following command in an elevated PowerShell terminal:

manage-bde -status

You will then get a report on the encryption status of the drives on that system.

The interesting field is Encryption Method. If you had a system using hardware encryption, that field would report HARDWARE_ENCRYPTION.

Via osquery

Using manage-bde is a good way to individually assess the status of a system, but thankfully, osquery includes a bitlocker_info table.

That table’s encryption_method column returns the same data as manage-bde.

As such, selecting that table will return the data we want. 

select * from bitlocker_info;

As we probably do not need the rest of the data, a query built on drive_letter and encryption_method would be sufficient to give an idea of the systems impacted, and perhaps keeping device_id as a unique identifier could make things simpler as well.

select device_id, drive_letter, encryption_method from bitlocker_info where encryption_method like 'HARDWARE%';

Running this query on a distributed osquery environment like Uptycs would return a list of drives encrypted with hardware encryption. Scheduling such a query and monitoring the data over time could identify new issues popping up.

Fixing the problem for good

Now that we know what drives are affected on which system, we need to resolve the issue. Not all devices are vulnerable to this issue, and we could filter it down to SSDs where the vulnerability has been demonstrated. We believe, as do the researchers, that using the encryption software included with the operating system is safer.

Not only has it been seen by more people, but it is also easier to patch and manage. On top of that, using software encryption can leverage CPU features such as AES-NI, further enhancing the performance.

Create a Bitlocker management GPO or MDM policy

If you do not already have a policy to configure Bitlocker, create one.

Make sure you do not link it to any live systems at first.

There are many settings to configure, however, for the purpose of this article and vulnerability, let’s focus on two settings.

1. Choose drive encryption method and cipher strength - Select a cipher compatible with your security policy, as well as versions of Windows. Microsoft recommends using the XTS ciphers for fixed drives, and Windows 10 by default uses the 128-bit version. Consider using 256 if the performance impact on your hardware is small, and keep in mind you could have multiple Bitlocker policies applied to different types of systems for performance or risk purposes.
2. Configure use of hardware-based encryption for fixed data drives - Disable the configuration. This prevents Windows from leveraging the hardware encryption of underlying SSDs or HDDs.

Applying the new settings

Once your GPO is configured, you can filter it down and link it to a few test systems. Note that if Bitlocker was already active, nothing will change. New systems will be configured properly, but Bitlocker will need to be disabled and enabled for the drives to be encrypted with the new ciphers. This will require proper planning and timing, as systems that are decrypted will create a temporary risk until the process completes.

Benchmark the deactivation and reactivation of Bitlocker on reference systems, and then plan the roll-out using your favorite deployment or orchestration systems, PowerShell, or GPOs, depending on what workflow you want to implement.

While you are resolving this issue for good, monitor status using osquery until you reach your goal: 0 Windows system using hardware encryption, and all of them using Bitlocker software encryption.

If you have not yet explored osquery, or want to improve your skillset, we are now offering a free online course to bring you up to speed; which includes an interactive lab dynamic to help fortify the training.

Related osquery resources:

• Osquery: What it is, how it works, and how to use it