Pwning With Sewing Needles

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.

Two data pins on a TSSOP Flash shorted by a multimeter probe
Two data pins on a TSSOP Flash shorted by a multimeter probe

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.

23 thoughts on “Pwning With Sewing Needles

  1. 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.

  2. 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.

      1. 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.

    1. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

    1. 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.

    1. 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.

Leave a Reply to PaulCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.