Surviving reformats by infecting the hard disk firmware | Hacker News Reader

Surviving reformats by infecting the hard disk firmware

malwaretech.com

64 pointsgraystevens34 comments

This rootkit is designed for a major brand of hard disk and can infect the firmware from within the operating system (no physical access required), it's also completely undetectable to software running on the host computer.

Skeptical about this -- especially the claim that it's "completely undetectable". One of the projects[1] we've worked on for 01.org now ships with UEFI SCT[2], which was designed to address this very issue.

Flash LUV to a USB and run the suites.. the tests will write to a folder on the USB, both "raw" and "parsed" results, so you can essentially have a log[3] of any issues.

  [1] https://github.com/01org/luv-yocto
  [2] http://firmware.intel.com/blog/linux-uefi-validation-project-incorporate-uefi-sct
  [3] https://01.org/linux-uefi-validation

Well, run the tests against the hack and we'll see :)

Well the bootkit is undetectable to the compromised OS, but not to another OS booted safely from another boot device (such as a USB stick).

As the author explains in his slides, only the first read of the MBR will return the bootkit. Subsequent reads will return the legit MBR. So a compromised OS attempting to check its own MBR will see legit data. But an OS booted from another boot device can read the MBR one time and can immediately see the MBR contains non-standard code (eg. not the standard Windows or Grub boot loader) and can conclude it is compromised.

It's a mystery to me why, in this day and age, anyone is making firmware-upgradable hardware and not checking a digital signature on the firmware upgrade.

I mean, 20 years ago there might have been space constraints, but these days that hardly seems like a worry. So why isn't secure firmware the standard?

Or will it take some malware being publicly released to get the hardware companies to take notice?

It's a mystery to me why, in this day and age, anyone is jailbreaking their iPhone to bypass digital signature checks.

I mean, 20 years ago there might have been some benefits, but these days that doesn't really matter. So why is jailbreaking so prevalent?

Or will it take some malware being publicly released to get the customers to take notice?

There are whole categories of useful and interesting software that Apple refuses to sign.

I don't think there's any real equivalent for hard drive firmware.

That is, until people get worried that the manufacturer's signed firmware itself contains government-mandated backdoors, and an open-source effort appears...

Regardless, requiring signing for firmware goes against open hardware.

And large companies like Facebook do redesign servers. I don't know if they specifically use new hard drive firmware, but I wouldn't be surprised.

For stuff like routers and mp3 players, I've replaced firmware.

There was recently an article by facebook about how they're building/deploying a cold-storage datastore[1] which amongst other things, uses custom HDD firmware:

"The biggest change was allowing only one drive per tray to be powered on at a time. In fact, to ensure that a software bug doesn’t power all drives on by mistake and blow fuses in a data center, we updated the firmware in the drive controller to enforce this constraint."

There's been plenty of speculation that this is similar to how Amazon Glacier works - lots of mostly unpowered disks, with custom firmware.

I presume when they're buying in suitable quantity, they can get direct manufacturer support with these sorts of modifications.

[1] https://code.facebook.com/posts/1433093613662262/-under-the-...

I saw that, I just didn't remember all the details. Well anyway, that's a good counter-example. What if a smaller company wants to do the same?

There might be an argument that it should require knowing the serial number or something that's only printed on the disk, so it couldn't be done by malware.

How about having the digital signature check controlled by a physical switch on the side of the drive that defaults to "enable"? Sort of like the write protect tabs of yore.

Anyway, I wonder about the feasibility of writing your own firmware like this. The stuff is so complicated that it seems impractical to do it usefully on a production-ready level without the cooperation of the manufacturer. In an ideal world the firmware would be open source and we could tweak it as we wished, but absent that, it seems like more of an abstract concern.

The vendors are always very mindful of every cent they put in extra in the product that doesn't give a meaningful effect on the bottom line (i.e. increase sales or prevents sales from falling off).

As long as customers are buying the product and not requiring this feature it will not be made available as it will require using a 16MB EEPROM instead of the 8MB one.

I hereby claim that I will buy hard disks from vendors that sign their firmwares. And I know I'm not the only one.

That wouldn't help the situation. You and many others would have to claim that you will NOT buy another hard disk without the feature. That's a much harder claim to make, but the only way you would have n impact on bottom line.

That would infringe on the end user's right to install their own customized firmware.

Seriously though, signed firmware is something that is inevitable but also easy to delay with some shady dealing. With NSA buying a non trivial number of disks to store their illegal collections, they could easily induce disk manufacturers to put off introducing firmware signing.

You could have a physical switch on the device that lets it temporarily accept unsigned firmware.

Probably the most reasonable option really- but it would add a little bit more to the manufacturing costs, so it would probably be available on a handful of drives.

You could have a physical switch on the device that lets it accept firmware, full stop. How often does a drive's firmware get updated during its lifetime? Very slightly more than zero times on average, I would imagine.

The manufacturer may need to push updates to consumers who aren't comfortable opening their computer. The set of people who want to install alternate firmware is however included in the set of people willing to physically open a computer.

The switch could be extended to the outside of the box - shock/horror.

How hard a single pin/paper-clip button that protects all critical files unless it's depressed and when it's depressed let's you install new firmware, OS and whatever else.

It would make me feel a lot better to know that there was no mechanism by which the manufacturer (or some entity which has hacked or coerced the manufacturer) could conceivably push updates to my computer without my knowledge and consent. Write-protecting the drive controller with a physical switch would be very reassuring.

I can assure you it would be an operational nightmare for many medium to large companies to have to have technicians open up computers to flip a switch on the hundreds or thousands of harddrives whenever they need a firmware upgrade (and it's more common than you think).

See https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/ for an example of the pain of being unable to flash yourself: "An awesome contractor for Samsung agreed that if we drove over batches of drives (luckily, they are incredibly close to our datacenter) they would flash them and return them the next day."

What happens when companies get sick of having to flip the switch? They would leave it in the insecure position all the time.

> What happens when companies get sick of having to flip the switch? They would leave it in the insecure position all the time.

Okay, but how is that worse than now?

That situation sounds strictly better: things like user work stations, which tend to be the entry points to corporate network for malware stay in a higher security mode and have their HDD firmware updated less often; things like servers in racks are in the same situations, and ops continues on just live they have been.

Yes it would be better than now. But the OP was suggesting signed firmware + no switch, which would be an even better solution.

only if the idea of locked hardware you can't control doesn't bother you. I'd rather use open hardware and rely on a simple physical interlock for security. Different customers have different needs, so it would be appropriate that different products might have different security features.

What I suggested isn't locked since there is a manual override. The button is meant to allow unsigned patches, while signed patches are accepted by default. Give it three states if you want: deny all, signed only, accept all. Ship it set on "signed only" which is the default 99% of buyers want.

Nice. I like it.

The switch would need to be connected directly to the hardware that allows writing. Unfortunately I think disk drives keep their firmware on the media itself, so any attack that allows you to write on the hidden area of the disk will be bypassing the switch automatically.

That would surprise me. I have no experience with storage devices, but I used to write firmware for other embedded devices, and in my experience firmware was always stored on the NAND flash integrated into the microcontroller. Most microcontrollers either can't run code from external storage, or can't do so with any efficiency, and most microcontrollers don't have anything like enough RAM to store the whole program text.

It wouldn't surprise me to see a mechanism allowing a drive controller to reflash itself from its own storage media, but I would expect the actual stored code to live in the controller chip. Even if the storage device is an SSD, the NAND-flash chips used for storage won't be visible in the controller's address space the same way its own flash is.

Read the slides. There is a "service area" on the drive that contains additional firmware modules loaded and executed by the microcontroller: http://malwaretech.net/MTSBK.pdf

This is why all the data that goes to a hard drive should be encrypted before it gets there. No reason for the system to be trusting that the storage isn't malicious. If all the storage sees is encrypted data then the worst that it can do is fail to store the data. What it can't do is substitute malicious code for my desired code.

Maybe what could happen though is that when booting the operating system, instead of reading whatever code normally runs as the kernel launches, some malicious code could be sent to the processor instead

I'd like to see the firmware decode/encode the MBR or MBR-equivalent. Encryption only being available if someone sets a jumper on the mobo during OS installation.

The average computer has how many places to store malware outside of the filesystem?

The classics are MBR and BIOS.

These days IPMI BMC and storage device firmware are becoming popular.

However, we also have PCI device firmware (eg. GPU firmware, network card firmware), connected firewire device firmware, USB input device firmware... others?

Reply on news.ycombinator.com