>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

Firmware data entropy vs. file offset

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.

Connecting UART debug pins

Reading from device’s UART port

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 0

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

Connecting BusPirate to the Rachio’s flash storage chip

Dumping the 8MB 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.

Flash chip data entropy vs. File offset

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.

No chip datasheet is available for the Murata System-on-Chip

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.