Blog: Internet Of Things

Hijacking Philips Hue

David Lodge 16 May 2018

We were filming a smart home hacking piece on the 5th May this year. Like most home users, the Wi-Fi PSK wasn’t strong enough, so we cracked it and joined the network.

The user had a Philips Hue lighting system. None of us here had looked at Hue before – we made an assumption after the previous Zigbee issues (link opens PDF) that security had been sorted.

We were NOT expecting to see API keys being passed in plaintext!

Seriously, the security model of the Hue control system is dependent on the user having a strong Wi-Fi key.

This is a known issue: it seems that Philips are well aware of it. Their Developer Programme lead story is about their coming implementation of SSL: https://www.developers.meethue.com/

Here’s how easy it is to exploit

The basic configuration, before authentication

Build in API debugger at /debug/clip.html

Lights configuration. What colour do you fancy today?

Making the lights flash, freaking the user out on a dark winter evening?

Fixing this

Erm – this relies on your users setting strong Wi-Fi keys on their wireless routers. That’s not good enough.

Philips Hue are releasing SSL support shortly, but will continue to support plain text for some time for compatibility reasons

So attackers intent on messing with your lighting can have a field day for some time to come.

Conclusion

Seeding SSL connections requires a source of strong entropy. This is always a challenge on constrained IoT devices.

I do hope that Hue have given really serious thought to how to establish an encrypted connection that can’t easily be decrypted.

There’s potentially an issue around trust root too:

  1. You can’t put a trusted (by a browser) cert on the device easily, mainly because server name validation is going to fail.
  2. You then have the problem of generating per-device SSL keys. They need to be regenerated each time the device is factory reset.

That said, their API generation process appears to be pretty good: the key is complex and clearly consumes entropy during generation. It also requires a physical button press on the device.

Philips are also good at fixing stuff – it used to be possible to create custom APIkeys, which could be simple words. No longer…

Finally, we keep finding ‘downgrade’ attacks in IoT product: support for earlier, weaker encryption standards in legacy devices often means that encryption support in newer hubs can be sidestepped.

So, is this a huge security flaw? No, it’s messing around with your lights from a range of <50 metres or so! But it could become more concerning if the range of devices that Hue integrates with expands.

At the moment the weakness is a lack of encryption, for which Phillips have a plan and they have shown themselves able to fix security issues in the past.

Keys need to be properly trusted and signed to stop man-in-the-middle attacks through tools such as bettercap.