Pwn the LIFX Mini white(limitedresults.com)
limitedresults.com
Pwn the LIFX Mini white
https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/
61 comments
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.
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.
If someone pulled the SDCard out of my Raspberry Pi they would have my wifi credentials too.
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.
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.
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.
What I guess you are thinking about is a problem too, defaults, but this is not what the article point 1 is about.
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.
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.
> 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.
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.
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.
I qualified my point with "largely" to be clear that I'm not saying it's unavoidable.
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.
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.
A down side is that there's no nicely integrated module like the ESP8266 available for diy.
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.
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.
Passwords? Maybe WPS, or a variant, can be used for IoT devices?
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.
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.
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.
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.
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?
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 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.
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.
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...
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...
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
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
> 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 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.
Including private keys of any sort in the firmware is kind of a no no
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.
Not necessarily, if the private key is different for every device. What would you have done instead?
seems to be the same in all bulbs :(
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.
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.
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.
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.
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.
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.
Why go with something in the garden? If you're an evil wifi-stealing neighbor, surely you're already within wireless range, no?
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.
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.
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.
That’s a pretty far fetched social engineering scheme if you ask me.
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.
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.
This would be trivial with Amazon comingling inventory.
> 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.
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.
If my neighbor is an evil adversary and they give me a lightbulb, why wouldn’t they just have the lightbulb modified to send them an email with the wifi password when I enter it?
> 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 don’t see anyone throwing out a working $30 light bulb.
I don’t see anyone throwing out a working $30 light bulb.
A friends ISP provided router literally has it written on the back. Also don’t forget WPS Push Button access.
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?
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.
How realistic of an attack vector is this though? LED bulbs often last 10 years or more. So either somebody knows you have an insecure light bulb and finds you important enough to regularly check whether you threw it out, or coincidentally, right when you throw out your smart bulb some tech savvy person went dumpster diving, found the bulb and really wanted to access your WiFi.
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...
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...
Dumpster diving no longer exists?
It's the same with used hard drives: It's your fault if you throw away unshredded/unwiped disks.
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.
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
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
What are world we live in where we have to put trust in our lightbulb provider
Given that bulbs have always been electrical devices capable of malfunctioning and burning our house down, we have been living in it for decades.
Hard drives are designed to store data, it is very explicit that they have data on them.
Lightbulbs? Not really. Especially for people who don't work in this field.
Lightbulbs? Not really. Especially for people who don't work in this field.
People throw away or resell other stuff as well that has Wifi credentials in it (or will have in the future):
- 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.
- 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.
Explain that to Average Joe.
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.
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.
> 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.
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.
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.
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.
I've got some Hue bulbs and while I believe newer versions of the hub/lamps have the option to return to last setting when power cycled via wall switch, I can't say the alternative is necessarily worse in terms of the user.
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.
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.
If this was defined behaviour and it fell back to being a dumb light, I'd be disappointed, but could live with that.
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.
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.
You're not really supposed to power cycle smart home devices. I would suggest just getting a smart switch.
I can't tell if this is meant sarcastically or not.
Any recommendations - specifically for replacing physical light switches?
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.
Url changed from https://boingboing.net/2019/01/29/fiat-lux.html, which points to this.
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).
Could be "shipped and maintained" code in a container? Don't think you can read much in to the name.
"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.