Reversing the Rachio Smart Sprinkler Controller
A new smart device that “takes the guesswork out of watering.” An IoT device that extends the boundaries of your smart home into the yard? Sure, what could go wrong? Turns out, sometimes, when things are designed with security in mind, not as much.
The Rachio smart sprinkler controller is a highly-reviewed IoT device that lets you start and stop your sprinklers from your phone. As another of the growing number of consumer IoT devices in your home network, it is also another potential infection vector for malware or attack vector for hackers.
This blog details the methodology used to explore the potential attack surface on the device. The intention was to find vulnerabilities as that’s what I do for my day job. However, I was pleasantly surprised given my past exploration of similar IoT devices. My research didn’t dig up any vulnerabilities in the Rachio3.
My initial goals were:
- Identify the device components
- Identify the attack surface
- Acquire and analyze device firmware
Identifying the Device Components
The device disassembles easily enough, revealing a loaded PCB underneath the plastic housing. The board has several transceivers and antennas for network and intra-device communication. It has a clock/calendar chip to maintain real-time during power off. For our purposes of assessing device security and acquiring firmware, the debug interface, processor chip, and flash storage are the most promising components to look at.
Next, Identifying the attack surface
Starting with a scan of the open ports on the device gives us a look at the services implemented by the Rachio device. It only has web services open (HTTP + HTTPS). Seems quite simple. No web server versioning information is returned in the header. The web server requires basic HTTP authentication and can’t really be explored much more without the firmware.
>nmap -p 1–65535 192.168.0.200
Nmap scan report for Rachio-28D876.lan (192.168.0.200)
PORT STATE SERVICE
80/tcp open http
443/tcp open https
MAC Address: B8:D7:AF:28:D8:76 (Murata Manufacturing)>curl -I http://192.168.0.200/
HTTP/1.1 470 Connection Authorization Required
Challenge accepted: Acquiring device firmware
Let’s start with logging traffic during a firmware update. The device updates over plaintext http, so the firmware is easy to acquire. However, the entropy of the data in the firmware file shows it is encrypted.
Current firmware: iro3-firmware-hk-5-601_c5d37fc0.ota.signed (1196114 bytes)GET /gen3-ota-firmware-image/iro3-firmware-hk-5-601_c5d37fc0.ota.signed?x-pin=c5d37fc0 HTTP/1.1
Host: s3-us-west-2.amazonaws.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/3.10.0
Now, the fun part: time to get our hands dirty.
Let’s check the debug interface by soldering pins to them and using a bus pirate or similar tool to read from the device. I won’t go into specifics of identifying and connecting to UART. The gif below shows the bus pirate used in UART mode to read from the board’s debug pins. The baud rate is automatically determined from the received data by the bus pirate (115200 bps) and the text coming from the debug pins is printed to the console during the Rachio device boot process. As it turns out, the Rachio’s debug pins are just a logging interface. The log interface provides some information on the boot sequence and underlying software, but doesn’t provide a shell. The device uses Cypress’s new and relatively unknown WICED SDK for embedded wireless communication. The boot log also tells us it is using an encrypted file system and has encryption keys hidden somewhere.
1542235590029:DEBUG :iro_main :OTA2 boot mode: 1
1542235590051:DEBUG :iro_wifi :starting...
1542235590060:DEBUG :rachio_persist :size is 1507328
1542235590096:DEBUG :rachio_persist :using secure fs
1542235590101:DEBUG :rachio_persist :Using device keys
1542235590117:DEBUG :identity :pin iro2-c5d37fc0 url A3BMBCWE3HYBWY.iot.us-west-2.amazonaws.com and env 0The debug interface gave us no leverage on the device, so we have to move on. The flash chip is the obvious next step for locating a bootloader and hopefully some decryption keys. With the device unpowered and a test clip attached to the flash chip, the bus pirate can make quick work of dumping the flash. The gif below shows the commands used with the flashrom tool to query data from the flash chip.
After getting the flash image, the entropy of the data contained gives a good picture of its contents. We can see several separate sections. The flash chip contains an encrypted filesystem, a section called the “Device Configuration Tables” (also encrypted), and an application image which is the same firmware image the device downloaded in the update earlier.
Our ultimate goal is to acquire and reverse engineer the device’s decrypted software and probe the service implementations for vulnerabilities. Hence, the next step would be to look at the Murata processor chip [https://wireless.murata.com/eng/type1gc.html] to see how it decrypts and loads the filesystem.
The Rachio device implements some basic but very important security steps to raise the bar for exploitation.
- Firmware and filesystem encryption
- Limited debug interfaces (no shell access)
- Service-level authentication
- Communication encryption
Here’s the thing: I can either continue to explore and dig deeper or just pick up one of the other million IoT devices that have a much lower bar for exploitation and discover vulnerabilities in them. It is very important to remember that attackers might use a similar rationale. They will likely try to find the path of least resistance into the network. A chain is only as strong as its weakest link — sound familiar?
These device security best practices are not cost-prohibitive for manufacturers to implement, but are missing from products by most manufacturers because security is not by design. It is usually an after-though, if that. The inclusion and hardening of consumer-grade IoT devices is a welcome and encouraging trend in network security.
