This has gotten on Bruce Schneier's site now. Finally. Bruce is not talking much (hmmm...his outfit used to make hardware instrumentation intrusion detection devices, sold to BT for zillions, and now he's running another firm). But his posters are.
Nick, Dirk, Clive - those guys are connected and know what they are talking about as far as I can tell, having read their posts for well over a decade...Don't be hard on Clive for mixing up to and too - he's in the hospital using speech recog.
https://www.schneier.com/blog/archives/2015/02/the_equation_gr.html
Anybody who has done hardware dev from scratch knows about a few of these type of vulns, but we don't use them for that while developing. They are hooks for our debuggers, or just a way to have the hardware come in in-budget. A very popular example is the arduino.
It has code it jumps to on boot that knows how to burn the rest of the firmware you want to put into it. They didn't hide it (well they tell you it's there), and they made it hard to erase by accident, and in this case, you can also get your hands on it to burn "virgin" at328 cpus with the internal flash, should you want to make one from scratch, or bork one you bought. This allows anyone to put anything (eg the customer in this case) into an arduino easily, via the serial port - the chip doesn't have any native way to talk to that port without some code - and that's the "hidden stuff" in the arduino that gets invoked on power-up (and why when you write a sketch for arduino, you don't get to use all the non volatile memory - some is used for that boot loader). A disk drive operates much the same - there's a cpu, flash, ram, and opsys going in there for things like wear leveling on SSD's, bad sector detection and marking out on spinning rust, and so forth - general disk management stuff so the opsys can be presented with a "perfect disk drive" via overprovisioning of some number of "spare sectors" and only mapping in the good ones, reserving some for replacing ones that go bad.
It's those sectors, and that flash that this attack works with. Your opsys, even at the driver level,
can't even tell they are there. The only way to read back the disk drive internal firmware would be through that very firmware. No big trick to subert that, while you're subverting the rest, eh? Your opsys still sees sectors 0-n, on cylinders 0-m no matter where the actual disk blocks are physically through this mechanism, and therefore saves having to do all this itself. You could argue in this light that outsourcing this to disk was not a great idea.
But it is what it is. Same deal goes for the boot flash on every motherboard. Only worse. Most CPUs these days aren't actually shipped bug-free, and even the instruction set isn't the plain old ASM we old guys knew and loved-hated. Nope, there are "firmware fixes" for bad yielding chips that change internal CPU microcode, that in turn implements the "hardware" instruction set...understanding all this is dependent on digging into how it all works deeply enough, but we're way off the metal these days, Dorothy.
To make it easy on themselves, manufacturers made it so you can update a drive or bios firmware, which can in turn, update CPU internals, drive sector assignment (and in at least one case, some of the drive storage also contains software for the drive's CPU) later, when bugs are found after shipping it. In essence, we are and have been paying them to be their beta testers, when it was even a remotely honest world.
There are of course folks out there who downplay this, saying it's too hard. Well, sure, it's too hard to do what I do almost without thinking every day for %99.howevermanynines people. That doesn't mean there aren't hundreds if not thousands who only need the hint to pull this off in a week or so. And the motivation. I don't have that, I retired and well off. So that goes into the 9's count too. So? Didn't we just hear that someone was skillful enough and careful enough to steal nearly a billion bucks from banks via much lesser tech? There's motivation out there all right. And not just for state actors. One should not judge threat by the speed bureaucracy works. After we did our first nuke, we had the hubris to think it would take the Russians far longer, and made plans around that. We were dead wrong. They had serious motivation, and better yet - they, unlike us, had an "existence proof" - they knew there was light at the end of that particular tunnel. Saved them no end of work, and they got there quite fast - even being a state actor with the usual disadvantages over just a couple guys in a basement with the right tools (eg state actors have to have meetings and such, and set policy, so they go slower).
Worse, the code to flash a bios or a hard drive's version of the same is already out there, on the manufacturer's website, along with example code. They could hardly make a copycat attack simpler for ya. Even if you don't have their source, it's a simple matter to run it with a logic scope hooked to the hardware, see the protocol for doing it all, and you have nice, working, sample code to add your little tricks to. Yes, it's that bad, even leaving out the state actor aspect - they're not the only players out there
by far.
Be careful out there - any exploit that gains "root" or "admin" privileges can do this writing of bad-ware to disks and bios storage - and not flash up a bragging "you've been pwned" message or give any indication at all you can detect before something really bad happens. Linux is strangely not mentioned anywhere, which makes me a little nervous, as all my systems are linux here (and as far as I can tell, never infected, but then, I'm really careful). Sometimes the dog that didn't bark is the one that tells the tale in this game. I'll be checking my honeypots.
