IoT hacking field notes #1: Intro to glitching attacks

TL;DR: First in a new series of short, IoT-related posts, this tells the story of a simple glitching attack we used to get a bootloader shell and ultimately root a device.

---

IoT field notes is a new series of short stories about interesting (hopefully 🙂 ) observations, vulnerabilities and techniques, inspired directly from the IoT assessments we perform at NVISO and from our IoT R&D activities.

Glitching 101

Our first story is about a glitching attack we recently used to take control of an IoT device. Simply put, “glitching” refers to intentionally introducing faults while a device is operating, hoping to make it malfunction in a way that can be exploited. Some examples of glitching include:

• Messing with a device’s clock, for example speeding it up or adding unexpected ticks;
• Pulling a CPU pin to ground;
• Momentarily increasing the voltage supplied to a device.

All the above can cause the device’s CPU to skip some instructions, perform the wrong instructions, or read and write corrupted data from memory. How is this helpful? Imagine the target device is performing an authentication check, for example verifying the pin entered by the user. If we can make the CPU skip the instructions performing the check, we might be able to bypass the authentication mechanism!

Locked out

In a recent assessment, we were faced with the following scenario: we found a serial interface on the target device, but the Linux console was password protected. In such cases, the bootloader (for example U-Boot) can provide a different way in! Developers often store juicy information, such as SSH keys and passwords, inside bootloader variables. Dumping them can provide the credentials we need for root access. On top of this, one of the bootloader’s duties is to provide the Linux kernel with kernel parameters. Making the right changes to these can spawn a root shell after the kernel boots.

In order to interact with the bootloader, we need access to the bootloader’s shell. During boot, U-Boot uses a countdown mechanism, allowing the boot process to be interrupted by pressing any key, which causes U-Boot to display the bootloader shell. However, the countdown mechanism can (and, in production, should) be disabled by setting the countdown duration to 0. This was the case for the device we were testing, meaning we could not get to the bootloader shell…

Glitching in action

So, was all hope of rooting the device through the serial interface lost? Not so fast! In fact, U-Boot has the habit of dropping into a shell if something goes wrong during boot, for example if it is unable to load the kernel. In our target device, U-Boot loaded the kernel from a Ball Grid Array (BGA) memory chip.

So, an idea was born. If we could stop U-Boot from loading the kernel, that could give us the shell we needed. Enter glitching! We inserted a thing copper wire below the BGA memory chip, just as U-Boot was trying to load the kernel:

This worked like a charm! As you can see in the image below, our glitch short-circuited some BGA memory pins, which in turn caused read errors and prevented U-Boot from loading the device tree. Unsure how to proceed, U-Boot kindly dropped into a shell, to allow debugging the issue – which also gave us a way in.

Once we had access to the bootloader shell, the rest proved very easy. In fact, one of the bootloader variables conveniently contained the root password – we’ll leave the rest to your imagination 🙂

Looking ahead

Some glitching attacks are very sophisticated, but others, such as the one we discuss here, can provide a shortcut to rooting a device. However, a note of caution: glitching can also easily lead to a fried device. Proceed carefully when trying it on your target hardware.

That’s all for our first IoT field notes post! If you enjoyed it, stay tuned for our next one, which will bring you tales of IP cameras.

About the author

Théo Rigas is an IT Security Consultant at NVISO. He has researched the security of connected alarm systems and is currently working on more IoT and embedded device security projects . Outside of his Research work, he performs Web, Mobile and IoT security assessments for NVISO.