Security consultant hacks light bulb

Security consultant Context Information Security has uncovered a security weakness in an Australian inventor’s Wi-Fi-enabled, energy-efficient LIFX LED light bulb that can be controlled from a smartphone.

By gaining access to the master bulb, Context was able to control all connected light bulbs and expose user network configurations. The bulb manufacturer LIFX has since worked closely with Context to promptly patch the issue, which is now available as a firmware update. A spokesperson, Simon Walker from LIFX, says that, “Prior to the patch, no one other than Context had exposed this vulnerability, most likely due to the complexity of the equipment and reverse engineering required.”

Below are some insights from Alex Chapman, Principal Consultant, Context, about how the company was able to hack the bulb.

Context chose the light bulb due to its use of emerging wireless network protocols, the way it came to market and its appeal to technophiles. LIFX CEO and founder Phil Bosua had introduced the project idea on crowdfunding website Kickstarter in 2012, where it proved hugely popular. LIFX Labs raised over 13 times its original funding target.

LIFX bulbs connect to a Wi-Fi network in order to allow them to be controlled using a smartphone application. In a situation where multiple bulbs are available, only one bulb will connect to the network. This ‘master’ bulb receives commands from the smartphone application and broadcasts them to all other bulbs over an 802.15.4 6LoWPAN wireless mesh network. In the event of the master bulb being turned off or disconnected from the network, one of the remaining bulbs elects to take its position as the master and connects to the Wi-Fi network ready to relay commands to any further remaining bulbs. This architecture requires only one bulb to be connected to the Wi-Fi at a time, which has numerous benefits including allowing the remaining bulbs to run on low power when not illuminated, extending the useable range of the bulb network to well past that of just the Wi-Fi network and reducing congestion on the Wi-Fi network.

The use of emerging wireless communication protocols, mesh networking and master/slave communication roles interested the hacker in us, so we picked up a few bulbs and set about our research. The research was performed against version 1.1 of the LIFX firmware. Since reporting the findings to LIFX, version 1.2 has been made available for download.

Analysing the attack surface

There are three core communication components in the LIFX bulb network: smartphone to bulb communication, bulb Wi-Fi communication and bulb mesh network communication. Due to the challenges involved, Context decided to begin the search for vulnerabilities in the intra-bulb 802.15.4 6LoWPAN wireless mesh network. The researchers decided to investigate how the bulbs shared the Wi-Fi network credentials between themselves over the mesh network. 6LoWPAN is a wireless communication specification built on IEE802.15.4, the same base standard used by Zigbee, designed to allow IPv6 packets to be forwarded over low-power personal area networks (PANs).

In order to monitor and inject 6LoWPAN traffic, a peripheral device that uses the 802.15.4 specification was required. The device chosen for this task was the ATMEL AVR Raven installed with the Contiki 6LoWPAN firmware image. This presented a standard network interface from which the researchers could monitor and inject network traffic into the LIFX mesh network.

Protocol analysis

The Contiki-installed Raven network interface enabled the researchers to monitor and inject network traffic into the LIFX mesh network. The protocol observed appeared to be, in the most part, unencrypted. This allowed the researchers to easily dissect the protocol, craft messages to control the light bulbs and replay arbitrary packet payloads.

Monitoring packets captured from the mesh network while adding new bulbs, the researchers were able to identify the specific packets in which the Wi-Fi network credentials were shared among the bulbs.

The onboarding process consists of the master bulb broadcasting for new bulbs on the network. A new bulb responds to the master and then requests the Wi-Fi details to be transferred. The master bulb then broadcasts the Wi-Fi details, encrypted, across the mesh network. The new bulb is then added to the list of available bulbs in the LIFX smartphone application.

Wireshark 6LoWPAN packet capture

The Wi-Fi details, including credentials, were transferred as an encrypted binary blob. Further analysis of the onboarding process identified that we could inject packets into the mesh network to request the Wi-Fi details without the master bulb first beaconing for new bulbs. Further to this, requesting just the Wi-Fi details did not add any new devices or raise any alerts within the LIFX smartphone application.

At this point, the researchers could arbitrarily request the Wi-Fi credentials from the mesh network but did not have the necessary information to decrypt them. In order to take this attack any further, they would need to identify and understand the encryption mechanism in use.

Obtaining the firmware

In the normal course of gaining an understanding of encryption implementations on new devices, we first start with analysing the firmware. In an ideal world, this is simply a case of downloading the firmware from the vendor website, unpacking, decrypting or otherwise mangling it into a format that’s usable. However, at the time of the research the LIFX device was relatively new to market, therefore the vendor had not released a firmware download to the public that the researchers could analyse. They had to fall back to Plan B and obtain the firmware themselves.

In order to extract the firmware from the device, the researchers had to gain physical access to the microcontrollers embedded within; an extremely technical process, which to the layman may appear to be no more than hitting it with a hammer until it spills its insides. Once removed from the casing, the PCB is accessible, providing the team with the access they required.

Extracted LIFX PCB

It should be noted that public sources can be consulted if only visual access to the PCB is needed. The American Federal Communications Commission (FCC) often release detailed tear downs of communications equipment which can be a great place to start if the hammer technique is considered slightly over the top.

Analysing the PCB, the researchers were able to determine that the device is made up primarily of two SoC ICs: a Texas Instruments CC2538 that is responsible for the 6LoWPAN mesh network side of the device communication and an STMicroelectronics STM32F205ZG (marked LIFX LWM-01-A) that is responsible for the Wi-Fi side of the communication. Both of these chips are based on the ARM Cortex-M3 processor. Further analysis identified that JTAG (Joint Test Action Group) pins for each of the chips were functional, with headers presented on the PCB.

Once the correct JTAG pins for each of the chips were identified, a process which required manual pin tracing, specification analysis and automated probing, we were ready to connect to the JTAG interfaces of the chips. In order to control the JTAG commands sent to the chips, a combination of hardware and software is required. The hardware used in this case was the open hardware BusBlaster JTAG debugger, which was paired with the open source Open On-Chip Debugger (OpenOCD). After configuring the hardware and software pair, we were in a position where we could issue JTAG commands to the chips.

At this point we can merrily dump the flash memory from each of the chips and start the firmware reverse engineering process.

Reversing the firmware

Now we are in possession of two binary blob firmware images required to identify which image is responsible for storing and encrypting the Wi-Fi credentials. A quick ‘strings’ on the images identified that the credentials were stored in the firmware image from the LIFX LWM-01-A chip.

Loading the firmware image into IDA Pro, we could then identify the encryption code by looking for common cryptographic constants: S-Boxes, forward and reverse tables and initialisation constants. This analysis identified that an AES implementation was being used.

AES, being a symmetric encryption cipher, requires both the encrypting party and the decrypting party to have access to the same pre-shared key. In a design such as the one employed by LIFX, this immediately raises alarm bells, implying that each device is issued with a constant global key. If the pre-shared key can be obtained from one device, it can be used to decrypt messages sent from all other devices using the same key. In this case, the key could be used to decrypt encrypted messages sent from any LIFX bulb.

References to the cryptographic constants can also be used to identify the assembly code responsible for implementing the encryption and decryption routines. With the assistance of a free software AES implementation, reversing the identified encryption functions to extract the encryption key, initialisation vector and block mode was relatively simple.

The final step was to prove the accuracy of the extracted encryption variables by using them to decrypt Wi-Fi credentials sniffed off the mesh network.

Putting it all together

Armed with knowledge of the encryption algorithm, key, initialisation vector and an understanding of the mesh network protocol, we could then inject packets into the mesh network, capture the Wi-Fi details and decrypt the credentials, all without any prior authentication or alerting of our presence. Success.

It should be noted, since this attack works on the 802.15.4 6LoWPAN wireless mesh network, an attacker would need to be within wireless range, 30 metres, of a vulnerable LIFX bulb to perform this attack, severely limiting the practicality for exploitation on a large scale.

Vendor fix

Context informed LIFX of the research findings - LIFX was proactive in its response. Context has since worked with LIFX to help it provide a fix this specific issue, along with other further security improvements. The fix, which is included in the new firmware available at http://updates.lifx.co/, now encrypts all 6LoWPAN traffic, using an encryption key derived from the Wi-Fi credentials, and includes functionality for secure onboarding of new bulbs onto the network.

With any internet connecting device, whether phone, laptop or light bulb, there is always a chance of someone being able to hack it.