The Insecurity of Things: Part Two

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

RaspberryPi Router.

Tearing down the device

Wiresharking the pcaps

Keep a handful of RaspberryPis around.

Ben at work in the lab.

Our target.

The Raspberry Pis had a few useful tools installed on them: 

• MITMProxy 
  
• tcpdump
  
• SSLStrip

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. 

Unauthenticated Firmware Upload/Download page.

"Secure Mode"

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.

Ben and the Lab Scope

The guts of the device.

DRAM

NIce! maybe we use our www.rfcat.com ;-)

Ethernet controller

UART...rootshell!?

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

Connected..

Connecting UART

Connecting UART

Rootshell!

Rootshell!

Ben at work

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

Animated Gif of idIOTic 0wning the device.

idIOTic interactive help and IOS style subcommand menus.

idIOTic interactive commands to 0wn this device several different ways.

---

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