Lightbulb Worm

From Embedded Lab Vienna for IoT & Security
Jump to: navigation, search

Introduction

The Lightbulb Worm can attack all Smart Lightbulbs but in this example everything is done with the Philips Hue System.In this System one or more Lightbulbs are communicating over the ZigBee Light Link Protocol with a Bridge that is connected to the Internet.

HueSystem.jpg

The Lightbulb Worm itself is purely theoretical but all the parts that make it possible have been practically carried out.

Attack Overview

At first, modified Hardware is used to bypass a proximity check so that the full 70 - 400m Range (Indoor - Outdoor) can be used to reconnect the Lightbulb to another Network. The Firmware Update Process was reverse engineered, allowing the attacker to install any homemade firmware on the Lightbulb. This Firmware can now theoretically block other Updates, thus bricking the Lamp, and run any arbitrary code, including infecting other Lightbulbs in Range. With the proximity check disabled, there is now a approxiomately 100m range in which other Lightbulbs can be infected thus there is a possibility to infect a whole city worth of Lamps if they are in close range to each other.

Bypassing the Proximity Check

The Proximity check is carried out on every ZigBee Ligt Link compliant stack and product to ensure that only a very close (~1m) Device can reset and start a new Network connection for another Device. This is made possible by checking the received signal strength indication (RSSI) and if this value is above a certain threshold, the Device saves the Message Parameters as Transaction ID. Upon receiving any other Message, it checks the Transaction ID and drops the Message if the ID is not present. A Transaction ID of 0 does not need to be checked because there is a basic sanity check that rules it out beforehand.

This sanity check is only done with scan Requests.

Any other Message with a Transaction ID of 0 is received and processed as valid. That means if a Broadcast with a Transaction ID of 0 and the content: "Reset to Factory default" is sent, the Lightbulb will process it. Broadcasts of this Message are normally not allowed but the Lightbulbs do not care about that. After the reset only a ZigBee Beacon Message needs to be sent to connect them to the attackers Network. Now the Lightbulbs are ready for a custom firmware.

Reverse Engineering the Firmware Update Process

A side channel power analysis of a disassembeled Lightbulb and Bridge confirmed that the Firmware for a Lightbulb has to be encrypted and authenticated with AES-CCM (CTR mode with CBC-MAC). It also deduced that the same Key is used to encrypt and authenticate. Also the Lightbulbs all use the same global Key which was of course leaked. Through all of this the Firmware Update Process is now clear and a Firmware File can be obtained and modified

Firmware from Scratch

The first Test was just a few changes to the Update File which was then re-encrypted to see if the Lightbulb accepts it, which it did. After that a Program was written to read the Flash Memory so that the File Layout of the Update File can be deduced. With the Layout known, any arbitratry Code can be implemented in the Firmware.

Possible Effects

Bricking the Bulb
Any Effect will be permanent (Blackout, constant Flickering)
Can only be reprogrammed at the PCB Level
Wireless Network Jamming
High Power Transmissions over 2,4GHz
Data infiltration and exfiltration
by changing and reading data such as Model or Version
Epileptic Seizures

Countermeasures

Philips has already provided a patch to the Proximity Check to ensure it only works over a Distance of approximately 1m

Other Countermeasures which should be taken
Each Lightbulb should have a unique key
Asymmetric Cryptography should be used for Software Verification


Hardware

Philips Hue Bridge 2.0, Gateway

Philips Hue White LED E27 9.5W/827, white