This was a research conducted in 2019 of my personal smart lighting system, which led to unexpected findings.
IoT devices are becoming more and more an inseparable part of our modern homes. With mainstream products like the Google Home and Amazon Echo, people are getting used to controlling their speakers, air conditioner, doors and countless other home appliances with their voice or app. However, when installing these devices users unknowingly put themselves at risk of uninvited guests.
Today we will take a look at a very popular line of LED controllers manufactured by Chinese company Zengge. These devices have LED light connectors and a Wi-Fi chip, and allow remote control of the lights. Users connect via their Magic Home / Magic Hue app (100k+ downloads on Android each) to the controller and can turn the lights on or off as well as change the LED color and other settings. Connection takes place over the common home Wi-Fi or through the Zengge cloud remotely.
Installation schematic for the LED controller
Behind the scenes, the LED controller is just a Wi-Fi chip (Hi-Flying LPB100/LPT120 in older versions and Espressif ESP8285 in newer ones) listening on TCP port 5577 for bulb commands. Commands are sent over a proprietary binary protocol between the application and the LED controller. Additionally, UDP port 48899 is used for changing the Wi-Fi chip access point configuration such as home SSID and password. Interestingly, Zengge decided to take the UART interface port commands built into the Hi-Flying LP line of chips and expose them to the 48899 port, effectively piping commands from the LAN as if received via serial. This instruction set, called AT+ in the MCU data sheet, allows relatively rich control over the chip — getting application and firmware versions, setting AP settings, sending arbitrary data over a socket and even flashing a firmware upgrade via a controlled URL link. Users can also control the LEDs remotely from the app via the Zengge cloud, implemented via an open socket which receives bulb commands.
Sample commands from the LPB100 datasheet
Already in 2015 talented researcher Viktor Stanchev created a Golang API for the LPB100 chip to access both the LED and chip port over LAN. Both protocols don’t implement encryption and have a simple hard-coded structure. Using the API users can program various automated procedures such as periodically changing the light colors or settings a sleeping schedule. Apparently, hundreds of people think it is a good idea to port-forward the LED and control ports and access their LED via an external IP:
190 devices using the LPB100 chip, port 48899 open
Our Shodan scan showed interesting results:
1. 230 Zengge devices with open 5577 port, allowing control of the LED
2. 376 Zengge devices with open 48899 port, allowing control of the Wi-Fi chip:
a. 190 HF-LPB100 chips
b. 43 HF-LPT120 chips
c. 143 ESP8285 chips
Viktor’s controller program was designed for LPB100 and exits if the version returned is not this exact chip. However, we found that LPT120 uses the exact same protocol and a tiny code change made the program work. The ESP8285 is a more complicated matter and the controller did not work out of the box. Still, with some protocol sniffing and comparing between different firmware we found some differences such as a different line ending character and confirmation messages. We applied these changes to the Golang code and opened a pull request. The result is that we can turn on or off 230 LED controllers and steal Wi-Fi credentials from all 376 devices. We can even use the wireless scan instruction of AT+ to find neighbor SSIDs and further deanonymize their location.
Getting SSID and password via the controller
Easily finding SSID->coordinates mapping worldwide on wigle.net
Furthermore, in the LPB100 and LPT120 High-Flying chips there is an AT+ instruction that downloads a binary firmware upgrade file from an unvalidated source, effectively granting arbitrary code execution. It would be quite easy to drop further exploitation weaponry like a SOCKS server or a network scanner and pivot into more sensitive devices in the network. Since many IoT devices including the LED controller assume the LAN to be a secure network it should be quite manageable to cause further damage inside the network.
Instruction to trigger a firmware upgrade
Our research shows how misconfiguration of devices by users, whether knowingly or not, opens the door for attacks. Attackers can wake up victims in their sleep, pinpoint their location and infiltrate their LAN. As for Zengge, routing the high-privilege commands from an open port instead of UART is a lazy and negligent way to configure devices from the app. As we can see, the next Mirai is only a couple of scans and tools away.