First day at hack.lu. Three of us kicked the conference off with the ARM IoT Firmware Emulation workshop by Saumil. The goal of this workshop was not so much to write exploits or to pwn boxes but to learn how to build a beneficial research environment by emulating the hardware of a Linux based IoT device to run its firmware in order to run analysis and tests.
First step is to obtain the firmware. This could be done by dumping it directly from the device or by downloading firmware images from the vendor. In order to dump the firmware from the device one has to obtain access to the underlying system which is usually done by finding the serial console on the hardware since this one often exposes an unauthenticated root shell. I think there is enough documentation online on how to identify and connect to a serial console so I won’t cover the details here. It’s also covered in Saumil’s slides in detail. Having the bootup logs from this console will be helpful later though. While talking about baud rates for the serial console Saumil made a great pun I don’t want to withhold: “Most common is baud rate 115200. If you find a console with baud rate 9600 you are in fact talking to an acoustic coupler. That’s not an IoT device, it rather belongs to a museum.”
So at this point we theoretically have access to the serial console of a device (say for example a DLINK Router), its bootup logs and the dumped firmware. The challenge now would be to emulate the DLINK hardware as close to the real hardware as possible. Saumil provided a virtual machine with all the data already extracted and ready to go. In this virtual machine we would fire up qemu to emulate the ARM environment and Saumil provided two images with OpenWRT firmware and lots of tools preinstalled. Why two images you ask? A lot of IoT devices use rather old kernel versions. To be compatible with most of the devices in the wild we were given images with kernel version 2.6(!) and 3.16. To quote Saumil again: “In IoT kernel 2.6 is like Internet Explorer 6. It’s never gonna go away.” This is mostly because the reference implementations and libraries of Broadcom are for kernel 2.6 and no one ever bothered updating if I recall correctly.
Another spiffy thing Saumil did in his environment: The virtual machine has 2 separate hard disks. One for the host and one exclusively for the qemu ARM emulation. This allows snapshots of the test environment without touching the host system.
Next step would be to extract the root filesystem of our target device, the DLINK router, onto a dedicated directory inside the ARM machine. To emulate the router properly some other things are necessary like mounting the proc, sys and dev filesystems of the ARM host system to the extracted filesystem. Afterwards it’s just a matter of chroot and in theory we have a working router userland on a compatible architecture. But the fun part is still to come, and this is where the boot log from the serial console comes in. After chrooting to the userland we have the DLINK userland, albeit the services are not (yet) running.
By analyzing the boot log, we can figure out which init scripts are executed after booting the router. And we now have to run the same scripts and find out what to do so they don’t fail. That’s the fun part ;D at least in my opinion. Analyzing unknown systems and figuring out how they work to the point where you can manipulate them. As it turns out Saumil was able to identify an XML file which contains the “default config”. So it is just a matter of deactivating $stuff we haven’t emulated, e.g. deactivate the Wi-Fi and bridge interface of the router and set an IP address. After tinkering with the configuration and figuring out what to deactivate in the ~1300 lines of XML we have a working image of the DLINK router, running the services the DLINK router would run, and we can finally start analyzing exposed services.
We can now test the web interface for common vulnerabilities, analyze processes with gdb from the ARM host system etc. I think this is quite impressive and way more convenient than carrying around a router or an IP camera or you name it. According to Saumil his students were able to analyze and attack devices they never had physical access to just by emulating and analyzing the firmware images!
Concluding I want to state that all of us agreed: Saumil is a humble, smart and funny guy. His way of teaching is so motivating and inspiring that I recommend everyone who has the chance to join his talks and workshops. I for one hope to see him again and chat with him about the progress I did with the tools he provided me in those short three hours.
cheers
Pascal
Slides: https://www.slideshare.net/saumilshah/hacklu-2018-arm-iot-firmware-emulation-workshop
GitHub: https://github.com/therealsaumil
Twitter: https://twitter.com/therealsaumil