Synopsis

With smart lighting and other IoT devices becoming cheaper and more accessible, for example, the Mirabella Genio range now being sold in large supermarket chains, I decided to take a brief look into the security of one of these devices. Something that peaked my interest early is the EZ mode pairing method in which the device can be easily set up and introduced to your home network. Taking a deeper look at this method revealed that during the process your WiFi credentials and other plain-text secret values are broadcast to anyone in range to listen. Not only could this allow an attacker sniffing local WiFi traffic to gain access to your home network, but may introduce avenues for further attacks.

Background

The smart lighting purchased was the Mirabella Genio Wi-Fi Dimmable 9W LED bulb, as you can see in the images below.

After needing to create an account with the associated mobile app, it was time to pair with the bulb and connect it to the local network. As the device only implements WiFi, you have two options, EZ mode pairing which is the default, and AP pairing. The process for EZ mode pairing within the app can be seen in the images below, where the user’s WiFi credentials are automatically or manually entered, they ensure the bulb has been reset and is flashing, then the process of EZ mode pairing is started.

AP (Access Point) pairing works as you expect, similar to Google Chromecast and similar devices, the bulb will start it’s own AP, you connect and share your WiFi credentials, then the device closes the AP and joins into your local network. However, EZ mode works without requiring your mobile device to join another network, but how? How are your WiFi credentials shared with the bulb without having another communication channel such as Bluetooth? Time for some investigation.

Smart Config and ESP Touch

Opening up the bulb with some elbow grease it was found that these used Tuya embeded WiFi modules, and investigating a little bit deeper, they implemented the fairly common Espressif ESP8266 or ESP8285 WiFi modules.

For those unfamiliar with Tuya, as I was, they offer a cookie-cutter style IoT service where you can purchase IoT devices such as smart bulbs for rebranding and on-sale. In addition to this, they offer a cloud service as a broker for communication between the mobile app and your devices so that they may be controlled from outside your network.

As the devices used Espressif WiFi modules, digging into the documentation online I found that they implement a method of pairing called “SmartConfig” or “ESPTouch”. Original implementations of the SmartConfig provisioning method appears to have started with Texas Instruments however Espressif seem to implement their own version in their WiFi modules that operates in a similar manner called ESPTouch. The basic run down of the method is as follows:

1. You set the IoT device into a promiscuous listening mode
2. From a mobile device connected to a WiFi Access Point, you start SmartConfig pairing using the relevant app
3. Your mobile device encodes your WiFi credentials into sequences of data length values
4. Your mobile device sends the sequences of broadcast UDP packets to your WiFi AP
5. The IoT device sniffs the sequences and decodes the data lengths to retrieve the WiFi credentials
6. The IoT device joins the WiFi network using the credentials and continues communication from there

This can be seen by reading the ESP-Touch User Guide, and the encoding can be derived by reading the code for the ESPTouch Protocol.

Thinking about the design for a moment, this breaches the trust boundary provided by the encryption of your WiFi traffic by encoding the secrets into the packet lengths which are visible to anyone that might be listening. This could be shown in a threat model similar to following.

To prove this, I compiled and flashed an ESP8266 WiFi Module I had at home with a smartconfig Example provided by Espressif. Sure enough, if this is listening when someone attempts to pair an ESPTouch device, their WiFi SSID and password are retrieved in plain-text, as can be seen in the image below.

That being said, the encoding for ESPTouch was not what I saw when compared to the length sequences I was seeing in Wireshark for the Mirabella Genio bulbs. Further investigation into this showed that Tuya appear to implement their own version of SmartConfig, their EZ Mode, also known as Tuya Link.

Tuya Link (EZ Mode)

After a little searching I found some Tuya Link demo code where comparing the encoding here to a Wireshark capture of the traffic, this looked much more on the money. An example Wireshark capture of the encoded length values can be seen in the image below, which shows a section of the preamble followed by the start of the encoded data.

In addition, it appeared not only were WiFi credentials encoded within the packet lengths, but two other secret values as can be seen in the following code.

class TuyaLink {
  constructor() {
   [...]
   * @example
   * device.registerSmartLink({region: 'AZ',
   *                           token: '00000000',
   *                           secret: '0101',
   *                           ssid: 'Example SSID',
   *                           wifiPassword: 'example-password'}).then(() => {
   *  console.log('Done!');
[...]

Reading some of the Tuya documentation, the token value appears to be a short-lived code used to activate the device within the Tuya cloud service. There appears to be no reason these values couldn’t be transmitted after the device connects to the network however.

Utilising the encoding code above, I wrote a small, and by no means great, script to sniff and decode this data using the scapy Python library. The script basically does the following:

1. Sniffs all WiFi traffic for broadcast 802.11 data packets
2. Observes packet length values for an Tuya EZ mode preamble, and once discovered
3. Targets the source MAC address,
4. Identifies valid headers using a CRC check,
5. Uses multiple data length sequences to build up the complete set of data regardless of dropped packets
6. Prints the data when length and CRC checks are valid

An example of this can be seen in the animated GIF below, and the script can be found here.

As you can see, as a proof of concept it clearly shows that the transmitted secrets are clearly visible and able to be discerned by anyone in range that may be listening.

One potential attack scenario springs to mind to exploit this issue; it goes as follows:

1. Attacker denies service to the user’s lights through deauth attacks
2. The user assumes their lights aren’t working and attempts to pair them again using EZ mode
3. Attacker captures their WiFi credentials and gains access to the user’s WiFi network

Disclosure

This issue was disclosed to the Tuya security team on the 14th of October 2020, in which I received a very quick response the same day. Tuya told me that this was a “known vulnerability” and that they “will gradually offline Smart Config” in favour of a Bluetooth method. In addition, Mirabella was also notified of the security vulnerability present in their Genio devices that implement the Tuya EZ mode pairing.

Final thoughts

The previous examples show that the SmartConfig design implemented by Espressif and Tuya both leak sensitive information to anyone within listening range. This design is flawed from a security perspective, and not only affects the Mirabella Genio bulbs, but also all Tuya and Espressif devices that might offer some type of easy SmartConfig method for setup. In addition, the Tyua Link version of this style of provisioning adds additional secret data to what is transmitted, and what is able to be captured by a malicious third parties. That being said, it is advisable to opt for AP mode provisioning when setting up these types of devices.

While this blog post is focused mainly on the Tuya EZ mode pairing of their smart devices, there appears a lot of potential for further security research into Tuya cloud devices, and other similar services for those wishing to delve deeper.