Since we've started teaching SexViaHex, many people (not just our students) have asked me (Joe Fitzpatrick) for equipment recommendations for doing their own hardware hacking. I own and use several tools with duplicate and overlapping purposes, since there's usually a 'best' tool for any given job. In the process of assembling the equipment and content forSexViaHex, I had a hard time whittling it down. The first answer to 'what should I buy first?' is and will likely continue to be the BusPirate (with a Saleae in close second). No single tool speaks so many protocols, and only a handful of tools provide lots of the diagnostic and passive sniffing features of the BusPirate. 

"So hold on a second" (you might be thinking) "First things first! How to we wire this Shikra up to stuff?"
It's really simple, the Shikra much like the BusPirate just has headers which you can use to jumper to your target. The pinouts of the Shikra are viewable in the documentation for it. 

According to the diagram to the above,  UART, the Shikra's pinouts are as follows:

TX: 1
RX: 2
GND: 18

Once wired up, the following command (from a *nix) machine will connect you through the Shikra to whatever you're targeting:

$ screen /dev/ttyUSB0 115200

Protip: I never worry about getting TX and RX right, since somewhere along the way they get mixed up, and it's usually easier to swap them once to get things to work than it is to make sure they're right in the first place.

We needed something different so we switched to a different FT232H-based board that worked well, but has had a very high failure rate (they'd burn up easily or stop working inexplicably).  We needed something more reliable. So after all that we decided to design something and the Shikra eventually replaced these tools.  The Shikra was equally as easy to get wired up for JTAG and use with OpenOCD:

Shikra JTAG Pinout:
TCK: 1
TDI: 2
TDO: 3
TMS: 4
GND: 18

OpenOCD Config File for the Shikra:
#shikra.cfg
interface ftdi
ftdi_vid_pid 0x0403 0x6014

ftdi_layout_init 0x0c08 0x0f1b
adapter_khz 2000
#end shikra.cfg

Of course, Shikra is not just for work. I recently got a Teclast Air II tablet (same panel as an ipad retina, but with an intel bay trail SOC and andriod/win8). I wanted to update it to a dual-boot bios, but accidentally bricked it because i flashed a bios file for the older Teclast Air 3G. Luckily i was able to resurrect it by using the Shikra + Pomona SOIC + Flashrom to directly flash the chip when it wouldn't boot otherwise.

In summary, I was pretty excited to get my hands on Shikra, and I'm looking forward to showing participants in our future SexViaHex classes how to use it to reverse engineer and hack up hardware devices!

When we last left off, we were setting the stage for sharing what the Interns found in a handful of "IOT" or internet connected devices they purchased. So we'll be starting with a simple one. One that only required simple techniques to compromise it. This first device is a "Smart"-Home Controller. For a bit of background on what's going on here, please see "Part One" of this series otherwise we're going to jump right in but first a disclaimer:

The following information is released FOR ACADEMIC RESEARCH PURPOSES ONLY. Xipiter staff did not at any time access the external or supportive infrastructure of any of the products mentioned herein. Furthermore, as a information security firm, Xipiter does not condone or encourage the use of the following material for the purpose of attacking or exploiting the devices of others. The purpose of this blog series is to raise awareness about the security risk posed by this new class of "IOT" or "Internet Of Things" devices.

Ben stepped through all the configuration steps as the device specified, but noticed something (by watching the network traffic intercepts).

In Step 4 of the configuration manual, it instructs you to connect to the manufacturer's website and enter the serial number and MAC address that is printed on underside label of the device. This presumably is to "pair" your user account with the hardware you purchased.  Ben noticed from the pcaps (from tcpdump) that immediately after entering this information, his web-browser was redirected to the local IP address of the device. It looked as though he was connected to the manufacturer's website, but there was an IFRAME actually pointing him at the device within the lab network. So the device is running a webserver.

Instead, when in "Secure Mode" the device spawned all of the daemons on 127.0.0.1 and SSH port forwarded them from the device through the manufacturers servers out on the internet.  This would allow you to access the device INSIDE your home network from out on the internet. (More on this "Secure Mode" later, because it is ironically the very feature that makes these devices open to potential remote attack.)

Ok so now that the device is set up and on the network, the interns opened the physical hardware it to see what they could see. As standard a procedure at Xipiter, everything is photographed through the lab scope right when it's opened so that serial numbers and model numbers can be recorded to download specification sheets (and so you don't have to remember to do it later for report writing). In the end, it'll turn out that none of the specification sheets were needed to compromise the device.

The first glaringly obvious thing is that the device is running an RALink core which we know from experience is a common MIPS based System On Chip popular with OpenWRT (We'll be validated shortly when we see in fact what it is running.)

In subsequent blogposts (in this series) and in our "Software Exploitation Via Hardware Exploitation" course we have to deal with using diagnostic tools and techniques to reach buried pins or discover which pins are responsible for what. But here, not only does thePCB Silkscreen clearly call out the pins but there are also headers soldered on. Clearly this manufacturer didn't iterate on the hardware design. These are all indications that the "development" and "release" revisions are the same hardware. 

The next step was to take a look around the filesystem...our goal is to find remotes so we want to find out what daemons are currently listening and which may be spawned by the system. 

After searching through the filesystem a bit for other references to the daemons in that process listing, it was determined that there was a light http daemon is used for service and setting files on the filesystem. 

The immediate next progression is to read the embedded HTTP config which revealed that this device has http configs that forward incoming requests to specific "endpoints" or web paths....So of course, some basic directory traversal stuff was tried. And eventually the interns landed on this:

So this is great. We are getting closer, we can get the password file unauthed remotely. BUT, one other thing to note is that the filesystem of the actual device is immutable including /etc/passwd (because it is distributed in the device as Mask ROM). To get around this and fake "mutable" parts of the filesystem, this manufacturer uses Non-volatile FLASH storage to basically store everything so that it can persist after reboot. 

They even use it to retrieve the root passwords stored in NVRAM ;-)

Ok, so let's review what we have so far:

• The device is using dropbear ssh daemon
  
• The device is using lighthttp with custom configs to serve files from the filesystem. There is an unauth'd directory traversal vuln here.
  
• We can fetch configuration values from NVRAM via the root console.
  
• The device has embedded SSH private keys on THE IMMUTABLE sections of the firmware image so we know that all these devices have the same embedded ssh key. It uses that key to access the manufacturers backend and set up ssh port forwards.

So at this point we need a tool to capture all of the "exploits" for these vulnerabilities.

So we now there is a need for a place to keep and release all vulnerabilities for these "Insecurity Of Things" posts. A place to keep them all bundled with easy access.....So we wrote a simple "modular" tool called idIOTic. 

This device was a very simple example, it didn't even require any of the fun stuff like "binary exploitation" to completely compromise the device and others like it. 

In the subsequent blogposts we'll go deeper and share more techniques from our SexViaHex class: 

• What if you cant easily access UART? 
  
• What if the firmware updates are signed or not easily downloadable?
  
• How can we use JTAG to pull firmware and analyze the firmware for vulns? 
  
• What if the embedded "webserver" is just some compiled C app servicing HTTP requests?
  
• What if there isn't a "full operating system" but just a RTOS?
  

We'll discuss all of this in more depth as we catalog what the interns found in a NAS, Access Point, and a Smart Thermostat (in the next post). With each post we'll also include PoC "exploit" modules for idIOTic.

The old ASIC world required electrical engineers to team up with software engineers to make anything of significance. Back then, everything was bespoke: from the hardware up through stack to the "business logic" software that was embedded. These days, this is less common because of the proliferation of multi-purpose SoCs and cheap solid-state storage powerful enough to run full operating systems. These days,  your average C programmer can make hardware do useful things using generic multipurpose micro-controllers.

And as we all know this means new places for security problems. 

We aren't much for the "CVEs-as-resume-material" or the "CVEs-as-company-marketing" mentality that plagues our industry. We also don't want to do a "Yet Another 'Thing' Hacking" talk about this stuff.  (We prefer to be head down, make hardware and software and find cool bugs.) So, we are going to simply release our findings here and walk you through how we found them with LOTS of photos and screenshots along the way. We'll share some PoC code and maybe even share some IDB files, firmware images, and other stuff.

If after all this if you want to learn more or get hands on, there are a few seats left for our public course in November in the D.C. Area. In this class we will do all of the above and talk in greater detail about these techniques.

So in short, here is what we did at Xipiter:

It is also worth noting that the interns spent no time researching "prior art" vulnerabilities on each target (although they stumbled upon some). Based on what was found, Xipiter has not yet reported any of the  vulnerabilities . (At Xipiter we generally strictly adhere to our "Responsible Disclosure" policy, but we are deviating from that for this kind of hardware work by releasing everything here for academic research purposes only.) 

The interns basically combed Amazon for the more popular "smart" or "IOT" (Internet of Things) devices and purchased those. They also looked around on Craigslist and found some stuff that they thought would be neat to investigate. So here is what they purchased:

We'll start dumping next week with some pretty devastating vulnerabilities in:

• A "Smart Home" Hub
• A home Access Point
• A home NAS

At Xipiter, we do all the standard "boutique information security firm" stuff. We do source code audits, reverse engineering of mobile and desktop software but we also do quite a bit of embedded systems security work.

For some strange reason, however within the information security world there is a severe lack of knowledge in this realm. This ultimately stems from the  "hardware/software divide": Hardware guys dont understand software and software guys (even the "low level" ones) don't really understand hardware.

But in this uncanny valley there be gold. 

Attackers these days need to spend spend months/years of man hours finding and weaponizing exploits and building post-exploitation toolkits for operating systems cluttered by Anti-Virus, software updates, Intrusion Detection, Endpoint Detection, etc. Why do all this when he could just find some 90's-style bugs and hang out on your router, access point, NAS, mobile phone, "smart home" appliance, set-top box, or television? There is no protection on these things there like there is on the endpoint. These devices often have infrequent updates or updates that are trivially disabled. Even if an attacker were detected, very few of the "industry leaders" in forensics and incident response actively address non-PC hardware.

Most of the research on "embedded device" security is boring and irrelevant which leads fed-up security folks like Dave Aitel to scoff at it.  And rightfully so. Most of the people publishing the embedded security research "miss the point": How threatening is an "attack" that requires you to physically go to the location of your target to do something?  If you're the one deploying the attack it increases your costs and risk. 

But again, it is all about scope: A vulnerability found with a Facedancer in the USB stack of a "Smart Thermostat" is not as valuable a "button pressing" vulnerability found in the firmware of a Casino machine or Video Poker. But both of them are found with similar techniques. So it is the techniques that are worth mentioning.

Most "embedded device" security talks either "miss the point" and talk about irrelevant bugs or
(on the other end of the spectrum) are innovative "Hardware Security" talks that are so heavily steeped in hardware that the software guys seem overlook their importance. 

This is unfortunate because as software security people we somehow miss the significance of things like: the existence of  "CPU cheat codes" that effectively give software in userland access to all of system memory. Or overlook the significance of "memory mapped IO" that gives software direct access to peripherals that can be used for rootkit persistence. As software security people we somehow miss that there are "shadow registers" or "magic values" that can unlock other functionality in the CPU or leak back values of privileged memory.  We miss great work by folks like Felix Domke showing us that random peripherals (with software vulns) often have hidden functionality that have DMA to privileged memory regions. Why should we spend our time weaponizing vulns and building toolchains when we can just execute a few magic instructions (or get a magic value into the right register at the right time) to unlock "debug" functionality left in by the CPU manufacturer? Why should we waste time on the endpoint that can be spent finding "operationally" valuable things on devices NEAR the endpoint or that route internet traffic for the endpoint?

This is real stuff. 
Not fantasy. 
We'll show you.

We'll start dumping next week...