Reverse-Engineering Suspicious IoT Devices Installed Under Employee Desks

What would you do if you found a suspicious-looking IoT (Internet of Things) device under your desk at work? If you’re an employer, how do you install innocuous IoT devices in your office building with raising concerns from your employees? If you want to produce your own IoT devices, how do you ensure that they’re ethical, legal, and secure? Erich Styger answers all of those questions in a log of his journey through reverse-engineering an IoT device found in a real office.

For ethical — and probably legal — reasons, Styger doesn’t say where exactly this device was found, nor who designed or manufactured it. He was been in contact with the manufacturer to let them know about the flaws he found, but his post is mostly intended for educational purposes. These particular devices were found mounted throughout a work space, including under employees’ desks. Each IoT device was mounted magnetically and easily removed, but their purpose wasn’t clear. That, in itself, is the first red flag. Employers should never install monitoring equipment without their employees’ knowledge.

Most of the rest of the red flags deal with the security of the hardware, which was full of vulnerabilities. Inside the easily-opened case was a PCB with a LoRa module and antenna, an STM32 Arm Cortex-M0+ microcontroller, a humidity/temperature sensor, a PID motion sensor, and an accelerometer that was apparently left unconnected. As it turns out, the device was intended to simply monitor the environmental conditions through the office, and was triggered by motion via the PID sensor in order to save battery life.

However, Styger found multiple ways to intercept that data, and even methods to inject false data. The easiest way to gather the data, and more importantly the secret app key, was to simply pick it up when it was transmitted between the microcontroller and LoRa module, because it was sent as clear text. With that information, the device could be spoofed through the LoRaWAN network. The debug pins and functions were even left accessible, so the device’s firmware could be copied, reverse-engineered, and modified. Basically, if you’re looking for a thorough explanation of what not to do when designing an IoT device that should be secure, Styger’s blog post is perfect.