The Device
Bought on Amazon (30 euros).
The lightbulb is plugged. LIFX app is installed on an Android smartphone. Wi-Fi connection is set. The lightbulb works fine.
Wunderbar, easy setup.
The Teardown
Butcher mode activated:
Work in progress:
The most difficult is to clean the board and remove this paste.
The Setup
The major component of the module is identified as ESP32D0WDQ6, a SoC from ESPRESSIF.
Datasheet is available here.
SDK & Tools are also available on GitHub.
Some pins are soldered to easily connect with a FT2232H board. A little bit of PCB Reverse is needed.
Connections from top to bottom = GND, VCC 3.3V, ADBUS0, ADBUS1.
Once VCC is powered, the LIFX LCM3 is booting:
Vulnerability n*1: Wi-Fi credentials stored in plaintext into the firmware
Dumping the firmware is straightforward. ESP32 is set in Download Mode:
then launch the read flash command from esp-tool to access the content of the memory:
esptool.py -p /dev/ttyUSB0 -b 460800 read_flash 0 0x200000 flash.bin
A simple research into the binary file flash.bin using an hex editor or even string|grep command is enough to retrieve the Wi-Fi credentials.
Vulnerability n*2: No security settings (at all)
To check the device configuration , E-fuses values are dumped:
espefuse.py --port /dev/ttyUSB0 summary
According to the values, this device is totally open (no secure boot, no flash encryption, no JTAG disabled).
Vulnerability n*3: Root certificate and RSA private key extracted
Root certificate and RSA private key are present into the firmware and are used to connect to LIFX cloud.
Oh Jesus…
I decided to stop the investigation after that.
Conclusion
In a very short limited amount of time, three vulnerabilities have been discovered:
- Wifi credentials of the user have been recovered (stored in plaintext into the flash memory).
- No security settings. The device is completely open (no secure boot, no debug interface disabled, no flash encryption).
- Root certificate and RSA private key have been extracted.
Disclosure
- 24/05/2018:Â E-mail to LIFX. Want to discuss with their engineering team, asking for PGP keys.
- 03/10/2018: No PGP keys, no feedback from LIFX during 4 months. Report finally sent via e-mail.
- 04/10/2018: Acknowledgement from LIFX.
- 17/10/2018: LIFX team confirms the vulnerabilities, asks for a call and a 150 days disclosure.
- 23/10/2018: Call with LIFX team. 90 days disclosure agreement.
- 23/01/2019: Posted.
- 30/01/2019: LIFX statement here.
Maybe you have some valid points, but you fails to illustrate them properly. Beyond the not-so-reasonable scenario (wouldn’t you be able to tell that your bulb has been tampered with?), the analysis lacks precision.
“Wi-Fi credentials stored in plaintext into the firmware”
What is a “firmware”? You mean the device flash memory? The user must set its credentials, right? So, how is it possible that they’re “in the firmware”, if firmware is the software that gets uploaded by the factory?
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 cert authentication, but some WPS as well I believe to remember) that don’t rely on that, but they’re harder to setup and support. Sure, some devices 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 decipher. Some systems provide a secure enclave where passwords can be stored, but someway it is usually possible to get it out when you have PHYSICAL ACCESS to a device.
2) No security settings; ok, this could be improved. But most of them are physical-access only settings. The scenario here is a bit different.
3) Root certificate and RSA private key extracted
Root certificate and private key of what? 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? You say 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.
Thanks for your detailed comment.
In the second sentence, it is mentioned the Wi-Fi connection is set. The user credentials are then stored into flash memory in plaintext.
1) agree with you. Some secure storage solutions are not so resistant, some others are. Depends on the implementation.
2) We are agree, this can be improved.
3) CA is useless, we know that. But RSA private key, don’t worry, it is valuable. I decide to not give details about that. The name of the blog is Limited Results, I Hope you understand and by the way you have a pretty good analysis…
I wish you the best.
Regards
LR
Thanks for your answer, LimitedResults.
After reading about other comments that explain how the ESP32 actually has an easy-to-use “secure enclave” and secure boot facility (something that wasn’t stated in your analysis) , I probably get your point; it was possible (and easy) to add such encryption, but that wasn’t done.
About the CA vs key: I understand your “limited results” approach, but, maybe, you could provide limited but meaningful results to your audience. If your paragraph were
“Root certificate and RSA private key for a critical service are on the device”
Instead of
“Root certificate and RSA private key are present into the firmware.”
Your would have served the very same purpose.
AND…. you have dumped the unencrypted RSA private key for us, in an image. Unless it’s a dummy key (I haven’t tried parsing it, actually), you seemed to have given us the single, most important piece of private information 🙂
Hi Alan,
I give the key but I do not open the door for you, I am not the doorman.
I hope you understand my philosophy.
Regards
LR
The ESP32 SoC supports encryption of the flash contents as well as verification of the firmware image prior to boot. The fact that the manufacturer didn’t bother is unconscionable. Just enabling flash encryption would ameliorate issues 1 and 3.
Nice comment, I agree.
What is the root cert for? Connecting to LIFX cloud?
CA is not important.
For the private key, it is a critical asset.
Don’t worry all concerned persons knows that…
I just published limited results here.
Regards
LR
You were mercyfull with them 🙂
Yes I know 🙂
Regards
LR
Fix you images loading speed, assholes.
Nice to meet you, gentleman.
Could you please share the exact pinout of the wifi module? I want to hook it up, but there are more pins than you mentioned. I’d appreciate the help so I don’t have to waste the time probing them all. Thanks!
Hi,
send me a picture of your module (for email go to contact me). If I can help, I’ll do.
Happy pwning man!
Regards
LR
You should update your disclosure timeline with the date of the fix release.
Not my business.
regards
LR
Killer hacker lightbulbs! I can see the movies already!!
https://boingboing.net/2019/01/29/fiat-lux.html explains briefly why it matters that the lightbulb stores your wifi password in plain text, even when it’s been discarded.
In the early 1970s, shortly after Intel and Texas Instruments introduced the first microprocessor chips, engineers used to joke about developing a “microprocessor-controlled hammer”. With the advent of these light bulbs, the joke has become reality.
what the advantage this lamp?
Instead of throwing a brick through a window and getting on the LAN, now you can just steal a porch light and crack it open like a walnut.
The LifX lightbulb was collecting analytics. Surprisingly I received a hostile reply concerning the state of privacy in the world: I should expect none. An amazon review deems these “hardware malware”. https://www.amazon.com/gp/customer-reviews/RVSM421NGTI1Z/ This combined with your article resulted in abandoning lifx for hue. Thank you for your research.
Shame on LifX