Paper:

https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf

Often, I get my news from Hacker News, but the discussion isn’t that great. In this case, I think the discussion is well worth reading!

https://news.ycombinator.com/item?id=18382975

Some choice quotes:

CaliforniaKarl1 minute ago[-] Here’s what I love the most about this: If you have a full-disk encrypted Windows laptop, which is fully powered down (or hybernated), and the laptop contains PHI, _and_ you lose the laptop, then you probably do _not_ have to report it as a data breach.(https://www.hitechanswers.net/hipaa-doesnt-require-data-encr…) But with this revelation, if you have an affected SSD, and you are running Windows, then losing such a laptop may now be a reportable event.

And:

tptacek3 hours ago[-]

 

Litany of failures:* Firmware protection in drives is almost uniformly broken, so that they can get code execution (through JTAG or through hacked firmware images) routinely. This is bad, but shouldn’t be the end of the world, since in the drive encryption threat model you don’t want to have to depend on the firmware anyways. But:

* Two Crucial SSDs encrypt the drive with a key unrelated to the password; the password check is enforced only with an “if” statement in the firmware code, which can be overridden.

* Another Crucial SSD uses PBKDF2 to derive keys, but then has a master override key, which is blank by default. It also has a multi-volume encryption interface (Opal) with slots for volume keys, all of which are populated whether they’re in use or not, and if they’re not in use, they’re protected with an all-zeroes key that recovers the master key for the device.

* Two Samsung drives implement PBKDF2, but not in the default mode, which is “password is checked in an if statement, like the Crucial drive”. Also, the wear-leveling logic in one of the drives doesn’t zero out old copies of the master key, so that when you change your disk password (or set it for the first time), unprotected copies of the data encryption key are left in blocks on the device.

* The Samsung T3 portable drive uses the drive password in an “if” statement and is trivially unlocked through JTAG. Its successor, the T5, is no more cryptographically sound, but is simply harder to obtain code execution on.

People have strange ideas about what disk encryption is good for (in reality, full-disk encryption really only protects you from the situation where your powered-down, locked device is physically stolen from you and never recovered [if you get the drive back, you have to assume, at least from a cryptographic standpoint, that it’s now malicious.])

But the net result of this work is that Samsung and Crucial couldn’t even get that right. This paper is full of attacks where someone simply steals your drive and then unlocks it on their own. It’s bananas.

Side note: Look forward to a high-level overview of hard drive (spinning rust) firmware, along with some distinctions between manufacturers, model families and individual models as a joint effort with our local data recovery friends over at https://www.progressivetech.com/

Re: https://firmwaresecurity.com/2018/11/04/hackaday-supercon-2018-ken-shirriff-reverse-engineering-integrated-circuits/

slides are here:

http://www.righto.com/p/silicon.html

MicroWalk is a microarchitectural leakage detection framework, that uses dynamic instrumentation to compare a given program’s behaviour for a random set of test cases; if these execution traces differ, it tries to quantify the amount of leaked information.

https://github.com/UzL-ITS/Microwalk

https://arxiv.org/abs/1808.05575

Many WiFi access points have Bluetooth built into them now, and Bluetooth chips typically have firmware of their own.

In this case, a software stack called “BLE-STACK” that runs on a Cortex-M3 MCU.

https://arstechnica.com/information-technology/2018/11/bluetooth-bugs-bite-millions-of-wi-fi-aps-from-cisco-meraki-and-aruba/

https://armis.com/bleedingbit/

So far, it seems to impact various Cisco, Meraki and Aruba access points.

CVE-2018-7080: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7080

CVE-2018-16986: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16986

Why are there Bluetooth chips in enterprise/commercial grade wifi APs? From Ars:

The BLE chips offer a variety of enhancements to traditional Wi-Fi APs. Retailers, for instance, can use them to monitor customer movements inside stores by monitoring the Bluetooth beacons sent by the customers’ phones. Hospitals can use BLE to keep track of Bluetooth-enabled medical equipment.