Pwn the LIFX Mini white
limitedresults.com
limitedresults.com
"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.
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.
What I guess you are thinking about is a problem too, defaults, but this is not what the article point 1 is 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.
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.
I qualified my point with "largely" to be clear that I'm not saying it's unavoidable.
A down side is that there's no nicely integrated module like the ESP8266 available for diy.
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.
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.
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.
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.
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?
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.
In that case you can probably just ask to use my or really most people’s Wifi, rather than destroying our $30 light bulbs. Honestly I would prefer you did. This is really a case where social engineering is almost guaranteed to be quicker and easier.
Also correct me if I’m wrong here but once he had shell access into the device, could he not just use the WiFi via the device anyway? Why does it matter that it’s plain text.
Also also, isn’t plain text WiFi credentials pretty standard? That’s how basically every Linux-y WiFi connected toy I own does it. It’s how all my raspberry pi’s are set up...
If someone gets into your house to steal your lighbulb and cut it open, you probably have bigger problems than your wifi password being stolen. Realistically you probably had it written on a post-it note on the router or your fridge.
The second is the same, if someone not only steals the bulb, but also writes a replacement firmware, flashes it, glues it together well enough for you to not notice, and then breaks into your house again to replace it without you noticing, sure they can inject packets into your home wifi, but they already have access to your house, why not just mess with your router directly?
The third is inexcusable, yes
It depends what exactly the keys are used for. If it's just for secure communication between the app and the bulb, and the keys are different for each bulb, I don't see any issue with this.
It's possible this certificate isn't that and is instead reused across all bulbs. We don't know that. And even if that is the case, there are no details on what this certificate is even used for that would allow us to determine if this is any sort of security problem.
No house-breaking is necessary. I could just go and buy a super fancy smart bulb and give it to you. You don't need your old insecure smart bulb any more so you put it in the bin. I take it from your bin. Now I have access to your network.
Your tech-savvy neighbour is the threat 99.99% of people should worry about, not a nation-state funded intelligence agency.
You have a really pessimistic view of neighbors, I must say. If my neighbor walked up to me and asked for my wifi password, I'd probably give it to them.
IMO the threat 99.99% of people should worry about are botnets, whether created by state-level actors, criminal gangs, or script kiddies. These vulnerabilities are not interesting for those purposes.
Granted, it's going to take longer (perhaps), but chances are you'll never notice until it is too late. Of course, most users won't notice new devices on their Wifi anyway.
People keep forgetting that Wifi is per definition insecure. It's not a point to point technology, and every single packet you send is broadcast in a wide area around you. Furthermore, all current authentication methods, WEP/WPA/WPA2 (excluding WPA3 for now, as it has yet to see wide adoption), have all been cracked in one way or another.
People sure should have a dedicated IoT network, but in the grand scheme of things, home networks are not usually that sensitive, as in no important yet unencrypted service will be exposed internally as it is typically the case in enterprise networks.
That’s a pretty far fetched social engineering scheme if you ask me.
To me the most compelling vector is actually selling compromised smart bulbs online that phone home and do more malicious stuff. In which case, the internal security of the device is irrelevant.
I don’t see anyone throwing out a working $30 light bulb.
Depending on what it's used for, it's not worse than the second, or am I missing something? I assume it's just for checking the signature of uploaded firmware.
The first scenario seems unrealistic, since people who are important enough to hack tend to also pay attention to the security of their devices and how they dispose of their trash [0]. The second seems unrealistic because the chances of it happening seem slim to none.
[0]: https://theoutline.com/post/3994/it-is-weirdly-hard-to-steal...
Either you trust the lightbulb provider to protect your creds better or don't use it. In my opinion the lifx is reasonably protected and far from being the worst offender here: the attack doesnt work over the air, and depends on physical access to a pre-setup bulb and involves physical labour to access the credentials (needs cutting out the board, removing protecting glue from the board, dumping firmware). This is not really mass-exploitable. Services like wigle will allow to see where the wifi is located though, but the bar for attacking is pretty high.
Have a look here for really awfull IoT sec:
Lightbulbs? Not really. Especially for people who don't work in this field.
- sale of used smart TV
- thrown out wifi range extenders
- used wifi enabled cameras
- your smart fridge, toaster, whatever
You will not get Google Home Mini / Alexa levels of security with these.
The mobile apps are fine, but the firmware just seems incredibly... not smart.
For example if you enable a schedule to address your circadian rhythm, then turn the light off with a wall switch at one point in the schedule and turn it back at another time. The light makes zero attempt to adjust its brightness and colour it just stays at the old setting.
Sure it hasn't had power, but it's not that hard to grab the date/time via NTP. Ideally there'd be a tiny battery just keeping a clock ticking over.
That's what I would expect as an override mechanism for the scheduled behavior: turning off and on sets regular as opposed to schedules brightness.
I'll try explain in greater detail, LIFX bulbs allow you to set a brightness and colour curve that's supposed to represent the colour and brightness at any time of day. Instead of adhering to this curve, if you turn the light off at the switch at midday, and you turn the light on again at midnight you'll be blasted with bright white/blue light, rather than dim yellow light that you've configured.
I'd say that's instantly unforgivable - if support had confirmed to me that this was expected I would have immediately returned my bulbs - they did not.
Even being a technical person and reasoning that they probably don't have a battery. The very least the light could do is fetch the current time of day then fade to the correct setting ASAP. Instead, the daily schedule, which seems to be made up of "start" and "end" points, doesn't seem to correct until hours later when the next start/end point is hit.
Like many others, I run circadian rhythm software on my monitors/displays. If I turn my computer, tablet or mobile phone off at midday, and on again at midnight I don't expect it to blast me in the face with blue light. Thankfully no other devices I own have this glaring fault.
The idea is that I can schedule the lights to do their thing or I can control via a phone app, but if someone else is at my house they can always just turn a light off and on at the switch to reset to full brightness.
I actually do this often when I need bright light in a room that is currently dim and I don't want to pull out my phone and tap the widget. Likewise, if my WiFi access point was being flaky for whatever reason, I would not want to be stuck with lights in some dimmed or colored state all the time. I'd want a way to make them fail back to being regular light bulbs.
I think that's the main idea. You get all the fancy scheduling and remote control, but in the end, you need a simple way for them to fall back to being plain old light bulbs if something isn't working.
Unfortunately, that's not the case. I gave the example of going from day to night, and the bulb being bright around midnight. However, my wife gets equally frustrated in the morning, when she turns on the light in our ensuite and it's dim because it was last on late the night before.