Multi Vulnerabilities in Self-Encrypting Drives

Wednesday, November 7, 2018 @ 11:11 AM gHale

There are multiple vulnerabilities in implementations of ATA Security or TCG Opal Standards in Self-Encrypting Disks (SEDs), which can allow an attacker to decrypt contents of an encrypted drive, according to a report from the Software Engineering Institute, CERT Coordination Center at Carnegie Mellon University.

There is no cryptographic relation between the password provided by the end user and the key used for the encryption of user data, which can allow an attacker to access the key without knowing the password provided by the end user, allowing the attacker to decrypt information encrypted with that key.

RELATED STORIES
USB Drives Loaded with ICS-Based Malware
Triton Analysis Tool: A Wireshark Dissector
USB Drives Loaded with ICS-Based Malware
Russia Behind Triton Attack: Report

According to National Cyber Security Centre – The Netherlands (NCSC-NL), the following products sufer from the vulnerability, which has a case number of CVE-2018-12037:
• Crucial (Micron) MX100, MX200 and MX300 drives
• Samsung T3 and T5 portable drives
• Samsung 840 EVO and 850 EVO drives (In “ATA high” mode these devices are vulnerable, In “TCG” or “ATA max” mode these devices are not vulnerable.)

Key information is stored within a wear-leveled storage chip. Wear-leveling does not guarantee that an old copy of updated data is fully removed. If the updated data is written to a new segment, old versions of data may exist in the previous segment for some time after it has been updated (until that previous segment is overwritten). This means if a key is updated with a new password, the previous version of the key (either unprotected, or with an old password) could be accessible, negating the need to know the updated password.

According to NCSC-NL, Samsung 840 EVO drives suffers from CVE-2018-12038.

Other products were not reported to have been tested, and similar vulnerabilities may be found in those products.

Vendors issued patches to address the vulnerabilities.

If patches are not able to be deployed, consider the following workaround: Use software-based encryption rather than the hardware-based encryption provided by self-encrypting drives.

According to NCSC-NL, BitLocker as bundled with Microsoft Windows relies on hardware full-disk encryption by default if the drive indicates that it can support this.

To determine whether BitLocker is using hardware-based encryption or software-based encryption:
• Run “manage-bde.exe -status” in an administrator command prompt
• If the “Encryption Method” starts with “Hardware Encryption,” then BitLocker is using the self-encrypting disk’s hardware-based encryption implementation
• If the “Encryption Method” states something other than “Hardware Encryption,” such as “AES-128” or “XTS AES-256,” then BitLocker is using software-based encryption

BitLocker’s default encryption method can be controlled with Group Policy settings. Configure these settings to force BitLocker to use software-based encryption by default. Once these policy settings have been changed, BitLocker needs to be disabled and re-enabled to re-encrypt the drive with software-based encryption (if not already using software-based encryption).



Leave a Reply

You must be logged in to post a comment.