disclaimer:
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 Raspberry Pis had a few useful tools installed on them: 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). |
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. | |
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 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 now we need an "exploitation" tool:
id-iot-ic
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 :
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.