If you don’t have root, you don’t own a device, despite what hundreds of Internet of Things manufacturers would tell you. Being able to access and write to that embedded Linux system in your new flashy gadget is what you need to truly own a device, and unfortunately this is a relatively uncommon feature. At this year’s DEF CON, [Brad Dixon] unveiled a technique that pwns a device using only a sewing needle, multimeter probe, or a paperclip. No, it won’t work on every device, and the devices this technique will work with are poorly designed. That doesn’t mean it doesn’t work, and that doesn’t mean the Pin2Pwn technique isn’t useful, though.
The attack relies on how an embedded Linux device boots. All the software needed to load Linux and the rest of the peripheral magic is usually stored on a bit of Flash somewhere on the board. By using a pin, probe, or paperclip to short two data pins, or two of the latch pins on this memory chip, the bootloader will fail, and when that happens, it may fall back to a uboot prompt. This pwns the device.
There are a few qualifications for this Pwn using a pin. If the device has JTAG, it doesn’t matter – you can already own the device. If, however, a device has a locked-down JTAG, unresponsive serial ports, or even their own secure boot solution, this technique might work.
This exploit works on the property of the bootloader. This bit of code first looks at a piece of Flash or other memory separate from the CPU and loads whatever is there. [Brad] found a few devices (mostly LTE routers) that would try to load Linux from the Flash, fail, try to load Linux again, fail, and finally drop to a uboot prompt.
As with any successful exploit, an equally effective mitigation strategy must be devised. There are two ways to go about this, and in this case, the software side is much better at getting rid of this attack than the hardware side.
Since this attack relies on the software falling back to uboot after an unsuccessful attempt at whatever it should be booting, the simplest and most effective mitigation technique is simply rebooting the device if the proper firmware can’t be found. Having a silent serial console is great, but if the attack relies on falling back to uboot, simply not doing that will effectively prevent this attack.
The hardware side is a little simpler than writing good firmware. Instead of using TSSOP and SOIC packages for storing the device firmware, use BGAs. Hide the pins and traces on an inner layer of the board. While this isn’t a foolproof way of preventing the attack – there will always be someone with a hot air gun, magnet wire, and a steadier hand than you – it’s hard to glitch a data line with a sewing needle if you can’t see the data line.
I really, really doubt BGAs would help much, unless you go crazy and have blind vias so you can’t get access to them from the other side of the chip, as well as purely interior traces so you can’t just scrape the mask and get the trace that way.
You’d need the chip manufacturer to be nice, too, so there wouldn’t be any data lines on exterior balls.
Even then, magnet wire and a pair of thin filaments as backstops can get access to any interior ball pretty easy.
Usually more complex btlr solution use standalone uboot application and reboot device when something goes wrong with boot sequence
If you’ll allow me to go on an ideological tangent…
In an ideal world, none of these hacks would be necessary. The device makers are benefiting from the collective efforts of the open source community to create their IoT widget, and should be paying it back by making it easy for people to exercise their OSS-given rights to access and modify the code running on the device.
I think it’s a real shame Linux can’t have its license changed to GPLv3, to force the issue.
GPL V3 demands that application code running on the machine be open source? That’s… Scary. And would kill Linux.
GPLv3 doesn’t mean the application code running on the device has to be open source. It means that the device manufacturer has to allow you to replace any code on the device that is GPLv3.
Hmm if I remember right there had have lot of same kind hacks earlier. first linksys routers drop to bootloader via short circuit memory. Also some of console mod chips works that way.
Yes indeed. This was the trick commonly used to debrick WRT54Gs over a decade ago. For that board, you had to wedge higher address pins such that you don’t stomp on the bootloader at the base of flash.
THIS year’s DefCon?!
Shorting data (or other) lines to affect booting is from the Ark!
yep. Sadly Defcon has fallen down just like all the other bastions of learning. Everything that is old is new again… I remember doing this to a wyse serial terminal that had a setup password lock set.
Ahhh this could be useful. Got a LLL that’s different enough that none of the known variations of vulcan nerve pinch work.
Should use a sewing needle to short the pins. :)
Pin shorting was the original standard for getting OpenWRT on the Linksys WRT54G routers, before software-only methods were discovered. It was considered risky, but I used it many times successfully.
https://blog.cryptomilk.org/2007/01/17/bricked-linksys-wrt54g-repair-instructions/
I fail to see why this would be a bug.
It’s a feature.
Once you have access to the hardware of a device you can open a whole lot of bag with tricks.
And the way to prevent this if wanted is of cource to use one of the many “secure” processors with built in encryption, flash and the whole shebang.
Similar to the technique I invented to recover data from a nearly dead flash chip with good address lines but one or more bad data lines.
Simply by using the feature of the chip that reads the entire array for diagnostics purposes, an image of the device can be build with successive readbacks as well as monitoring device current for identifying areas likely to fail in the future.
Often the data line is blown/severed but with a JFET connected to the damaged pin/stub the missing data can be reconstructed with the same technique invented by NASA called “temporal interpolation”.
None of the embedded systems that I have worked on (professionally) have been vulnerable to this kind of attack. None of them fail over to a console command line they just fail full-stop. They also had secure boot mechanisms which meant that the SoC wouldn’t load any code it didn’t recognise (the very particular boot loader) and then boot loader wouldn’t load any images that weren’t signed correctly.
The only time one of the projects I worked on was breached was because there was a signing issue, rumour had it that it was an inside job though.
Well if the adversary has physical control of the hardware, you’ve lost.
Techniques that come to mind are laser drilling the package of the SOC to find and repair the blown PROM programming fuse, or just replacing the SOC with a clean one.
Until recently it was uncommon to find a consumer router that did trusted boot.
Are the defcon talks available online? Is there anyway to link to them in the summaries here?
Some are: https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw
What does this do to the chip driving the data lines? Potential for damage from a short circuit?
Well if you were going to wire up a switch to do it, I’d recommend using a 1K resistor in series.
Just a couple of seconds dead short should be okay. Potential for damage would be from continually driving it, while getting hot.