Researchers Find Vulnerabilities in Self Encrypting SSDs

AlphaAtlas

[H]ard|Gawd
Staff member
Joined
Mar 3, 2018
Messages
1,713
Researchers from Radboud University in the Netherlands found severe security vulnerabilities in several popular, self-encrypting SSDs from Samsung and Crucial. These SSDs can encrypt and decrypt data coming in and out on the fly, which is seen as a "hardware encyption" option in Bitlocker on Windows systems, but the researchers highlighted several ways to bypass this encryption without a user password. Vendor-specific commands, memory corruption, storage chip communication exploits, and (theoretically) fault injection attacks can all be used to run unsigned code, and gain control over the SSD's data. The full research paper can be read in the original article, and the researchers recommend using software encryption over hardware encryption in general. Samsung and Crucial were notified in April, and Samsung already has a consumer notice on their site.

The researchers identified these security issues using public information and around €100 of evaluation devices. They bought the SSDs that they examined via regular retail channels. It is quite difficult to discover these problems from scratch. However, once the nature of the issues is known, there is a risk that the exploitation of these flaws will be automated by others, making abuse easier. The researchers at Radboud University will not release such an exploitation tool. The models for which vulnerabilities have actually been demonstrated in practice are: Crucial (Micron) MX100, MX200 and MX300 internal hard disks; Samsung T3 and T5 USB external disks; Samsung 840 EVO and 850 EVO internal hard disks. It should be noted, however, that not all disks available on the market have been tested. Specific technical settings (related to e.g. "high" and "max" security) in which internal drives are used may affect the vulnerability.
 
Been saying for years now: nothing is private, nothing is secure, it hasn't been for a long time and even in spite of "new" exploits like this one being discovered all the time by some creative thinkers who go way outside the boxes they happen to think they're caged in we'll never have actual privacy or security ever again.
 
Best practice; never trust a black box.
... Racist ....

Just never trust any box why does it have to be black huh.... Jokes aside don't even trust boxes you assembled yourself because honestly no matter how good you may be somebody out there is better and guaranteed if they want in they can spend more time on attacking your security than you can spend defending it.
 
Amazing and scary how many computers are in your computer. Incomplete list: Each HD/SSD, HD controller(s), Video card(s), Sound chip, network interface, MB management unit, USB controllers. I call them computers since they accept input, modify it, and output it, have a control chip, firmware and OS drivers.
 
I was under the impression that drives with built in encryption were never intended to protect the data while it is on there.

The drive based encryption is typically only used as a fast way to secure erase drives.

Encryption Key resides in firmware. When SMART secure erase command is issued to drive, rather that repeatedly overwriting the drive with garbage data for days, it just wipes the encryption Key and replaces it with a new one.

Voila, drive is instantly unreadable, and since the key has been wiped, even if someone gains access to the firmware they can't recover it.
 
So what's recommend best practice for external HDD?

Linux has a lot of goof full disk encryption tools. No idea about windows though.

I should note, I've never bothered with either. I've never lost a disk, and don't plan on it.
 
"hardware" encryption is the same as "hardware" RAID, it's just software running on dedicated ICs. If it's not updated regularly like we normally update software, then there's no real expectation of total security.

Surprise surprise, it sucks. Who's really, actually, surprised here?

Not me.
 
I was under the impression that drives with built in encryption were never intended to protect the data while it is on there.

The drive based encryption is typically only used as a fast way to secure erase drives.

Encryption Key resides in firmware. When SMART secure erase command is issued to drive, rather that repeatedly overwriting the drive with garbage data for days, it just wipes the encryption Key and replaces it with a new one.

Voila, drive is instantly unreadable, and since the key has been wiped, even if someone gains access to the firmware they can't recover it.

Actually, apparently that secure erase can be hacked around too.

Like the shit that is being pointed out in this report is just downright hilarious and sad. The complete lack of anyone with any idea how to implement cryptography working on a supposed secure crypto-system is just insane.
 
"hardware" encryption is the same as "hardware" RAID, it's just software running on dedicated ICs. If it's not updated regularly like we normally update software, then there's no real expectation of total security.

Surprise surprise, it sucks. Who's really, actually, surprised here?

Not me.
That's true. It's a meager "value add" feature to try and justify the high cost of business class PCs. If you want anything that approximates "data security", it needs to be done via software at the filesystem level and using external keys. Assuming the system's hardware isn't already compromised via some "security" subsystem. ;)
 
Been saying for years now: nothing is private, nothing is secure, it hasn't been for a long time and even in spite of "new" exploits like this one being discovered all the time by some creative thinkers who go way outside the boxes they happen to think they're caged in we'll never have actual privacy or security ever again.
Until the bombs fall anyway.
 
Actually, apparently that secure erase can be hacked around too.

Like the shit that is being pointed out in this report is just downright hilarious and sad. The complete lack of anyone with any idea how to implement cryptography working on a supposed secure crypto-system is just insane.


You would need to plan this attack carefully. Essentially, break into a system firmware, steal the current key, and then sit on that key until you can get your hands on the disk so you can reinsert the key and read the content on the disk.

If you have access to the system - however - why wouldn't you just steal the data directly?

The only way I could see this effectively being used is if you get into the supply chain - CIA style - read the key before the disk is delivered and hope that whomever installs the disk doesn't do a secure erase (replacing the key) before they use it, and only secure erases it after use. Then you can reinsert the key and steal the data of the disposed of drive.

But if you can do this, maybe it would be more effective to replace the firmware all together so it always uses the same key, or something like that.
 
You would need to plan this attack carefully. Essentially, break into a system firmware, steal the current key, and then sit on that key until you can get your hands on the disk so you can reinsert the key and read the content on the disk.

If you have access to the system - however - why wouldn't you just steal the data directly?

The only way I could see this effectively being used is if you get into the supply chain - CIA style - read the key before the disk is delivered and hope that whomever installs the disk doesn't do a secure erase (replacing the key) before they use it, and only secure erases it after use. Then you can reinsert the key and steal the data of the disposed of drive.

But if you can do this, maybe it would be more effective to replace the firmware all together so it always uses the same key, or something like that.

Apparently some of the devices store the password and then store the encryption key. They do a check vs the password and if that works, they then use the key. In addition, several of the devices store the key in multiple places (so that if you wipe by accident, the device can still be factory recovered via jtag). They don't wipe the key, instead they wipe the password, but the key is still there. It all goes back to one of the fundamental problems, instead of the key being a secure cryptographic hash of the password, they are not linked and completely independent.

This why this story in the security community was met with almost WTF since the secure in these cases is so fundamentally flawed and so incorrect that even someone who's been through security 101 would find it laughable.
 
Back
Top