RSA IoT Village 2018: Hacking some of the things
RSA attendees who wanted a hands-on taste of hardware hacking were able to get their fix at the IoT Village area of the RSA Sandbox, a busy ancillary location of the RSA Conference 2018 in San Francisco. There, they learned that the UART interfaces ubiquitously found in IoT equipment have some default behaviors that enable at least preliminary access to the workings of the device, giving hackers a starting point for developing more thoroughgoing security breaks.
I took some time to work through a couple of the hands-on exercises at the workbenches comprising the village. I was drawn, in part, because there was a soldering iron on the table. It turned out we didn’t need a soldering iron, but all the same I was handed the guts of a Philips Hue controller hub and a logic scanner with a bunch of lead probes hanging off of it, a sort of miniature version of the wiring harness used to administer an EKG.
The object was to get root on the hub. To speed the ploughing, a certain amount of advance work had been done. Header pins had been soldered onto the holes in the circuit board for access to a diagnostic port, for example. This made it rather easier to hook up the leads to a logic analyzer, each lead snugging onto a pin on the header board.
What if I didn’t know which unsoldered holes were actually a port in disguise? I asked Nathan, who was helping me. He said that, starting from nothing, you soldered pins onto all the header spots and ran the diagnostic probe on all the pins at once. In any case, I fired up a capture on the Linux desktop at the station, then powered on the Philips hub.
Analyzing the serial capture
The point here is that lots of IoT devices have a similar setup. There’s a CPU chip on board that runs an embedded version of Linux, and there’s a way to hook a serial terminal interface up to it if you’re willing to do some patient poking around. You’ve got to figure out a few basics about the port, such as which pin is transmitting, which receiving, which is ground, what the baud rate is and so on. The analyzer figures most of this out for you. You can work your way through the possibilities for baud rate, or you can use the analyzer to look at an individual bit’s worth of high signal on the line and work backward from how much time that bit takes to transmit, or you can guess a couple of values that are far more likely than not.
When you get it right, somewhat miraculously, an analyzer hooked to the transmit pin will spit out actual ASCII characters and, cue enlightenment, I noticed the word “boot” amid the first few dozen characters.
Terminal console access, but stumped
From there, a further exercise hooked up a serial-to-USB interface to the laptop, to which a console window could be attached. Now, when the hub was powered on, the familiar Linux boot sequence streamed by, with volumes attaching and so on, eventually ending at a console prompt asking for a login.
With the right login credentials, you could sign on and be a root administrator, but the point of the next exercise was that it’s not actually that simple. After all, you don’t know what the root password is.
Probing the UART at RSAC,
What the IoT Village folks let you know, though, is that this interface you’re using is a UART interface and one thing that’s true about UART interfaces is that if the master volume doesn’t mount successfully, it fails to a root login prompt. This isn’t a flaw, exactly. It’s just how the thing works.
Since you’re using a boot sequence that’s stored on a non-volatile chip, the play at this point is to short the power to the chip in question to ground, making it non-functional during the boot. For the hardened geek, this is the fun part of the exercise, because now you have an excuse to use the video microscope to see the circuit board better, find the line in question and tap it with the thin point of a probe.
Hello, root
When the volume doesn’t mount, you get a root prompt. The system uses a password hash that is stored in an environment variable (sigh), so you can set this hash to zero, write the environment variables to the chip and reboot one last time. Now you own the full system in its normal operational mode.
This is not, one hastens to say, the same thing as controlling the universe. You haven’t really breached anything usable in the field. Nathan’s view was that Philips had done a pretty good job of the security of the actual system, so this is really just the first step that gets you to the start of the real research. Now you can make a copy of all the software used in the system, get a better look at the network traffic generated by the device, and possibly find poorly protected encryption keys and certificates.
It’s a staple of panel discussions of IoT security to say that most devices have next to no security, but one nice thing about an exercise like this is how it shows that it’s not downright stupidly simple. Yes, it’s the sort of thing that someone with some experience in electronics and computers can push to a point where he can get a look at the source code, but getting source binaries on a device you’ve taken apart in your lab is still a long way from having remote exploits that turn field devices into weapons.