Huang: On Hacking MicroSD Cards [LWN.net]

Worth a read: this posting by Andrew "bunnie" Huang on loading new firmware into a MicroSD card. "From the security perspective, our findings indicate that even though memory cards look inert, they run a body of code that can be modified to perform a class of MITM attacks that could be difficult to detect; there is no standard protocol or method to inspect and attest to the contents of the code running on the memory card’s microcontroller. Those in high-risk, high-sensitivity situations should assume that a 'secure-erase' of a card is insufficient to guarantee the complete erasure of sensitive data."

to post comments

Huang: On Hacking MicroSD Cards

Posted Dec 29, 2013 23:29 UTC (Sun) by deconfliction (guest, #94407) [Link]

Finally people are starting to be paranoid enough. I remember it wasn't so long ago I was scratching my head (or pulling out my hair or something) thinking about these words applying to my common home internet router-

"From the security perspective, our findings indicate that even though s/memory card/router/s look inert, they run a body of code that can be modified to perform a class of MITM attacks that could be difficult to detect; there is no standard protocol or method to inspect and attest to the contents of the code running on the /memory card/router/’s microcontroller."

Huang: On Hacking MicroSD Cards

Posted Dec 30, 2013 0:47 UTC (Mon) by csamuel (✭ supporter ✭, #2624) [Link] (2 responses)

There also appear to be attacks against firmware in more usual hard disks (and BIOS's) too according to this article in Der Spiegel reviewing an NSA catalogue, talking about persistence of attacks:

The ANT division doesn't just manufacture surveillance hardware. It also develops software for special tasks. The ANT developers have a clear preference for planting their malicious code in so-called BIOS, software located on a computer's motherboard that is the first thing to load when a computer is turned on.[...]

Another program attacks the firmware in hard drives manufactured by Western Digital, Seagate, Maxtor and Samsung [...]

Huang: On Hacking MicroSD Cards

Posted Jan 2, 2014 5:51 UTC (Thu) by Gollum (guest, #25237) [Link] (1 responses)

Check the blog post by Jeroen at spritesmod where he boots Linux on the controller of his hard disk, plus backdoors the disk to return chosen contents for /etc/shadow on demand.
On my phone, so can't provide a link, I'm afraid.

Huang: On Hacking MicroSD Cards

Posted Jan 2, 2014 6:11 UTC (Thu) by foom (subscriber, #14868) [Link]

http://spritesmods.com/?art=hddhack

Very nice!

Huang: On Hacking MicroSD Cards

Posted Dec 30, 2013 11:49 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

I have had a microSD fail on me by becoming read-only, but not saying so. It could be mounted read-write, as long as I used it it would behave quite normally, I could even re-format it (in a different filesystem, even), but after ejecting and reinserting it all changes would be lost -- it would show in the same state as on a certain date, with all data of that date intact and nothing afterwards registered. I couldn't do anything with it and just backed it up and threw it out.

Huang: On Hacking MicroSD Cards

Posted Jan 6, 2014 11:55 UTC (Mon) by njwhite (guest, #51848) [Link]

I had that happen with a cheap USB stick. I decided to make it a slow removable swap device for my netbook, and it has continued to work in that mode (where persistence between plugging in isn't needed) for 3 years now :)

ubifs/jffs2?

Posted Dec 30, 2013 13:16 UTC (Mon) by giggls (subscriber, #48434) [Link] (6 responses)

I wonder if using this hack it will get possible to implement a simple pass-trough mechanism which will allow for running ubifs or jffs2 on top of the Flash-memory located inside Micro-SD Cards.

ubifs/jffs2?

Posted Dec 30, 2013 23:36 UTC (Mon) by flewellyn (subscriber, #5047) [Link] (5 responses)

Yes, I too was wondering if this capability could be used for good as well as for ill.

I'm picturing updating the algorithms to better account for media defects, or to improve other aspects of the storage system like wear-leveling and maybe even compression. Or encryption? I don't know, just conjecturing here.

ubifs/jffs2?

Posted Dec 31, 2013 21:29 UTC (Tue) by hamjudo (guest, #363) [Link] (2 responses)

It would only be useful over the long term, if there are plans for a long term, predictable supply of media which supported a particular API.

Not much point for the good guys to learn how to write code for a particular flavor of ARM based microSD cards, if next week the manufacturers are switching over to MIPS based cards.

Our only hope, is that a market will develop for SD cards that are fully independently audited, and by implication, auditable. The manufacturers would need to publish the complete specs, including the source code for the internal controllers. Then the auditors could verify that the SD cards were made with the stated chips, and that those chips were running code which matched the source code, and further, that there are no other chips present, nor hidden modes of operation.

To do their job, the auditors would need to be able to install test code, to probe for hidden operation modes. Auditability, leads to hackability (in the nice sense of hackability). Each design change would require a new audit, and a new set of documentation for auditing. This would provide market pressure to provide stable internal APIs, to prevent the cost of auditing going out of control.

In that sort of environment, it would make sense to write nice code to run on SD cards. Without some assurance of API stability, writing the code would only be useful for short term projects, like evil NSA tools.

I know this is a fantasy. Learning to replace the embedded code in one flavor of SD card, has about the same level of long term utility as learning how to add new hardware microcode to a Pr1me 450 in 1980. It might be useful on the few Pr1me 450s that were in circulation at the time, and impress the professors, but the code wouldn't even be useful on other Pr1me computer models, possibly not even on different revisions of the same model, and certainly not on something as different as a VAX 11/780. (I believe this is the sort of low-level microcode that Ken Thompson was referring to in the paper referenced below. Yet it has much in common with the embedded firmware of the microSD card.)

hardware sources and power profiling

Posted Jan 1, 2014 0:53 UTC (Wed) by deconfliction (guest, #94407) [Link]

and to quote slashdot's resident paranoid alien genius, please don't forget power profiling-

"No, instead you should be able to verify all of your hardware and software are valid. One way to do this is demand the VHDL and compiled chipset designs for all your hardware. This way one can benchmark things such as power draw or timing characteristics in reality and simulation, allowing some degree of verification that pattern matching code isn't running across your bits."

http://slashdot.org/comments.pl?sid=4585877&cid=45757167

Another Pr1mate?!?

Posted Jan 5, 2014 11:16 UTC (Sun) by Wol (subscriber, #4433) [Link]

25/30, 2250, 750, 850, 9955, 2750 ...

Mind you, as a lesson in code compatibility that ain't a bad list!

Cheers,
Wol

ubifs/jffs2?

Posted Jan 2, 2014 8:50 UTC (Thu) by Lennie (subscriber, #49641) [Link] (1 responses)

Sounds like someone should start a project for an opensource firmware with device specific drivers.

That might be a start to solve that: there is no standard protocol or method to inspect and attest to the contents of the code running on the memory card’s microcontroller.

ubifs/jffs2?

Posted Jan 2, 2014 8:58 UTC (Thu) by Lennie (subscriber, #49641) [Link]

Or even better ?

How about a device with direct access to the flash instead of the firmware handling all the access.

Then the software on the computer driving it can be open source.

Huang: On Hacking MicroSD Cards

Posted Dec 30, 2013 18:29 UTC (Mon) by geek (guest, #45074) [Link] (1 responses)

In "Reflections on Trusting Trust" - here: http://cm.bell-labs.com/who/ken/trust.html, Ken Thompson said, "I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."

Is anyone looking hard at microcode malware?

Dave

Huang: On Hacking MicroSD Cards

Posted Dec 30, 2013 20:04 UTC (Mon) by deconfliction (guest, #94407) [Link]

"Is anyone looking hard at microcode malware?"

I think for over a decade the NSA has been hard at work waving its hands getting people to look away from microcode malware. Their success rate in doing that may however be on a downward trend recently for some reason...

hacking wi-fi sd card

Posted Jan 1, 2014 9:26 UTC (Wed) by dufkaf (guest, #10358) [Link]

BTW, there is even more advanced controller in so called wi-fi sd cards, it runs linux and can be hacked too. see e.g. http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/