Pwn the LIFX Mini white

The Device

LIFX mini White

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:

Classic tools for hardware hacking

Work in progress:

Fireproof paste all around

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.

Simple setup

Connections from top to bottom = GND, VCC 3.3V, ADBUS0, ADBUS1.

Once VCC is powered, the LIFX LCM3 is booting:

UART activity during boot. It connects directly to the SSID (here KabelBox-0570)

Vulnerability n*1: Wi-Fi credentials stored in plaintext into the firmware

Dumping the firmware is straightforward. ESP32 is set in Download Mode:

Download mode activated

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.

WPA2 key is stored in plaintext (ASCII encoded)

Vulnerability n*2: No security settings (at all)

To check the device configuration , E-fuses values are dumped:

espefuse.py --port /dev/ttyUSB0 summary
Efuses content

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…

enjoy

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.

22 Replies to “Pwn the LIFX Mini white”

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

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

      1. 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 🙂

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

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

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

  2. 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!

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *