Twinkly Twinkly Little Star

It's Christmas and what better way of celebrating this festive season than hacking some smart Christmas lights?

'Twinkly' are IoT LED Christmas lights by LED Works, an Italian startup that produce a range of smart light products that contain individually addressable LEDs. These lights can be controlled with a smart phone application over local WiFi allowing for the lights to display arbitrary lighting patterns and produce some stunning effects.

The mobile application communicates with the lights over a local network. Initially, you directly connect to the lights as an access point and then configure them to join your home network. After that, you can communicate with it over your local network and it no longer presents itself as an access point.

All communications from the application to the lights is done through RESTful HTTP API endpoints on the lights on port 80. The communications are not encrypted, however the WiFi password is sent encrypted during set up (albeit trivial to decrypt).

As the communications are not encrypted, it is simple to Man-in-the-Middle the traffic and analyse the API.

In order to communicate with the lights, the phone application first needs to find them. It does this by performing a UDP broadcast to port 5555 with the message '\x00discover'. The lights then respond with their IP address in a UDP response along with the name of the device.

Once the application knows the IP address of the lights, it authenticates with them, receives an authentication token and retrieves information about the device.

The authentication process, although a good idea, is flawed. First, the application makes a POST request to the endpoint '/xled/v1/login' with a base64 encoded 32 bit random number. The lights respond with an authentication token, how long it will be valid for, and a base64 encoded response to the challenge. This response is based on the random challenge number, the MAC address of the lights and a shared secret. The phone application sets the authentication token as a HTTP header and sends the received challenge response back to the lights on the endpoint '/xled/v1/verify'. This finalises the authentication allowing for authenticated endpoints to be called.

This process only authenticates the lights to the application and not visa-versa. This makes the authentication routine simple to implement and requires no knowledge of any shared secrets, the MAC address of the lights, or the challenge generation algorithm.

A number of endpoints were identified while using the application and we built a simple Python Class to interact with the lights programatically, which can be found in Appendix 0x01. A more complete implementation has also been built by @scroolik which can be found here https://xled.readthedocs.io/en/latest/

Armed with the ability to control the lights individually, we connected up a Raspberry PI with a SNES controller and developed a version of Snake that can be played on our lights for the whole office to enjoy.

The lights controller is contained within a plastic box with a couple of LED lights and a button (to perform a factory reset). The casing just clips together and is simple to dismantle by hand.

On one side of the PCB are the LEDs, the button, a couple of capacitors, some test points and a unpopulated IR detector (presumably left over from a previous revision). Some of the test pads are labelled with useful names such as RXD, TXD, RST, GND and GIPO0.

The other side of the PCB is more populated. There are two different power circuits and an ESP-WROOM-02 module which contains a ESP8266 WiFi SoC and SPI flash.

To program an ESP8266, you pull GPIO0 Low and reset the device via the RST pin which causes the device to enter its ROM based serial bootloader. This allows the device to be programmed over UART (TXD/RXD) but can also be used to read the SPI flash. This explains the test pads on the device and thus it is likely that these pads would allow for us to pull the firmware off the device or update it, but as we will see this was not required.

To get the Android application to analyse, we first install the application onto an Android device via the Play Store. With device debugging enabled, we can use adb to pull the APK from the phone. First we identify the package name:

Then locate the APK file

Then pull the APK fime from the device

After decompiling the application it was easy to find the calls to the API endpoints and the algorithms for building authentication challenge-responses and encrypting/decrypting WiFi passwords.

Within the applications 'assets' folder there were firmware update binaries for the lights.

The firmware for the device is split into two files called xled.elf-0x00000.bin and xled.elf-0x40000.bin. The first contains the application firmware for the device and the other contains a SDK provided by Xtensa (who make the ESP chips). Despite the file names they are not ELFs (not even the festive kind). The numbers in the file names correspond to the memory location the images are stored on within the SPI flash.

To perform a firmware update, the phone application posts these files to API endpoints along with SHA1 checksum of the files. These firmware updates are not signed however and thus it is trivial to upload arbitrary firmware to the device over the local network without any real authentication or authorisation, making it straightforward to gain arbitrary code execution.

We already know the MCU is an ESP8266 which unfortunately is not supported by our favourite disassembler IDA Pro. Thankfully there are some resources online from other researchers building some tooling for disassembling and loading ESP8266 binaries into IDA. [1] [2]

The loader built in [1]  however did not load our first binary and required some modifications. This is available in the Appendix 0x02.

The processor module in [2] does not support IDA 7.x, however a port is available in this comment in its github repo [3].

Once the first binary was loaded into IDA we could import the second binary (SDK) and load it at address 0x40240000 which is where the SPI flash is mapped into memory.

IDA does an OK job of fixing things up but more work real is needed to improve the IDA processor and loader scripts.

Following cross references from strings used in the API endpoints, the main endpoint handling routine can be found and reversed.

Although it looks reasonably complex it was not too hard to follow its logic. Doing so revealed a number of additional endpoints that were not defined or used by the Android application. Some of these have been included in the python Class.

Up to now, we have talked about a couple of small issues such as poor authentication and the possibility of unauthorised firmware updates. These vulnerabilities are only exposed locally on the same network and admittedly against a low power MCU that controls Christmas lights.
But we can do better! So now lets turn our attention to some fully remote attacks :D

Twinkly Lights boast that they can also be controlled over Google Assistant which lets you turn your lights on and off or change their pattern to some preset patterns or a custom pattern uploaded using the phone application.

This functionality is provided by 'Message Queuing Telemetry Transport' (MQTT) which is a publish-subscribe messaging protocol. In this protocol, device/nodes connect to a central broker, they can then subscribe or publish messages to 'topics' which are message queues which other devices can also subscribe of publish to.

Twinkly Lights connect to a private broker with a single username and password which are hardcoded in the firmware. The connection to the broker is also unencrypted and thus it is trivial to snoop on the connection and discover these credentials.

Each Twinkly lights have 3 topics they subscribe/publish to:

When the lights first turn on they publish their connection state, the SSID they are connected to, and their internal IP to the topic '/xled/status/$MAC'. This is an arguably low risk information disclosure.

An interesting feature of MQTT allows you to subscribe to topics using wild cards, defined by the symbol '#'. Thus if we subscribe to the root with the topic '#' we are subscribing to all topics and see all the lights publishing their information.

Monitoring the root for unique mac addresses we estimate there are almost 20,000 devices out there.

To turn the lights on/off or change the mode using Google Assistant application it publishes commands to the '/xled/command/$MAC/' topic which the lights also subscribe to.
For example, if the command {'command': 'switchoff'} is sent to this topic for a given set of lights it will turn the lights off.

As any MQTT node can publish to any topic, it is thus possible for anyone to issue commands to any set of lights and turn them off. We tested this remotely from AWS against the lights in the office and it worked perfectly.

It would not take much to build a script which turns off all connected lights in the world!! I am not saying this has been built or hooked up to some kind of button. But ...

DNS rebinding is an attack technique which has recently seen some interest, but is still not that well known. DNS rebinding allows for an attacker controlled web page to bypass the Same-Origin policy in most browsers. It works by an attacker switching the DNS A record for the domain after the page has been loaded. When the executing javascript makes an AJAX request to the original page, the DNS record is switched to another IP address and the browser thinks this is within the same origin as the original domain. This can even allow attackers to enumerate and perform HTTP requests to internal infrastructure of the target just by browsing to their website.

As authentication to the lights does not require any knowledge that can only be known out of bounds locally and the communications don't use HTTPS, it is thus vulnerable to DNS rebinding attacks.

Using MWR's 'dref' [4] framework by serain we built a site which when browsed to will enumerate an internal network, find any Twinkly lights, and display a message on them.

The target here were IoT Christmas lights, which is not exactly a high value target. However, they presented a number of vulnerabilities which we see all too often in other IoT equipment and products which we have performed product security reviews of and where these kinds of vulnerabilities could be much more serious.

0. https://www.twinkly.com/products/wall/

1. https://boredpentester.com/reversing-esp8266-firmware-part-1/

2. https://github.com/themadinventor/ida-xtensa

3. https://github.com/themadinventor/ida-xtensa/issues/12

4. https://labs.mwrinfosecurity.com/tools/dref/