Ask Slashdot: How Does One Verify Hard Drive Firmware?

An anonymous reader writes: In light of recent revelations from Kaspersky Labs about the Equation Group and persistent hard drive malware, I was curious about how easy it might be to verify my own system's drives to see if they were infected. I have no real reason to think they would be, but I was dismayed by the total lack of tools to independently verify such a thing. For instance, Seagate's firmware download pages provide files with no external hash, something Linux distributions do for all of their packages. Neither do they seem to provide a utility to read off the current firmware from a drive and verify its integrity.

Are there any utilities to do such a thing? Why don't these companies provide verification software to users? Has anyone compiled and posted a public list of known-good firmware hashes for the major hard drive vendors and models? This seems to be a critical hole in PC security. I did contact Seagate support asking for hashes of their latest firmware; I got a response stating, "...If you download the firmware directly from our website there is no risk on the file be tampered with." (Their phrasing, not mine.) Methinks somebody hasn't been keeping up with world events lately.

Comments

Hashes not useful

[IamTheRealMike]

Seagate is correct. Putting a hash on the website doesn't improve security at all because anyone who can change the download can also change the web page containing the hash.

  The fact that this practice is widespread in the Linux world originates from the usage of insecure FTP mirrors run by volunteer admins. There it's possible for a mirror to get hacked independently of the origin web page. A company like Seagate doesn't rely on volunteers at universities to distribute their binaries so the technique is pointless.

A tool to verify the firmware is poetically impossible to write. What code on the drive would provide the firmware in response to a tool query? Oh right ..... the firmware itself. To make it work you need an unflashable boot loader that acts as a root of trust and was designed to do this from the start. But such a thing is basically pointless unless you're trying to detect firmware reflashing malware and that's something that only cropped up as a threat very recently. So I doubt any hard disk has it.

BTW call a spade a spade. Equation Group == NSA TAO

Re:Hashes not useful

[bill_mcgonigle]

Seagate is correct. Putting a hash on the website doesn't improve security at all because anyone who can change the download can also change the web page containing the hash. ... A company like Seagate doesn't rely on volunteers at universities to distribute their binaries so the technique is pointless.

There are many possible attacks. A hash on a website is not invulnerable to a rogue employee at Seagate (or one "just following orders").

A hash protects against a rouge insertion at the endpoint. Like if your PC is compromised by an attacker and then you pull the hard drive and [assuming there's a way to get a hash from SMART/ATAPI) you can compare the hash of the firmware that the drive is running to the list of published firmwares at the vendor's site. If the attackers are only modifying a small subset of drives, this works fine - they can't also intercept the check to the vendor's site - not unless they've broken TLS and/or have malware on every possible machine.

A tool to verify the firmware is poetically impossible to write. What code on the drive would provide the firmware in response to a tool query? Oh right ..... the firmware itself.

Well, today you can pull the image from JTAG, or so the experts have said (you can verify the firmware directly from memory with a hash if you have moderate funding). There's all sorts of talk about how ATAPI is write-only for firmware because the vendors don't want their competition to get their code and decompile it. This appears to be nonsense, as any other drive vendor already has the debug tools to pull such things from memory, and extracting it from an update isn't that hard - if a 16K DOS update utility can extract it, so can a multi-billion dollar R&D company.

To make it work you need an unflashable boot loader that acts as a root of trust and was designed to do this from the start. But such a thing is basically pointless unless you're trying to detect firmware reflashing malware and that's something that only cropped up as a threat very recently. So I doubt any hard disk has it.

They most certainly do not. So, here we are at today and need a way forward. There are a few ways forward, a fistful of crypto protocols to choose from to ensure future usefulness of hard drives for security applications, and INCITS/SATA-IO ought to be having emergency meetings _right now_ because this (NSA/GCHQ) is a major threat to the industry. The vendors may need to move operations outside of five-eyes to remain commercially viable.

How it's done: Link to SpritesMods.com article.

[Futurepower(R)]

Jumping to page 3 of the article in SpritesMods.com: Parts on the [hard disk] PCB: "My target was to try and compromise the security of a system by using hard disk firmware mods."

Re:We need hardware write-protect for firmware

[alphatel]

What good will physical switches do if a virus is waiting for you to flip that switch to write-enable so that it can now infect the HDD firmware? Switches would be useful if you never update the firmware. In which case, eliminate the switch and make the firmware permanently read-only. My point is, we need a more secure way to update firmware.

Unless the virus is resident in Bios, (which can also be protected in the same manner), it would be impossible to be infected if you are in a power off state, then enable your switch/jumper, power on, flash your firmware, then disable the switch/jumper after completion before booting into your OS.

In the old floppy days things were pretty much this way. Time to go back.

Re:how ?

[earthminion]

@AC, "some new trend" and "someone goes on blabbing about JTAG" ... No its not a new trend, people like you who don't really know about JTAG, have always trolled down comments they don't like (oh the irony). The fact is JTAG is about as near to a standard as we have with embedded CPUs and all developers of embedded systems know about and use JTAG. Also how do you think the initial bootloader firmware gets on the embedded systems during manufacturing? ... I'll give you a clue, JTAG.

Re:how ?

[Anonymous Coward]

No. The hard drive itself is a computer and is compromised. It doesn't matter if you boot off of it or connect it later. You can't trust anything coming out of the main interface.

Many hard drives have a secondary TTL level serial port that you can use to load new firmware on a bricked drive. It's possible that the serial connection is wired in such a way to be safe from corrupt firmware. So it might be possible to recover a compromised hard drive that way, but I wouldn't trust it without a lot more information about the serial port and how it works than is publicly available.

Seagate HDs

[BlackLotus89]

If it's about seagate hds you can take a look at seaget.With this you can dump the buffer and memory of your harddrive. Here is an explanation https://blacklotus89.wordpress... and here is the code https://github.com/BlackLotus/... Maybe this can be used to dump the firmware as well (somehow)

Re:how ?

[fisted]

Ehm, first of all, JTAG isn't only used for downloading firmware to your device, it's also a debugging interface and *very* widespread.
Second, you don't typically "disable" the JTAG interface on a released device -- what you do is set some "lock bits" or equivalent in the MCU, so the firmware cannot be read. No need to disable JTAG for that.

But sure, go on demonstrating how little you know about the matter... AC after all.

Re:how ?

[ckatko]

>But if you booted a different, known-good machine, then mounted the hard drive in question as a secondary drive, it seems feasible you should be able to read and verify the firmware.

No... no, you're missing it. The firmware isn't some magical OS. The firmware runs whenever it's connected. Not only when its booted from. Do you know what firmware is?

The firmware handles all requests. So clearly, you are requesting data from something that's tampered with, to see if it's tampered with. It's entirely possible that to make their firmware harder to catch, the firmware would only give you the "false" previous firmware data as you talk to it. Given the complexity of all of their groups viruses we've seen so far, and the fact they compress their payloads, this is not far fetched at all.

I mean, have you ever even used a microcontroller before? How do you think data gets off your hard drive?