I ran across this article from last year again and it got me thinking. The article is a story about how a hardware hacker was able to hack hard drive firmware, first to upload his own firmware, but also to take advantage of the embedded controller, and even install linux on the controller. If you haven't read it it's fairly impressive. [Ed's Comment: I would go further and say that it is a amazing piece of hacking, in the traditional meaning of the word.]
It seems that lately there have been a lot of vulnerabilities targeting embedded peripherals. Those in the article come to mind, also badUSB, and some IPMI vulnerabilities.
What do you think? Are the number of attack vectors targeting embedded peripherals a consequence of more powerful controllers? Worse software? More sophisticated attackers? Or just a random occurrence?
(Score: 3, Insightful) by kaszz on Saturday November 29 2014, @03:44PM
Microcontrollers got cheap and manufacturers of motherboards wanted to aid their design. Intel 8048 was used as the keyboard controller early on in IBM-PCs. But the firmware was read-only and cumbersome to program. The new circumstances is re-programmable memory in the form of EEPROM and more powerful MCU in the form of more RAM and faster processing unit. The second stage in this security vulnerability is that these microcontrollers have uncontrolled access to the main computing platform. And their EEPROM allows malware to survive re-installation cleanup.
The cure is to put barriers between the attached microcontrollers and the main computing platform. The second is to lock the firmware either by making it read-only or checking true checksums of all involved microcontrollers at boot and later. The latter won't work for undocumented harddrive controllers which means to stop this a redesign is really needed.
(Score: 1) by OffTheWallSoccer on Sunday November 30 2014, @04:14PM
This is why any embedded system should always have its JTAG port disabled and all firmware-update mechanisms requiring digitally signed firmware images. This particular WD drive did neither. All firmware projects I have worked on in the past ten years have had those two, and some also had encrypted FW images, so that they themselves couldn't be disassembled and reverse engineered.
(Score: 2) by kaszz on Sunday November 30 2014, @09:04PM
I think the JTAG ports should be left working. If physical access is a problem. There's worse to deal with than bad firmware. Better to require signed firmware for upgrade and let the user use the JTAG port to rescue the device or repurpose it. The big problem is that embedded devices have their firmware upgrade option open to the software side of things without any gatekeeper.
(Score: 1) by OffTheWallSoccer on Monday December 01 2014, @07:40AM
I think the JTAG ports should be left working. If physical access is a problem. There's worse to deal with than bad firmware. Better to require signed firmware for upgrade and let the user use the JTAG port to rescue the device or repurpose it.
Disabling JTAG before the device leaves the manufacturing line serves two purposes. First, it closes a big security hole -- letting someone poke around your device's memory will reveal all sorts of things, as shown by the article's author. Second, it prevents competitors from downloading the running (i.e. unencrypted) firmware *from* the device in order to reverse engineer and copy the product (in other words, IP protection).
If you need to provide a mechanism for a device to be unbricked in the field, provide a jumper that forces the device to power up into a simple bootloader that only knows how to receive a signed (preferably also encrypted) firmware image from the host.
As for a user repurposing the device, they really can't do that unless the device internals have been documented by the manufacturer or reverse engineered through security holes. Most device manufacturers aren't in the business of making repurposible (sp?) devices, so they aren't going to make it easy to do so.
(Score: 0) by Anonymous Coward on Saturday November 29 2014, @03:45PM
Put the operating system (Linux) in the firmware and everything else on the platters. It might be a pain in the ass to update but might make a faster boot and less likely for malware/corruption.
(Score: 2) by kaszz on Saturday November 29 2014, @03:50PM
And where do you get the track decoding drivers and realtime response time ensurance? or even just hardware interface documentation?
(Score: 2) by dyingtolive on Saturday November 29 2014, @10:29PM
By putting on goofy clothes and screaming "hack the planet", I'll wager.
Don't blame me, I voted for moose wang!
(Score: 0) by Anonymous Coward on Saturday November 29 2014, @04:05PM
HP made a Jornada 820 laptop without a hard drive in a similar way. http://www.winceonline.com/jornada2.html [winceonline.com] The operating system (Windows CE) and pre-installed programs was in rom, everything else was on prom or something like that. Booted in a few seconds. I have one that still works, not much software is available for it though.
(Score: 0) by Anonymous Coward on Saturday November 29 2014, @04:09PM
Forgot to mention, I put a wireless card in it to connect to my broadband.
(Score: 5, Interesting) by maxwell demon on Saturday November 29 2014, @04:27PM
That would actually a nice way to implement hidden volumes. I mean, with TrueCrypt, it is general knowledge that hidden volumes are supported. The existence of them may not be provable, but the mere installation of TrueCrypt is already a hint that hidden volumes might be present. However if you have just a stock hard disk, most people wouldn't expect hidden volumes to be even possible. If a sector reads all zeroes, then people would think it's all zeroes on the hard disk. And cloning the disk, even when removed from the original computer, would also just copy those zeroes. But thanks to hacked firmware, a secret passphrase written to a secret position in the hard disk could uncover the hidden volume, which suddenly appears where previously all those apparently blank sectors had been.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by meisterister on Saturday November 29 2014, @07:50PM
+1 this is a very interesting idea. The resources required to determine whether the hard drive even had any encrypted data would also be very expensive (if I recall correctly, services to recover data from a badly broken hard drive are in the $10k-20k range), as the controller itself would be the uncooperative part.
(May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
(Score: 1) by Wrong Turn Ahead on Sunday November 30 2014, @05:35AM
I had a laptop hard drive recovered back in 2008 and it cost ~$1100 at the time...
(Score: 3, Interesting) by Immerman on Saturday November 29 2014, @08:10PM
You could get even trickier: Take a 4GB drive and slap a 1GB sticker on it, and have the custom firmware report sizes accordingly. BAM! 3TB of completely invisible storage capacity that could be selectively mapped onto the visible 1TB when the proper secret handshake is provided.
(Score: 1, Troll) by maxwell demon on Saturday November 29 2014, @09:19PM
I'd really be interested in the firmware update that can upgrade a 4GB drive to 4TB. That could save a lot of money when buying hard disks. ;-)
On a more serious note: When replacing the sticker, you risk generating a drive that doesn't look right (if the drive you label it as looks slightly different than the one you relabel).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Immerman on Sunday November 30 2014, @03:04PM
Damn, how'd that slip through?
And yes, you are correct - but how many investigators are likely to notice the visual anomalies? I'm guessing looking at photo studies of the drive the label is from isn't part of the normal data extraction process. Especially if you throw a decoy Truecrypt volume on the visible portion to throw them off the track.
And if you could find a family of drives where the case/controller board/etc. are basically the same for several capacities, with only a few controller parameters tweaked to match the platters, then you could eliminate virtually all evidence. Unless they swapped the controller board itself out of general suspicion there'd be no way to tell anything was wrong.
(Score: 3, Funny) by frojack on Saturday November 29 2014, @10:46PM
Well, if you can make a 3TB drive from a 4GB drive you're already ahead of the game.
No, you are mistaken. I've always had this sig.
(Score: 2) by pixeldyne on Sunday November 30 2014, @10:46PM
That is a good idea but you'd also need to fake a new serial and product number, otherwise that would give it away. I don't think an investigator would bother with the label?
(Score: 2) by sjames on Saturday November 29 2014, @08:45PM
For bonus points, hold a write in cache as if the zeros had been overwirtten. That way it would withstand at least a cursory examination of the 'blank' areas.
For cases where loss of the data is more acceptable than having it discovered, let the write succeed and start wiping the encrypted volume.
(Score: 2) by maxwell demon on Saturday November 29 2014, @09:24PM
You could also reuse the spare sectors (used by the drive as replacement if regular sectors fail) for storing such test writes. Then it would even survive a power cycle, provided the written data doesn't exceed the spare sector capacity.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by davester666 on Sunday November 30 2014, @06:40AM
Well, you've already lost on the data, because it's in the hands of someone else, so it's gone. If the data was that important to you, you needed to find a better place to store it than you did.
(Score: 2) by opinionated_science on Saturday November 29 2014, @06:01PM
and raises the question of when the news stories based on "the Snowden files" will include a slide on this...
(Score: 2, Interesting) by iamjacksusername on Saturday November 29 2014, @06:19PM
The update mechanism for firmware in general sucks. Unless you are using SCCM, OpenManage, OpenView or another large management stack, trying to do firmware updates is incredibly difficult on groups of systems. Even with the management stacks, most places just put their heads in the sand on it. I mean, if you have a 1000 of a computer model, you have the resources to test the firmware update. If you have 5 of a computer model, it often costs the same (in terms of management and opportunity costs) as just pushing the update. So the answer becomes just do not do the update and hope it never becomes a problem. Which, to be fair, has been the case for a long time.
I blame the manufacturers for this mostly and Microsoft for this a little bit. Firmware updates should be managed through the OS like any other update and it is the manufacturers' responsibility to make sure that happens. Microsoft is a little to blame because they make too much money selling people software to manage updates and applications. Since people are, by nature, cheap and they do not understand the value of updating such things, every Joe and Jane manufacturer rolled their own broken software update system. And that is how we got here today.
(Score: 2) by tynin on Saturday November 29 2014, @07:04PM
A few years back we had to get our thousands of linux servers a firmware patch and the manufacturer only provided a windows based flash tool. Thank the flying spaghetti monster for PXE booting. I created an win95 boot floppy image with the autoexec.bat calling out to the patcher then shutting down. I tested it on one, then started rebooting the rest to use the firmware patching image. It is sort of comical watching win95 boot up on servers with piles of cores and RAM. Thankfully the whole thing went off without a hitch as I was dreading that I was going to brick a rack of servers if I wasn't careful.
(Score: 2, Interesting) by iamjacksusername on Saturday November 29 2014, @08:01PM
Welcome to updates on ESXi! It is like the year 2000 all over again when we had to build floppies to boot into DOS to run BIOS updates. For example, Dell has Linux images for the firmware but ESXi cannot process them. If you have Dell servers, they provide you a boot image builder so you can PXE- or usb boot each server that needs an update and run the bin image. It is not all Dell's fault - in a sane world, ESXi would natively support linux bin firmware installers or work with the manufacturers to provide a consistent API for flashing firmware so they could produce flash images for ESXi.
(Score: 2) by Arik on Sunday November 30 2014, @03:13AM
In a sane world, firmware updates would be extremely unusual, and accompanied with both a hearfelt apology and an offer to simply RMA the hardware if that is more convenient for you.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by sjames on Saturday November 29 2014, @08:52PM
Bricking is a big part of the problem. When a brick is a potential outcome, the testing must be more rigorous and so expensive and the justification to ignore updates grows larger. It is quite possible to make sure bricks can't happen, but most manufacturers fail miserably at it.
On servers, let the BMC flash the main BIOS and let the OS flash the BMC (when a jumper is set).
(Score: 0) by Anonymous Coward on Saturday November 29 2014, @09:14PM
i think real innovation comes in waves.
sure, stuff "gets better" with each new model bu the big steps are leaps and they
happen when the hardware and software used to build (mostly) hardware is deemed "old".
now the manufacturers actually uses new stuff to make new stuff and this i consider such a leap;
inbetween ... well ... they added more platters or made the display bigger or added more cores or such.
-
as for remote management "ease", people working in this field have a lucrative and secure job but,
blame it on "humanness", want it to be even less work and as long as people are hoodwinked
by centralized domain name system and generally "dumbed" down they will have a job forever managing
other peoples data on their .. farms .. in ... the .. cloud.
firmware stuff should be hard as hell to update else we are just opening the door (or giving a free pass)
for manufacturers to become sloppy.
then again it doesn't take a genius to see that "five eyes" will come in their pants (regularly) if updating firmware "thru
the network" becomes the norm and a monthly thing.
on the other hand: i wonder what they will call the people in a few years time that provide a service that
can un-officially make historical personal data disappear from the future facebook or instagram or twitter or ...
(Score: 3, Interesting) by cosurgi on Saturday November 29 2014, @10:40PM
Whoa wow, that's an amazing hack. Also I couldn't help but notice that this guy was using ROXterminal :) Which is part of my favorite desktop environment, which I am using since 1999: sawfish+rox (also I was sawfish maintainer in year 2007-2009 :)
#
#\ @ ? [adom.de] Colonize Mars [kozicki.pl]
#
(Score: 2) by cafebabe on Saturday November 29 2014, @11:41PM
1702845791×2
(Score: 0) by Anonymous Coward on Sunday November 30 2014, @09:52AM
https://www.blackhat.com/html/bh-us-12/bh-us-12-archives.html#Brossard [blackhat.com]
Scary shit.
(Score: 2) by pixeldyne on Sunday November 30 2014, @10:42PM
How would one detect this behaviour? The extra logic would slow down access times but would not be conclusive. Just swap the platters with another drive, then read the contents? I wonder if you can also de-solder and swap the memory chips from SSDs...