One of the most critical issues that we look for when we assess an embedded/IoT device is secrets that are shared across the device population. Usually, finding these secrets involves gaining full access to our own device in order to find out how other devices may be affected. For example, an LTE router may have a service account hard-coded into its firmware to allow for remote support. If we can recover the account credentials and method of access, we can "service" any device that is accessible to us. This post is about one of the methods we use to gain full control over, or "root", our devices.

On Linux and Android-based devices, protecting device secrets means that you've got to keep an attacker from getting privileged (a.k.a. root) access to a device. Developers need to make sure that they:

• Secure attack surface area such as network ports, application services, debug interfaces, and serial ports
• Protect the integrity of the software and configuration from modification
• Prevent authentication and authorization controls from being bypassed during operation

My DEF CON 24 presentation, "pin2pwn: How to Root an Embedded Linux Box with a Sewing Needle" (updated slides), documents a simple but surprisingly effective method to bypass protections on mis-configured devices that rely on U-Boot and Linux to secure access to root.

Warning!

I have not yet destroyed hardware but this is technique is clearly an abuse of semiconductor devices. Be sure to use this only on equipment you can afford to destroy. Depending on the hardware you may have better and safer options to get what you need done. I recommend that you use those options first.

Demos

Demo #1

Demo time! This device is configured to "autoboot" after three seconds and does not give any opportunity to abort the boot sequence.

During the boot process I'm using a small sewing needle (technically a sewing pin since it doesn't have a thread hole!) to short together two of the leads coming off of the flash storage device that holds the Linux kernel. This prevents U-Boot from loading the kernel and once it gives up U-Boot does exactly what the developer asked it to do... it falls back to running the U-Boot command line interface! Once we have access to the U-Boot CLI, we can set boot args and access the filesystem as the root user.

Preparing this device for the attack required identifying the flash device. On this device the CPU, flash, and memory are on a small DIMM-style CPU module.

The flash device is on the underside, left hand side of the module.

After some experimentation I settled on disrupting the Address Latch and Control Latch pins. I positioned the pin using some blue tape and re-assembled the CPU module to give it a try.

Demo #2

This demo features a different device which uses serial flash.

Prior Work

The simple pin2pwn technique is part of a much larger spectrum of techniques known as hardware glitching or hardware fault injection. There are a number of techniques which have been used to compromise secure processors to give up cryptographic keys.

Other examples of successful flash device glitching using electrical shorts:

• WRT54 “Bricked Router” recovery, Administrator note by mbm, 2004
• “How to Hack the Hudl – We give Rockchip a good seeing to”, Pen Test Partners blog post
• WINKHUB Side Channel Attack, Kevin2600
• 20 Devices in 45 Minutes, CJ Heres et. al., DEF CON 22 (related)
• http://colinoflynn.com/2016/07/getting-root-on-philips-hue-bridge-2-0/, Colin O’Flynn, 2016

Details

When and Where?

pin2pwn works best when you disrupt the flash load process when:

1. U-Boot attempts to load the kernel
2. During the Linux userspace init process.

To get familiar with the timing of the system the easiest approach is to find the serial console and monitor the boot process. If you can't do that or the system is very terse drop a logic analyzer on flash device pins to figure out what is going on.

Where to poke really depends on what you can easily reach on the flash device. This is what has worked best for me:

1. Parallel flash devices. Many of these are standardized on a TSOP-48 package with a consistent pin out. Best places to poke:
   • Left side: Short the Address Latch (AL) and Control Latch (CL) pins.
   • Right side: Short the Data 6 and Data 7 pins together.
2. Serial flash devices
   • Short between pins 1 (chip select) and 2 (data out)

The key is experimentation. This isn't rocket surgery so poke and see what happens.

Pin2pwn works against userspace... sometimes

I've also found specific conditions where the simple pin2pwn attack can be use against the Linux userspace /bin/init process. In some of our assessments the /etc/inittab has been configured to a) start an application (not getty, in this case) which is responsible for authenticating access to device serial ports and b) after that application closes open a shell on the console. Presumably this was done to facilitate developer access if the primary application failed. Leaving this debug facility present in a production configuration was a mistake.

The best way to exploit this mis-configuration was to wait until the console displayed the standard /bin/init messages and then disrupt the flash device. This particular device used Busybox which was helpful because most of its pages were already loaded into RAM. Disrupting the flash device at this point prevented the application from loading but didn't prevent Busybox from starting the shell.

pin2pwn rampage results

We wanted to know how common this attack worked so we took a quick survey of devices in the gear closet. The table below summarizes our findings. Each device was from a different manufacturer and had a distinctive Linux distribution and U-Boot version.

Defensive Strategies

These devices were vulnerable to this attack due to a combination of accessible hardware interfaces and software mis-configuration. This isn't a bug in U-Boot, the Linux kernel, Busybox, or any other software. Defense involves making better design decisions.

Defense Strategy #1: Fail Closed

Our first success with pin2pwn came from a device that featured a seemingly well engineered "secure boot" system that intended to detect device firmware modification. As each firmware component was loaded the bootloader computed a cryptographic checksum and verified that the compute checksum matched the expected value. The flaw was that whenever the checksum failed the device would revert to a U-Boot prompt.

Apparently the developers had not planned what a secure response should have been to failure. Ensure that your own designs account for unexpected failure and resolve to secure configuration when the inevitable occurs.

Defense Strategy #2: Hide Pins

Simple attacks like pin2pwn rely on access to signal traces on the PCB or pins on the semiconductor devices. Selecting Ball Grid Array (BGA) packages and routing signals on internal PCB layers can make an attacker's job more difficult. The picture below shows that even with BGA devices outer-layer PCB layers expose signals. Check your routing!

Defense Strategy #3: Run Silent, Run Fast

pin2pwn is a "by hand" attack that gets really hard when devices are "quiet" and boot very quickly. The attack method could be enhanced with automated tools that could react quicker but then the demo wouldn't be nearly as much fun.

Wrapping Up

Astute readers know that if an attacker has physical access to a device that the battle is lost. See Rule #3. Carve has completed hundreds of security assessments that have hardware elements in the system architecture. What we have found is that eager developers forget that protecting secrets stored in hardware devices is hard. We use pin2pwn to make a point to our clients that even simple tools can poke holes in a poor security architecture.