IoT Goes Nuclear: Creating a ZigBee Chain Reaction

Eyal Ronen, Colin O’Flynn, Adi Shamir and Achi-Or Weingarten

Creating an IoT worm

Within the next few years, billions of IoT devices will densely populate our cities. In this paper we describe a new type of threat in which adjacent IoT devices will infect each other with a worm that will spread explosively over large areas in a kind of nuclear chain reaction, provided that the density of compatible IoT devices exceeds a certain critical mass. In particular, we developed and verified such an infection using the popular Philips Hue smart lamps as a platform. The worm spreads by jumping directly from one lamp to its neighbors, using only their built-in ZigBee wireless connectivity and their physical proximity. The attack can start by plugging in a single infected bulb anywhere in the city, and then catastrophically spread everywhere within minutes, enabling the attacker to turn all the city lights on or off, permanently brick them, or exploit them in a massive DDOS attack. To demonstrate the risks involved, we use results from percolation theory to estimate the critical mass of installed devices for a typical city such as Paris whose area is about 105 square kilometers: The chain reaction will fizzle if there are fewer than about 15,000 randomly located smart lights in the whole city, but will spread everywhere when the number exceeds this critical mass (which had almost certainly been surpassed already).

To make such an attack possible, we had to find a way to remotely yank already installed lamps from their current networks, and to perform over-the-air firmware updates. We overcame the first problem by discovering and exploiting a major bug in the implementation of the Touchlink part of the ZigBee Light Link protocol, which is supposed to stop such attempts with a proximity test. To solve the second problem, we developed a new version of a side channel attack to extract the global AES-CCM key that Philips uses to encrypt and authenticate new firmware. We used only readily available equipment costing a few hundred dollars, and managed to find this key without seeing any actual updates. This demonstrates once again how difficult it is to get security right even for a large company that uses standard cryptographic techniques to protect a major product.

Possible Worm applications

Bricking attack

An attacker can use the worm for a city-wide bricking attack. The malicious firmware can disable additional firmware downloads, and thus any effect caused by the worm (blackout, constant flickering, etc.) will be permanent. There is no other method of reprogramming these devices without full disassemble (which is not feasible). Any old stock would also need to be recalled, as any devices with vulnerable firmware can be infected as soon as power is applied.

Wireless network jamming

The IEEE 802.15.4 standard which ZigBee runs over uses the 2.4GHz ISM (Industrial, Scientific, Medical) license-free band. This band is widely used by many standards, including IEEE 802.11b/g (n mode supports both 2.4GHz and 5GHz bands). These 802.15.4 SoC devices have a special `test mode’ which transmits a continuous wave signal that is used during the FCC/CE emission certification process. This test signal can be tuned to overlap on any of the 2.4 GHz 802.11 channels (or sweep between them), and can be used as a very effective jammer. Using many infected lamps at once, WiFi communication (or any other 2.4 GHz transmissions) could be disrupted in the whole city.

Attacking the electric grid

All the city’s smart lamps can be scheduled to simultaneously turn on and off multiple times. The sudden changes in power consumption can have a detrimental effect on the electric grid.

Causing epileptic seizures

By repeatedly flashing the lights at the right frequency, it is possible to induce epileptic seizures in photosensitive people on a large scale.

Philips Hue Malicious software update

By extracting the global keys Philips uses to encrypt and authenticate new firmwares, we were able to load a malicious over-the-air firmware update. In this image from the official Hue app, you can see the infected light software version: “IrradiateHue”

Takeover attack demonstration

To be able to load the malicious update, we must first make the lamps join our own network. We accomplish this by using a novel takeover attack against installed lamps. To test our attack we have built a fully autonomous attack kit. We have tested our attack in two scenarios: War-driving and War-flying against ZigBee networks.

We have tested our attack kit against lights installed in our faculty in the Weizmann Institute of Science. We can cause lights to flicker at range of over 70 meters while driving, as you can see in this video:

For our war-flying we found a more interesting target. An office building in the city of Beer Sheva hosting some well-known security companies and also the Israeli CERT. Several Philips Hue lights were installed in one floor to test our attack. We have mounted our attack kit on a drone and started our attack from a range of 350 meters

The video starts with an external footage of the drone taking off at a range of 350 meters. The evaluation board of the attack kit can be seen hanging on a one meter USB cable beneath the drone. After the takeoff we switch to the drone’s high quality camera. Right after liftoff it is already possible to see the light effects starting in the distance. As the drone gets closer to the building, the ZigBee channel gets more reliable, and we are able to affect more lights, and the flickering becomes more regular. When the drone hovers in front of the building, the second phase of our attack can be seen. The lights have been “kidnaped” from their controller and are crying for help, signaling S O S repeatedly in Morse code.

Full Disclosure Status

We have made full disclosure to Philips Lighting, including all the technical details and suggestions for a fix. They have already confirmed and fixed the takeover vulnerability. OTA updates are available.

Publications

Talks