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:

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.

Su casa es mi casa

This first device is billed as the "most flexible, powerful and affordable home controller on the market today. No monthly fees!" Neat. Now let's see how secure it is. The product descriptions and marketing material surrounding it also give us as "security researchers" a glimpse at the capabilities of the devices and to estimate attack surface: Lots of connectivity.

the setup and the Teardown

Now that we have a general idea of attack surface, let's set it up the way a normal user would. And in the process get more information by opening it up and seeing what we can see.

The marketing material was right, setup was very simple. It consisted of you just plugging the device into your local internet router via Ethernet. You then went to a predefined web page (out on the internet) and entered the MAC Address and Serial Number of your device. But before we do this, we'll want to see what it does.

So now that we know this thing is going to be talking to the internet for first configuration, the first thing was to intercept all of it's communication with the outside world. Ben, set up a router on his Raspberry Pi to do this so that all traffic could be intercepted and watched in real time. The RaspberryPis are ideal for this kinda stuff because they are cheap enough to buy a handful of, they run Linux, they support've got built in support for a handful of USB Ethernet and Wifi Adapters, and they can be packed away [as is] for easy reuse on other projects without rebuilding. Other tools like WiFi Pineapple are slow and frankly too "abstracted".)

The SSL tools are just-in-case the device decides to try to "call home" to it's servers over SSL. If it is poorly implemented it would allow us Man In The Middle his connection and peek at what he's doing (more on this later as it is a recurring theme in many of these 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.

"Secure mode"

Ben also noticed that the device could run in "Secure Mode" which (after a little digging) Ben discovered disabled all the daemons (like the web server) running on the device's "network facing" IP.

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.

For this device, we just simply handed the interns a UART USB cable plucked from one of the SexViaHex Student kits . (No Shikra needed for this one). With a little quick help from one of the Appendices of the SexViaHex Lab Manual (for the pinouts of the UART cable) the interns were connected to the device using screen (yea, it can do serial too ;-).

It took a few guesses at baud rate but just like that, the interns had a rootshell over UART. (We have an entire unit in SexViaHex about how you calculate baud rates using a Logic Analyzer to gain interactive control of a device. We'll also demonstrate this technique on two other devices in subsequent "The Insecurity Of Things" posts).

now the we got a rootshell, let's find a remote vulnerability

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.

This is a common technique used by hardware vendors. So to "fake" a mutable filesystem they have a custom binary on the filesystem called "nvget" that fetches from NVRAM using a "key/value" scheme. Here is an example of it in use in their boot scripts.

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 now we need an "exploitation" tool: id-iot-ic

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.

with this tool, 0wning your own device is "point and click" simple. And we'll just keep adding exploit modules as we go.

It has full interactivity and "point and click" simplicity to exploit the simple (and not so simple) vulnerabilities in the devices we'll be discussing in this blog series. It is modular (uses some simple python interpreter "monkey patching" to make it so new commands/functionality can be added by just dropping files in to the "modules directory").

animated gif of idiotic 0wning the device

Conclusions

With some really dead-simple techniques this device was easily compromised. Furthermore not only can you attack your own device, but an attacker could (without purchasing a device) potentially just download the firmware image from the manufacturer (as linked from the manufacturer's wiki), extract the filesystem image using binwalk and unsquashfs, and navigate to the right directories on the filesystem to retrieve the ssh private keys used to access the manufacturers backend.

From there potentially (if SSH works the way we think it does), this key can be used to access ALL THE OTHER devices like it in the world currently connected to the internet. It should be noted that as the interns discovered these vulnerabilities in this device, they found "prior art" vulnerabilities found by D. Crowley (then of Trustwave Spider Labs) although there was no explicit mention of the ability to potentially access all the other devices via the manufacturer's servers (via the hardcoded SSH keys).

While this a simple little device, the ability to attack it on the local network and potentially reach it THROUGH the manufacturers own servers as a beachhead to other computers on your home network is a reminder of why devices like this need to be understood better.

this extracted SSH key can potentially be used to access ALL THE OTHER devices like it in the world currently connected to the internet, through the manufacturer's backend no less.

Our next targets :

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?

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.

Everyday we read about some newfangled internet connected device being released. Things we use everyday are being made "smart" with some rushed-to-production software embedded in a cheap micro-controller. Fitness trackers, smoke alarms, televisions, cars, wall-outlets, even water-bottles. Internet connected-water bottles? What a time to be alive!

Some think this "Internet of Things" (IOT) and embedded system explosion is driven by gadget hungry consumers. Perhaps it is, but most of this absurdity is side-effect of us technologically transitioning from a world built around ASICs to a world powered by cheap general purpose SOCs (with FPGAs and CPLDs filling in the gaps).

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.

hack all the things?

Some of the vulnerabilities we will be releasing are 'remotely accessible'...some even allow an attacker to access the manufacturer's backend and spread to ALL devices from there...

So to further celebrate this brave new world of newly connected devices we at Xipiter will (over the next few weeks) be releasing our findings in about ten connected devices that many people (according to Amazon) have in their homes. Some of these vulnerabilities are remote, meaning they can allow a remote attacker access to the hardware.

In some cases these vulnerabilities are serious enough that anyone can buy the hardware and not only remotely attack other devices but also attack the manufacturer's backend infrastructure and spread from there.

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.

The interns did it...

Then we gave them a budget of about $2500 to buy any devices they wanted to investigate.

Then we let them loose to bang on all the devices they purchased.

When the interns got stuck with lab hardware or lab tools, we'd help them. When they got as far as they could go with that stuff (which was generally pretty far), we showed them (deeper stuff) like how to extract and reverse engineer binaries and firmware, write simple exploits for binaries on the targets (although many of these targets sadly didn't require too much fun binary exploitation). They got to learn a lot.

Ben and Mohini debug compiler errors for the firmware of their ARM microcontroller.

They approached their targets from the outside (sniffing traffic, accessing network services, intercepting firmware updates), then if required, they went deeper (opening the hardware, findings interface points, using diagnostic hardware) and finally accessed and interfaced with the devices at a hardware level with the intent to discover some remotely exploitable vulnerability. From web directory traversal down to MIPS/ARM disassembly with tools like IDA and Capstone Engine. They got to do it all.

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 targets

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:

A "smart" smoke alarm

A used ATM

A "standalone" webcam (A webcam not requiring a computer).

A "smart home" hub

Another "smart home" hub

A "smart" thermostat

Another "smart" thermostat

A home router/access point

A home Networked Area Storage (NAS)

A "smart" networked wall outlet

A "game console"

A Point of Sales System

and an Android tablet

Ben builds a router out of his Raspberry Pi to do SSL MITM of one of the devices...

Some more thoughtful words ...

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.

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...