[alanfranz]

Maybe the author has some valid points, but he/she fails to illustrate them properly. Beyond the not-so-reasonable scenario, the analysis lacks precision.

"Wi-Fi credentials stored in plaintext into the firmware"

It seems the author fails to understand (or convey) what is a "firmware". The user must set its credentials, right? So, how is it possible that they're "in the firmware"?

1) Wi-fi credentials stored on a device must be readable by the device somehow when it boots and it wants to connect. There're other, less-used and more complex authentication systems (e.g. X509 client cert authentication) that don't rely on that, but they're harder to setup and support, and you'd still need to revoke a cert after a device is thrown away or compromised.

Sure, some systems provide an "encrypted partition", but usually such partition (since the device must start without a password) is encoded with some variation over the serial number or other unique property of the device... and it's usually not so hard to access. Some systems provide a secure enclave (e.g. TrustZone) where passwords can be stored, but someway it is usually possible to get it out when you have PHYSICAL ACCESS to a device. Not something that I would have expected done right on a MCU.

2) No security settings; ok, this could be improved. But most of them are physical-access only settings.

3) Root certificate and RSA private key extracted

Root certificate and private key of what? Given the fact that the author has a vague notion of "firmware", I wouldn't trust his/her opinion. First, the fact that the certificate is in the firmware is not a problem; just the private key could be a problem.

But is that certificate shared and reused between all devices? Or is it flashed per-device and/or autogenerated and trusted on first use? The author says nothing about that. If it's a single certificate that allows, with such key, ALL devices to authenticate on LIFX server, well, that's a vulnerability! Otherwise, it's probably a good practice.

[alias_neo]

Spot on, OP shows a cursory knowledge of what they're seeing but not the specifics to explain the issue.

WiFi creds have long been an issue with IoT devices, the fact they're added at runtime is a step forward over a lot of the DIY stuff where they really are written to firmware when you write your code, because it's easier than writing code to allow a user-set WiFi password.

There are currently few ways to protect against physical access, but one simple protection is to keep your smart bulbs on their own VLAN and SSID. If they're compromised, the rest of your network is safe, and you're not risking your main SSID password leaking.

Security settings, again, mostly physical, but signatures and secure boot would prevent someone MiTM an update to gain control/access, or just borrowing a bulb and doing the same.

As for the certs, without details of what they are for is hard to say for sure but I doubt there generated separately for each device. These companies are notoriously bad at this stuff.

ESP32 is a major step forward in IoT devices over the previous, it has more resources so in theory it should have sufficient memory and compute to work with certs/keys cryptographically rather then just verifying fingerprints.

It also comes with promise of a secure element, but the SDK is "immature" and I'm yet to see any wide use of those features.

[retSava]

This seems to be user-provided wifi credentials added at the setup-stage at the customer time and location.

What I guess you are thinking about is a problem too, defaults, but this is not what the article point 1 is about.

[alias_neo]

I might not have been clear, but this is exactly what I'm talking about.

When you buy a WiFi connected IoT device, they don't know your WiFi credentials, so you enter them, and they get stored on the device so they can be used to connect to your network, just like any other device.

Of course these are not encrypted, because the device need them to connect to your WiFi.

When you build a home made IoT device, using an ESP32 for example, your can take these easy route, and hard code your WiFi password into the code before your write the firmware.

To avoid this in a user-made IoT device, you'd need to configure it to set up a WiFi hotspot, unprotected, so you can connect to it and tell it your WiFi password, like one does with a Chromecast, and like the device in the article and any other sensible production device.

It then stores this in EEPROM or NVRAM, and "reboots" to connect to your network, disabling its hotspot in the process. This unencrypted storage is what the article refers to and is largely unavoidable.

[gh02t]

> This unencrypted storage is what the article refers to and is largely unavoidable.

It is avoidable, the ESP32 supports transparently encrypted flash memory using a key that is stored in one-time-programmable, tamper-resistant fuse bits. The intended use is to make exactly this sort of attack considerably more difficult. Unlike the ESP8266, the '32 has quite a few security features, none of which are enabled here apparently.

[alias_neo]

We aren't in disagreement, I mentioned the secure key storage ("secure element") in my first comment, the problem is that people aren't using it.

I qualified my point with "largely" to be clear that I'm not saying it's unavoidable.

[gh02t]

Yes, I guess my point was that in this case it's trivially avoidable. Enabling these features in the ESP32 is really easy and doesn't have any significant downsides AFAIK, I don't understand why LIFX didn't. It's far from unhackable but I think enabling flash encryption and locking the JTAG and flash read would be perfectly acceptable security-wise.

[solarkraft]

All of this crap is why I'm now a fan of Zigbee. If I have to set up a new network anyway it might as well be better suited for the iot.

A down side is that there's no nicely integrated module like the ESP8266 available for diy.

[alias_neo]

Agreed, I started with XBee radios, they do secure networking and full mesh but they're relatively expensive, a single radio cost about £40 a few years back.

To add an MCU and peripherals brings a single device cost up considerably.

I'd hoped, some years ago when I first started my IoT endeavours that the cost would come down but ZigBee has not, and sadly things like ZLL (ZigBee Light Link) that companies such as Philips use for Hue, perpetuate the propriety nature.

My entire home is Hue (ZLL) but for anything non-Hue I use Z-Wave devices which are relatively cheaper and support secure mode.

[pbhjpbhj]

Passwords? Maybe WPS, or a variant, can be used for IoT devices?

[alias_neo]

There are solutions, but as I mentioned in my original comment, previous hardware has generally not had the power to implement secure cryptographic solutions.

As an example, an ES8266 would be unable to verify a server certificate for a TLS connection against a CA, cryptographically due to memory/compute constraints so historically it's been done by just verifying the fingerprint with a simple comparison.

WPS is insecure and shouldn't be used at all.

One way to do the password system safely is to have a one time pass in volatile memory that is provisioned in a secure environment where you're confident it can't be captured as you pass it over an insecure channel.

The ESP32 is a huge improvement, hardware wise in security capability, it has hardware cryptographic extensions and a secure element, but it's rarely used properly as the article is an example of.

[gh02t]

Regarding the storage of wifi credentials in the firmware, it's got to do with the layout of the ESP32 memory. Firmware and data storage both exist in the same flash memory and the SDK by default stores wifi credentials in the flash memory when connecting. When you dump the flash you get everything, program code and data.

I don't really think this "vulnerability" is anything like a serious threat, but the ESP32 has features to mitigate that LIFX should have enabled. Enabling encrypted flash and setting some of the security features to make it harder to manipulate/dump the flash memory would be perfectly satisfactory; it wouldn't be impossible but it'd be good enough and I can't think of any reason not to on a shipping commercial device.

[retSava]

Regarding 1 and 2 - while I'm not very familiar with the sec settings of this particular chip (esp32), what you can do is to store such settings in internal flash and have the fuse (or similar) setting active that disables reading out internal flash.

With this setup, you can snatch someones lamp and do this dance to get their wifi credentials. With what I suggest above, you can't extract the content and thus credentials with it. There are other ways and attacks - power glitching etc, but that bumps the struggle up one notch or two.

edit: you don't ship with the credentials, but when a user sets this up, you store this in internal flash per above.

[stefan_]

That's a very convoluted way to solve what is a non-problem to begin with. This is a light bulb screwed into a permanent light fixture. On or off, the ESP32 on this thing is powered.

So you just keep the WLAN credentials in RAM, RTC RAM if they even use low-power modes, and all of these problems go away. How often do you move light bulbs, after all?

[gh02t]

I don't think storing credentials in the RTC memory is a good option. In that scenario, if you accidentally turn off the power to the lamp you lose the configuration (unless they add a battery/supercap backup, which might be difficult given that there is not much space and a lot of heat). I do know that by default, the ESP32 SDK stores the last used WiFi credentials on the flash memory mostly unprotected, though this can be disabled.

I am failing to see a real problem here, however. If an attacker is able to steal your light bulbs, I feel like you have bigger problems. I guess the biggest concern is that if you get burglarized you should maybe change your wifi password? More of a concern if you have some bulbs mounted outside, but that's about it.

That said, LIFX should have enabled some of the security settings of the chip. Encrypted flash and setting the read protect bits especially would make this attack much more annoying. It's cool that we could potentially flash our own firmware on these things, but it's pretty lazy from a security point of view.

[cstrat]

If someone pulled the SDCard out of my Raspberry Pi they would have my wifi credentials too.