Don’t Toss That Bulb, It Knows Your Password

Whether it was here on Hackaday or elsewhere on the Internet, you’ve surely heard more than a few cautionary tales about the “Internet of Things” by now. As it turns out, giving every gadget you own access to your personal information and Internet connection can lead to unintended consequences. Who knew, right? But if you need yet another example of why trusting your home appliances with your secrets is potentially a bad idea, [Limited Results] is here to make sure you spend the next few hours doubting your recent tech purchases.

In a series of posts on the [Limited Results] blog, low-cost “smart” bulbs are cracked open and investigated to see what kind of knowledge they’ve managed to collect about their owners. Not only was it discovered that bulbs manufactured by Xiaomi, LIFX, and Tuya stored the WiFi SSID and encryption key in plain-text, but that recovering said information from the bulbs was actually quite simple. So next time one of those cheapo smart bulb starts flickering, you might want to take a hammer to it before tossing it in the trash can; you never know where it, and the knowledge it has of your network, might end up.

Regardless of the manufacturer of the bulb, the process to get one of these devices on your network is more or less the same. An application on your smartphone connects to the bulb and provides it with the network SSID and encryption key. The bulb then disconnects from the phone and reconnects to your home network with the new information. It’s a process that at this point we’re all probably familiar with, and there’s nothing inherently wrong with it.

The trouble comes when the bulb needs to store the connection information it was provided. Rather than obfuscating it in some way, the SSID and encryption key are simply stored in plain-text on the bulb’s WiFi module. Recovering that information is just a process of finding the correct traces on the bulb’s PCB (often there are test points which make this very easy), and dumping the chip’s contents to the computer for analysis.

It’s not uncommon for smart bulbs like these to use the ESP8266 or ESP32, and [Limited Results] found that to be the case here. With the wealth of information and software available for these very popular WiFi modules, dumping the firmware binary was no problem. Once the binary was in hand, a little snooping around with a hex editor was all it took to identify the network login information. The firmware dumps also contained information such as the unique hardware IDs used by the “cloud” platforms the bulbs connect to, and in at least one case, the root certificate and RSA private key were found.

[Limited Results] had hinted to us that he had previously disclosed some vulnerabilities to the bulb’s maker, but that until they fixed them, he didn’t want to make them public. They’re fixed now, and it appears that the bulbs were sending everything over the network unencrypted — your data, OTA firmware upgrades, everything. They’re using TLS now, so good job [Limited Results]! If you’re running an old version of their lightbulbs, you might have a look.

On WiFi credentials, we were told: “In the case where sensitive information in the flash memory wasn’t encrypted, the new version will include encrypted storage processing, and the customer will be able to select this version of the security chips, which can effectively avoid future security problems.” Argue about what that actually means in the comments.

ESP8266’s don’t do zwave as far as I know. Since that’s the heart of the problem. It’s an intrinsic Wifi problem, it’s sortof inherent in Internets Of Thingses. They all have to log on to your network.

If you were clever you could possibly rustle up a second network just for these, that doesn’t have access to anything important, including the out-pipe to the Internet. Not sure how you can run 2 networks over the same Wifi equipment though I’m fairly sure it can be done.

I don’t think Zwave has a day job as a computer networking standard, it’s mostly meant for home automation. So somebody accessing your Zwave network might be able to mess about with your lights but your data is all safe on a different frequency.

Most newer AP’s and (IIRC) all DD-WRT can run multi SSID/multi WPA2 pwds/multi-VLAN and force each to their own network only. I have 4 SSID’s on mine – music, sprinkler system, iDevices, droid devices. One vlan per device class.

It’s probably a bad sign that the security problem here isn’t significantly different from the one that motivated various military hardware to have elaborate key fill mechanisms and prominent zeroization triggers for emergencies; but is being tackled by vendors who are anywhere from indifferent to adversarial toward user security; for users who don’t understand and want it to just work.

Of course the WiFi details are plain text. The key has to be, and SSID probably needs to be as well. As long as it is possible to read all the storage on the device, any obfuscation or encryption would at best just make it slightly harder to get and really no better than plain text. Then someone would write a simple script that does it automatically, and you’re back to where it started.

One way I can think of is to store such details on a read-protected internal flash / EEPROM (possible on the microcontrollers I’ve dealt with), or anywhere but encrypted with a device-specific key stored in afore-said read-protected storage.

But that too is stored on the device. So just extract that, and then decrypt everything else. More complicated, but not really any more secure (OK, it would take a little work to get, instead of just a hex editor, but that can be scripted easily).

This is the essence of at-rest data encryption. It requires some hardware protected key which you can use to encrypt/decrypt the sensitive data, but that can’t be otherwise accessed from software. Many modern SoCs provide such hardware, including the ESP32, but not the ESP8266.

The rub, of course, is that, even though the firmware on the device can’t read the hardware protected key, it can invoke hardware operations that use the key to decrypt sensitive data. And once decrypted, the sensitive data is usually kept around in RAM for later use. So at-rest data encryption must always be coupled with firmware secure boot and secure debug/JTAG disable.

At the risk of sounding like a broken record, no IoT product should ship without these protections.

Even if it can be read by software, as long as it can’t be accessed externally (e.g. external flash, or via a debugger), and the software can’t be changed to read it out (secure boot, or block updating without a full erase first), it should be fine.

I totally agree that nothing should ship without adequate protections. But how to convince manufacturers of that is another story…

If it was read protected, how will the chip get the SSID and password out of it to send to the AP to connect?

What’s needed is a tamper proof silicon design, where there is a secure enclave for key storage and encrypt/decrypt functions, and a protected tamper-proof datapath from the secure enclave for the decrypted details to get to the WiFi unit for use in the connection protocol.

And even that will probably leak the information along the way in some manner – power use attacks, timing attacks, and so on.

You could hash the ssid and use the hash to encrypt the password concatenated with some fixed value. The device scans available SSIDs, tries to use each one in order of descending RSSI. If you get the correct fixed value you try the password. Not exactly bulletproof. Does not work for hidden SSIDs and for broadcast SSIDs the adversary could always do a site survey. At least it is not plain text.

And anyone can still easily decrypt the password, unless you use the slight alteration below. But at least they don’t have the SSID which could identify where it came from, in turn making the password much more likely to be useful. However as you say it doesn’t work with hidden SSIDs, and therefore would probably not get implemented.

An improvement would be to encrypt the password with a key derived from the SSID itself rather than its hash, as that way the password cannot be decrypted without first finding an SSID that matches the hash. However that probably wouldn’t be hard for a determined attacker.

Things like this is why I dont own any “internet of things” devices.
The only things I own with an active network connection are a Netgear ADSL2+ modem router, a desktop PC and a Nokia N900 phone. I do own a cheap Android phone (bought during a time when my N900 was being fixed and I needed a phone to make calls to people) but that sits in my desk drawer with the battery removed.
And I own a Topfield PVR to record TV but the Ethernet connection on that isn’t plugged in at all.

Not everybody who wants to use such devices is able, wants and has the time to do such hacks. But most people are able to use a hammer and it does not take much time. Probably most people who can and want try some hacks do it anyway :-)

I mean, anyone who’s seriously motivated can decap the chip and find the keys. Only way to prevent that is to lose any protected data on power loss or something, or some sort of geofence thing, but they’re all annoying to deal with. I propose a big bold messages on the base of the bulb reminding consumers to reset memory before disposing of the product…

Does it have to sit on the same network as the controlling devices? If not, why not save tinfoil and time, and just keep it off the trusted network? Most modern routers support multiple APs for guest networks which isolate clients from one another.

There are other comments talking about hacking together complicated solutions. Not trusting it to run alongside the rest of your internal network, and not putting sensitive information onto it in the first place seems a lot simpler and safer.

Given that ‘smart’ waste/recycling technology tracks how much stuff comes out of each bin, it’s not impossible to get from finding it in the garbage truck to finding the house number.
Furthermore, councils are starting to snoop on our trash to ensure we’re recycling responsibly. Our council asks us not to shred confidential waste, just cross out the important bits, because it’s better for their recycling… uh, no!

You know there are databases of SSIDs that are mapped to latitude/longitude, right? That’s one of the ways Google knows where a device is even if GPS isn’t available.

So you take the SSID, run it though the DB, and now you know where to go. You don’t even need to get the bulb from the target’s trash, you could get them from a recycling center or somewhere like that.

Put your IOT devices on a separate WiFi network from your main home (or work) network and follow best practice of changing the WiFi password and even SSID when one of these devices is disposed of. Let’s not forget that cracking WiFi is not impossible so your WiFi should be segregated anyway. You could consider using MAC address white listing and network scanning to count the number of devices and alert if that number changes.

If you have physical access to the device, you have everything.
With full access to the silicon inside the device, there’s no foolproof way to make the data secure – obfuscated at best.

You’re talking about cutting the device apart with a hacksaw, soldering wires onto pads etc in order to read the flash.

In what attack scenario is it really going to be worth it for the attacker to do this, in order to get the Wi-Fi password?

Because you can’t get inside a bulb like this non-destructively, in most cases, you can’t really re-flash it with your own firmware and still have an intact lightbulb you can use.

Why would you need to throw away a LED bulb anyway? Aren’t they supposed to never fail?

It’s not really “insecure” – but if you really care that much about protecting your password, just be aware that you need to change the password if you throw away devices that contain the password, or reset the device back to a “blank” state where applicable (device manufacturers should make this easy and documented!). Or drill a hole through the flash silicon first.

“In what attack scenario is it really going to be worth it for the attacker to do this”

Did you see the hacked automated/networked apartment scene in Mr. Robot or the X-Files fantastic season 11 episode “Rm9sbG93ZXJz”? It’s not that this would be a widespread hack, it’s just another avenue, not necessarily a good one, to hack a specifically targeted individuals because they exposed themselves to such hacking in order to do something totally unnecessary by networking something for some entirely -TRIVIAL- convenience. Your protection is that you are only one Wildebeest in a herd of many… until someone targets you for some reason.

There is nothing that you can do to completly fix this vulnerability. It is the crux of why every security professional rages against the IOT. Every one of these devices adds to the multitude of attack vectors that any data has. For any device to use wifi it must some how store and use the SSID and the password, on devices with input capability it is possible to use encryption as it can rely on a secret stored inside the users head. For devices with no physical input there is nothing that you can do other than obfuscation of the information.

Now, on the upside: cracking wifi is not trivial but it is not overly complex either, so for most people this is a non issue as anyone willing to go through the trouble of digging through your trash for a lighbulb is willing to put a device just outside the building that will log traffic and work on cracking the password actively as the ammount of human time investment is pretty even.

Much like everything else on one’s network (computer included) it’s about keeping it away from the bad-old internet. Problem is a lot of IoT BY DESIGN are made to being dependent upon interfacing with the internet. So it’s either purchase a device that’s segregated, and lose some of it’s functionality (and the higher cost), or gain that and open security vectors. There doesn’t seem to be a middle ground in IoT.

Not sure I agree. It’s unavoidable to you because you accept that IOT devices can be disposable.

Philips and Ikea do this “right” – the credentials are kept on the HUB, not the bulb.

The “Hue bulbs are overpriced” folks aren’t doing themselves a favor with their non-UL listed equipment that embeds keys to their wifi… and who really in their right mind wants to *administer* their light bulbs on a per-node basis? (Oh hey, no problem0… surely someone’s made Ansible or Chef scripts for wifi-bulb management…”)

Thats an interesting hack, however i’m not sure about the implications for some lambda person. How probable it is that somebody will dig into your trash to hack your network? If you are a famous person in some way or a big company it’s another story, but for an anonymous person i think this is not the worst security hole.
Anyway, no Internet of Toilet stuff here, no problem.