Do you like my hacking? If so, please consider leaving something in the
Fediverse (Mastodon etc): @Sprite_tm@social. spritesmods.com
While the flash mod was a good step forward, I still couldn't play out my imaginary hacker scenario: I don't think any server company accepts 'donations' of hard disks with de- and re-soldered flash chips. I needed to find a way to re-flash the chip while it was still soldered to the hard disk, preferably from the PC the hard disk was connected to.
The Western Digital firmware upgrade tools proves this is possible: it's basically a tool you run under DOS to put new firmware to both the flash and the service area aka the reserved sectors of the hard disk. According to the Internet, the tools use so-called Vendor Specific Commands to accomplish this. There are also some other tools that can meddle with the firmware: for example, there is a bit of proof-of-concept code that can use unused reserved sectors to hide away data. Finally, there's a set of tools called idle3-tools that can be used to modify a byte in the firmware to modift the idle behaviour of the hard disk. This code also uses VSCs, and does this using the 'official' way using Linux scsi passthrough ioctls. I decided to 'borrow' this code, modify it a bit and integrate it in fwtool. After some messing around and guessing VSC parameters, fwtool could all of a sudden also read and write the flash of a HD attached to the PC it's run on.
With this, my attack was complete. If a blackhat hacker had somehow obtained root access to a server with this drive, he could use fwtool to remotely dump the flash of the disk, modify it and flash it back. Eventually, the owner of the box will find out I am using his box for nefarious purposes and will probably re-install the system, securing the way the hacker orginally entered the machine.
With the firmware hack in place, however, the attacker could tell the hard disk to do something nefarious with the new install. He'd need to trigger that behaviour first, though, and that could be done by writing a certain magic string the firmware hack would look for to the disk. The magic string can be in any file; the attacker could for example upload a .jpeg-file with the string in it to the server. He could also request a file from the webserver with the magic string appended to the URL. That would eventually end up in the logs of the machines, triggering the exploit.
The hard disk firmware hack would then do something nefarious. For example, it could wait for the machine to read out the file /etc/shadow, where all the passwords are stored on an Unix/Linux system, and modify the contents on-the-fly to something the attacker hardcoded earlier. When the attacker would then try to log into the system with his own password, the machine would check this password against the now-modified /etc/shadow and the attacker would be free to login again.
Here's the demonstration I did at the presentation. You can see me try to log into the root account of the machine unsuccessfully. I then enable the hack and give it a replacement password hash, namely for the password 'test123'. Because Linux caches the shadow file (like all files recently accessed), I have to generate a lot of disk activity for the file to be 'pushed out' of the cache; that way, when I try to login again, Linux will be forced to fetch the shadow file from disk again. Finally, with the cache cleared, I can just log into the root account with the faked test123 password.