CVE-2020-11922: WiZ Smart Lightbulbs: Can a Lightbulb be Smart and Secure?

****Smart lightbulbs examined: WiZ Colors A60****

Smart lightbulbs are becoming increasingly popular, providing options for varied lighting scenes, saving money and providing easy app – or voice app – control. Few potential purchasers of smart lightbulbs would put cyber security at the top of their list of attributes which is why it was important that we, and Consumentenbond did so on behalf of the consumer.
Here we examine the WiZ Colors A60 lightbulb. In common with all our tests we closely examined the security of the device and following our test we shared the results with the vendor. Testing extends to both software and hardware.
As in all tests of this type, the vendor of the product was informed of any problems or vulnerabilities that were encountered. Although there was no formal requirement for them to do so, in the case of WiZ the vendor responded positively to our reports and their actions are detailed below. We applaud the vendor for doing so, as it inspires confidence not only in our testing team, but also in the wider marketplace. It is worth commenting that given today’s speed of turnaround in new products – particularly in the connected device marketplace – some ‘bugs’ or vulnerabilities are inevitable, so it is important that vendors or manufacturers respond quickly when they are discovered.

****Examination of the Lightbulb Software****

To begin our testing we examined the software running on the lightbulb and paid special attention to the traffic – data being received by and sent from the bulb.

****Accessing network traffic****

First we noticed encrypted traffic being send from the lightbulb to mqtt.wiz.world on port TCP/8883. On this domain an MQTT server is running which is used for triggering the lightbulb via the accompanying mobile application.
This encrypted traffic was easily made much more readable by using SSLstrip to remove the encryption in between. The traffic can then be visually inspected.

Figure 1: Decrypted contents of the data being send between the lightbulb and the MQTT server.

We can determine several parameters and values from the now-readable data. In particular:

• Firmware version
• HomeID version
• IP address
• Wi-Fi SSID
• MAC address
• and much more

Is there anything in this list that should not be there? Yes. Why should the WiZ server know anything, for example, about the SSID being used in your local network setup at home (CVE-2020-11922)? Even more so, since it is often possible to find the approximate physical location using an ssid with https://wigle.net.
These are not very significant security matter, but as we believe vendors should highly value privacy we consider this should be addressed.

Vendor’s Response: The WiZ team agrees with us regarding the need for privacy and quickly issued a temporarily fix. That would be followed up by a permanent fix, comprising hashing the SSID before data is submitted to the cloud.

****Impersonation with the Android application****

The lightbulb can be controlled using a mobile application. In this case we analyzed the Android app WiZ Connected (version 1.14.0) from Google Play. As with many apps of this type, this one also uses general logs to reflect all kinds of information to the terminal (CVE-2020-11923). Unfortunately the WiZ Connected application also logs the API credentials as well.

What is the relevance of this, and what could someone do if they were able to access these credentials? You could easily impersonate the rightful owner of the lightbulb and its app. It is worth mentioning however that accessing these credentials isn’t particularly easy.

If someone did get their hands on these credentials what harm could they cause? Let’s consider a practical case. say you have equipped your home with a set of very fancy with automated lightbulbs, and set up several light scenes, including one with subdued light for watching movies. You engage this mode and then, inexplicably (because an attacker has accessed those credentials) the lights turn on and off, entirely ruining the mood, overriding your own controls. Not cool, of course. Better not log credentials anywhere, right? The vendor agreed, has issued a fix and the application now no longer stores these credentials.

There is another thing the application we tested does (Android Version 1.14.0). It stores confidential information in a plain-text xml file within the mobile application’s sandbox. This means other applications may be gathering this information without you knowing it. This should be regarded as possible rather than a probable.

Evidence of this can be seen when you use the adb shell to view the contents of your Android device. The file /data/data/com.tao.wiz/shared_prefs/shared.prefs.xml contains the application token for example. This information can be used to perform requests on behalf of the user it belongs to. Of course, you would need access to the local application sandbox in order to get this information.

Figure 2: The shared.prefs.xml contents.

A solution would be to not store any sensitive information if not required. Or, if you really need to store some sensitive data, use the KeyStore for Android.

Vendor’s Response: The vendor has stated that a fix for this issue will be made available and features on the development roadmap.

****Examining the Hardware****

After all this we also wanted to see if we could find any cool stuff on the hardware level. So we smashed a few lightbulbs and opened them up (it was really that easy, no anti-tampering whatsoever). By using a Saleae Logic Analyzer it was possible to extract the firmware via the so called Serial Peripheral Interface.

Figure 3: Attaching the logic analyzer.

After getting a memory dump from the lightbulb we could see that the firmware was probably not fully encoded or encrypted. The entropy in the file indicated that we might find something readable.

Figure 4: Check out the entropy graph of the firmware.

And we did. After running strings we found all kinds of readable data like the SSID and its accompanying password for example (CVE-2020-11924).

Figure 5: Wi-Fi credentials were readable.

Obviously, you would like an attacker to not have access to this information. The vendor should encrypt whatever is possible. Firmware should be fully encrypted, and passwords should be stored in a secure manner.

Figure 6: When running strings, it appears not to be encoded or encrypted.

So, if you have an old smart lightbulb that you would get rid of. Perhaps you’d better not hold a yard sale if you are not one hundred percent sure your credentials were removed from the bulb. A nosey neighbor may be spying on your Wi-Fi network!

Vendor’s Response: The vendor has stated that an update has already been issued to obfuscate the sensitive data stored in hardware. Furthermore, they’ve stated that although some of their older products are not capable of supporting full firmware encryption, they are taking the need for encryption into account for next generation devices.