7 ms·

Pwn the LIFX Mini white

53 points by pbowyer 8y ago

dang 8y ago
Url changed from https://boingboing.net/2019/01/29/fiat-lux.html https://boingboing.net/2019/01/29/fiat-lux.html, which points to this.
dmitrygr 8y ago
The first two points are unreasonable. 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
- fyfy18 8y ago
  > 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.
  - dmitrygr 8y ago
    Including private keys of any sort in the firmware is kind of a no no
    - alanfranzoni 8y ago
      Not necessarily, if the private key is different for every device. What would you have done instead?
      - dmitrygr 8y ago
        seems to be the same in all bulbs :(
    - jon-wood 8y ago
      You need some way for the device to communicate with your backend, and private keys work pretty well. For the devices I work on these keys are unique for each device, and transferred over to it during the setup process.
    - stefan_ 8y ago
      Provisioning each device with a unique certificate signed by a vendor CA is what I would call absolute best practice. 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.
- achamayou 8y ago
  But if someone gets a bulb from your bins that you’ve thrown away because it was defective in some way, and gets access to your WiFi that way, it’s a bit annoying.
  - ce4 8y ago
    It's the same with used hard drives: It's your fault if you throw away unshredded/unwiped disks.
    - PinguTS 8y ago
      Explain that to Average Joe.
    - newaccoutnas 8y ago
      Indeed, but will a non-tecnical user know that. It's been of increasing frequency non-technical users ask for disks to be wiped though, they are aware it contains sensitive information... but a light bulb? Maybe no lightbulb moment for them.
      - ce4 8y ago
        I don't know how to properly address this without wiping. Maybe not use wifi for the bulbs in the first place or not use IoT at all? Consumers will not care about that. 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: https://mjg59.dreamwidth.org/40397.html https://mjg59.dreamwidth.org/40397.html
        newaccoutnas 8y ago
- onion2k 8y ago
  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. 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.
  - brohee 8y ago
    The WiFi password will be there in any case, obfuscating it is not a big hurdle, and asking a secure element in a $30 lightbulb is unreasonable in a world where many PC still ship without a TPM chip. 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.
  - kortilla 8y ago
    Why would I throw away a perfectly good led smart bulb just because I got another one? That’s a pretty far fetched social engineering scheme if you ask me.
    - nkozyra 8y ago
      Yeah, I don't find it particularly compelling. 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.
      - general8bitso 8y ago
        This would be trivial with Amazon comingling inventory.
  - 8fingerlouie 8y ago
    Or i could just dump a Raspberry Pi Zero W attached to a 10000 mAh power bank in your garden, and wait for it to capture a 4 way handshake. Retrieve the data from the Pi, and throw some serious cloud computing power at it while bruteforcing the password. 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.
- general8bitso 8y ago
  So, if you had such a lightbulb, and it stopped working, and you put it in your garbage, could somebody not take it, find your pw, and the access your wifi network? Maybe even some ARP poisoning or change your dns servers?
- _pmf_ 8y ago
  > The third is inexcusable, yes 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.
  - dmitrygr 8y ago
    to check sigs you need public key, not private
- donatj 8y ago
  A friends ISP provided router literally has it written on the back. Also don’t forget WPS Push Button access.
alanfranz 8y ago
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 8y ago
  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.
Benjamin_Dobell 8y ago
Attack vector details are a bit sketchy, but there's at the very least some concerns raised. Particularly surrounding that private key. However, I will say that I'm not at all surprised that the firmware isn't of the highest quality. I just picked up some LIFX bulbs a couple of months ago and have been hugely disappointed with the firmware. 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.
- _pmf_ 8y ago
  > 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. 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.
  - Benjamin_Dobell 8y ago
    Probably just a poor explanation by me. The behaviour I'm attempting to explain is definitely not what anyone would expect - well unless you're technically inclined and somehow expect it to fail. There's 100s of reports of similar issues running back years (I've also reported it to support myself). 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.
dpeck 8y ago
tldr: people generally put WAY too much trust in WiFi security, and think that encrypted at rest with the keys still on the same device matters.
stefan_ 8y ago
The author missed the biggest problem of them all, which is the debug strings ("/home/sam") indicating this is shipped production firmware built on some developers personal computer (hi, sam).
- pbhjpbhj 8y ago
  Could be "shipped and maintained" code in a container? Don't think you can read much in to the name.
donatj 8y ago
The attack vector is weird. Having LIFX bulbs personally, I’m going to notice if you steal one of my light bulbs pretty quickly. I’m also going to assume that the vast majority of LIFX bulbs are in private residences. I highly doubt any high security areas are using WiFi connected light bulbs. 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...

53 points by pbowyer 8y ago

dang 8y ago

Url changed from https://boingboing.net/2019/01/29/fiat-lux.html https://boingboing.net/2019/01/29/fiat-lux.html, which points to this.

dmitrygr 8y ago

The first two points are unreasonable. 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

fyfy18 8y ago
> 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.
- dmitrygr 8y ago
  Including private keys of any sort in the firmware is kind of a no no
  - alanfranzoni 8y ago
    Not necessarily, if the private key is different for every device. What would you have done instead?
    - dmitrygr 8y ago
      seems to be the same in all bulbs :(
  - jon-wood 8y ago
    You need some way for the device to communicate with your backend, and private keys work pretty well. For the devices I work on these keys are unique for each device, and transferred over to it during the setup process.
  - stefan_ 8y ago
    Provisioning each device with a unique certificate signed by a vendor CA is what I would call absolute best practice. 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.
achamayou 8y ago
But if someone gets a bulb from your bins that you’ve thrown away because it was defective in some way, and gets access to your WiFi that way, it’s a bit annoying.
- ce4 8y ago
  It's the same with used hard drives: It's your fault if you throw away unshredded/unwiped disks.
  - PinguTS 8y ago
    Explain that to Average Joe.
  - newaccoutnas 8y ago
    Indeed, but will a non-tecnical user know that. It's been of increasing frequency non-technical users ask for disks to be wiped though, they are aware it contains sensitive information... but a light bulb? Maybe no lightbulb moment for them.
    - ce4 8y ago
      I don't know how to properly address this without wiping. Maybe not use wifi for the bulbs in the first place or not use IoT at all? Consumers will not care about that. 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: https://mjg59.dreamwidth.org/40397.html https://mjg59.dreamwidth.org/40397.html
      - newaccoutnas 8y ago
onion2k 8y ago
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. 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.
- brohee 8y ago
  The WiFi password will be there in any case, obfuscating it is not a big hurdle, and asking a secure element in a $30 lightbulb is unreasonable in a world where many PC still ship without a TPM chip. 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.
- kortilla 8y ago
  Why would I throw away a perfectly good led smart bulb just because I got another one? That’s a pretty far fetched social engineering scheme if you ask me.
  - nkozyra 8y ago
    Yeah, I don't find it particularly compelling. 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.
    - general8bitso 8y ago
      This would be trivial with Amazon comingling inventory.
- 8fingerlouie 8y ago
  Or i could just dump a Raspberry Pi Zero W attached to a 10000 mAh power bank in your garden, and wait for it to capture a 4 way handshake. Retrieve the data from the Pi, and throw some serious cloud computing power at it while bruteforcing the password. 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.
general8bitso 8y ago
So, if you had such a lightbulb, and it stopped working, and you put it in your garbage, could somebody not take it, find your pw, and the access your wifi network? Maybe even some ARP poisoning or change your dns servers?
_pmf_ 8y ago
> The third is inexcusable, yes 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.
- dmitrygr 8y ago
  to check sigs you need public key, not private
donatj 8y ago
A friends ISP provided router literally has it written on the back. Also don’t forget WPS Push Button access.

alanfranz 8y ago

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 8y ago
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.

Benjamin_Dobell 8y ago

Attack vector details are a bit sketchy, but there's at the very least some concerns raised. Particularly surrounding that private key. However, I will say that I'm not at all surprised that the firmware isn't of the highest quality. I just picked up some LIFX bulbs a couple of months ago and have been hugely disappointed with the firmware. 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.

_pmf_ 8y ago
> 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. 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.
- Benjamin_Dobell 8y ago
  Probably just a poor explanation by me. The behaviour I'm attempting to explain is definitely not what anyone would expect - well unless you're technically inclined and somehow expect it to fail. There's 100s of reports of similar issues running back years (I've also reported it to support myself). 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.

dpeck 8y ago

tldr: people generally put WAY too much trust in WiFi security, and think that encrypted at rest with the keys still on the same device matters.

stefan_ 8y ago

The author missed the biggest problem of them all, which is the debug strings ("/home/sam") indicating this is shipped production firmware built on some developers personal computer (hi, sam).

pbhjpbhj 8y ago
Could be "shipped and maintained" code in a container? Don't think you can read much in to the name.

donatj 8y ago

The attack vector is weird. Having LIFX bulbs personally, I’m going to notice if you steal one of my light bulbs pretty quickly. I’m also going to assume that the vast majority of LIFX bulbs are in private residences. I highly doubt any high security areas are using WiFi connected light bulbs. 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...