I just finished an interesting pen test: an infrastructure who’s entire attack surface consisted of custom embedded hardware devices. They communicated via proprietary wireless data connections.

It was a short project. A few weeks, tops. Getting in bed with their comms wasn’t really feasible: high barrier to entry, requiring hardware I didn’t have. All the traditional back-end systems (PC, servers, etc.) were also out of scope, because they were housed in a secure data center away from the internets, accessible only via the private connections with the devices.

It was looking bleak.

Physical access to the devices was ‘in scope’, so I reluctantly popped one open. As I expected, it was full of entirely proprietary hardware: the mainboard and the peripherals, all communicating across several proprietary buses… and… serial.

So I decided (again reluctantly) to look at the serial stuff. I found a few admin ports, but that was underwhelming. But things got interesting when I noticed that, in one special mode, all the communication peripherals spoke to the mainboard over serial and not the bus they were seated in.

I am not really a hardware guy. I reverse and source audit. So, in my view, it still looked bleak.

Nonetheless, I decided to try my hand at spying on the serial traffic. The first technique I tried was suggested by Eric Monti (who I discovered had done something similar with great success in the past). His suggestion: use two serial ports on my laptop, making it “inline” between peripherals intercepting and rewriting the data with a vanilla “select() loop” style mux. Eric provided some code that I hacked up a bit. This worked, but only partially, because some of the devices failed to initialize during hardware handshake when my laptop was inline (I still don’t know why. I suspect some of the pins I couldn’t control went from low to high… again… I’m not one of the Matasano hardware guys).

The only thing left to do really was passively spy on the traffic between the peripherals. This would require a hardware serial tap. I thought about it, and it seemed reasonable. So I googled around and found this.

I took some (reluctant) trips to Radio Shack and Fry’s and tried my hand at building his tap, not really expecting to get anywhere. After three failed attempts, I realized that this guy’s wiring diagrams were subtly incorrect. The pinouts were wrong. I tried my new design which looks more like the diagram above. The device came out looking something like the photograph below.

I fired up minicom/zterm, and began seeing all the traffic on the bus! (Really only half because each side of the tap is only half duplex.) So now I was starting to feel a little more confident. This was familiar territory, I could now try my hand at reversing the protocol spoken across the peripherals to see what was being sent to the back-end servers. Before I could do that however, I needed to write custom tools —- minicom wouldn’t cut it.

So I wrote an internal serial terminal and injection tool called serial_snoop to be used with this serial tap. It has two modes: The first is passive, and it just displays data on one or two buses. The second drops you into a interactive python shell, and acts like minicom, only instead of reading from STDIN (as minicom does) serial_snoop sends data out onto the serial device via object method calls (which I provide in a big class). Because it’s interactive python you can also import “helper objects” to perform tasks… this allowed me to play interactively with the devices, and name helper functions specifically to their purpose (“initialize_wireless_iface()”, “send_packet()”, and potentially “crash_server()” :-).

And this is where our story ends. I spent about a week reversing the protocols spoken by the device to the back-end systems. It was a surprisingly simple protocol. By the middle of the last week, I had replicated most of the functional parts of the protocol and I had successful data injection into the back-end systems via the wireless interfaces in the device.

The moral of the story, I guess, is that if I can do simple hardware stuff like this, anyone can. Hardware never gets solid testing because of obstacles that may actually be easy to overcome. If you can successfully hop the hardware hurdle, you can find all that never-before-seen attack surface.