
Pwn the LIFX Mini white - pbowyer
https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/
======
alanfranzoni
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.

------
donatj
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...

------
dmitrygr
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

~~~
onion2k
_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.

~~~
8fingerlouie
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.

~~~
yellowapple
Why go with something in the garden? If you're an evil wifi-stealing neighbor,
surely you're already within wireless range, no?

------
Benjamin_Dobell
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_
> 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
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.

~~~
axiometry
You're not really supposed to power cycle smart home devices. I would suggest
just getting a smart switch.

~~~
_pmf_
I can't tell if this is meant sarcastically or not.

------
dpeck
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.

------
dang
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.

------
stefan_
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
Could be "shipped and maintained" code in a container? Don't think you can
read much in to the name.

