Security Researchers Expose Vulnerability in Philips Hue Smart Bulbs

[CarlJ]

Or is the entire idea that you can’t communicate across that barrier?

It's not that you/they can't communicate across the barrier, but rather that you/they can only communicate in very specific well-defined ways: in this instance, the Hub only communicates with local-network devices via HTTP, and only when the local device initiates the conversation. The Hub can also communicate with a few IP addresses at Philips, if you allow it to "phone home"*. This can be written as a couple ACLs in the router that say "(Hub IP address) can only send HTTP traffic to local network, and only if the other end initiates the conversation", and "(Hub IP address) can send/receive to/from (IP addresses in Philip's domain)".

As far as your original mention of WiFi - it's useful in terms of understanding networking, but doesn't come into play here, because the Hue bulbs talk ZigBee (only) to the Hub, and the Hub (only) speaks ethernet to your home network.

As an aside, the Hub is controlled by the official Hue app - and all the unofficial Hue-related apps (there are many) as well as by HomeKit, and Alexa, and probably your SmartRefrigerator - via a fairly straightforward RESTful interface over HTTP, using JSON. It's quite simple to write scripts that interact with the Hub and turn lights on/off, collect status, and such. (I've got a bunch of python scripts I use for setting up specific scenes and such - and my own custom home weather station has a touchpanel with one column reserved for buttons to select various scenes.) Anyway, if you know how to program, and wish you could make your Hue lights do some particular thing - you probably can. Their developer program is free and provides complete documentation of the interface.

*: Having the Hub "phone home" to Philips is there to allow remote (away from home) control of your lights directly from the Hue app on your phone/tablet. This is from before HomeKit (and its own flavor of remote control) was a thing. You don't really need two such methods active, and HomeKit works with any other IoT devices you have (rather than only Hue devices). So I have the remote access in the Hue app turned off, and control them remotely solely with Apple's Home app (have an Apple TV at home, which handles HomeKit command traffic between Apple and my home). I trust Apple's security more than I do Hue's.
[automerge]1580925430[/automerge]

The main issue is that Apple/Homekit rely heavily on Bonjour (mDNS) for device discovery. But mDNS normally only works within a subnet since it uses broadcasting. However, you can set up an mDNS reflector to enable mDNS across subnets. One implementation is Avahi (which can be used on Linux-based routers such as pfSense).

Nice to see someone who speaks network around these parts.

 

[imola.zhp]

True, but in some cases there are solutions. The main issue is that Apple/Homekit rely heavily on Bonjour (mDNS) for device discovery. But mDNS normally only works within a subnet since it uses broadcasting. However, you can set up an mDNS reflector to enable mDNS across subnets. One implementation is Avahi (which can be used on Linux-based routers such as pfSense). I found that it doesn't work reliably with all devices though.

So again, a lot of headache that may or may not work reliably to go from almost no chance of ever being hacked to no chance of ever being hacked. Sorry, not worth the effort.

There are some things I absolutely do not want connected. One friend of mine has a deadbolt on their front door they can unlock with an app. No. Another friend has the Amazon service where the delivery person can open the garage door to deliver packages. Again no. But now that I'm used to smart lighting there is no going back for me.

Google WiFi would be a way around this. When you set up your guest network you can specify what devices on the primary network the guest network has access to.

All of our doors have animated deadbolts. They are add-ons and you cant tell from the outside except for the garage entry door which you would have to be in the garage to see that its "smart." They all run on Home Assistant (again except for the garage door that is homekit) using zwave, not zigbee. Its great to go out the front door without any keys and have siri lock the door as you jump into a Lyft and go out for the evening.

As far as google wifi, yikes; again I'll stick with almost no chance of ever being hacked.

 

[TheColtr]

This 👏 is 👏 why👏 we 👏 need👏 HomeKit 👏 routers 👏 now 👏

sure it wouldn’t protect against non HomeKit accessories, but everyone makes the decision on what they want to buy. I’ve got all HomeKit accessories and I cannot wait for eero to launch it. The more HomeKit accessories on my network the more concerned I get with network attacks.

 

[Rigby]

So again, a lot of headache that may or may not work reliably to go from almost no chance of ever being hacked to no chance of ever being hacked. Sorry, not worth the effort.

I agree, unless you're a networking geek it's probably not worth it. But the more important it is to be careful what devices you let on your network and then make sure that they receive timely firmware updates. Choosing Homekit-enabled devices is usually a good idea since Apple imposes some rather strict security requirements on them (although that's not bullet proof as the Hue Hub shows).

 

[Suckfest 9001]

Yeah because that’s exactly what he (and no one ever) was saying. Such a derpy, hyperbolic comment. You realize the choice isn’t between just candles and smart lights?

It was obviously said that way to be humorous, which everyone here picked up on except you. So it's kind of your own fault that you're mad. Tomorrow will be a better day man.

 

[imola.zhp]

I agree, unless you're a networking geek it's probably not worth it. But the more important it is to be careful what devices you let on your network and then make sure that they receive timely firmware updates. Choosing Homekit-enabled devices is usually a good idea since Apple imposes some rather strict security requirements on them (although that's not bullet proof as the Hue Hub shows).

Excellent advice, keep your devices up to date just like you would with any computer or phone and if a device starts acting crazy, you may want to be extra careful with removing and re-adding to the network.

Unfortunately our most unreliable devices are wifi homekit plugs from iHome. Several times per week several plugs will stop working and have to be un-plugged and plugged back in to start being responsive. We had about 12, we're down to 9. At some point I keep thinking we will find the sweet spot as far as how many play well on the same network. We have two parents homes with them, both with 3 and they have never stopped being responsive in those households. So I keep replacing them with different solutions and moving the extras to the parents. We'll either hit the sweet spot or find the one plug that keeps bringing the rest of them down.

 

[CarlJ]

Choosing Homekit-enabled devices is usually a good idea since Apple imposes some rather strict security requirements on them (although that's not bullet proof as the Hue Hub shows).

To be fair, HomeKit was a retrofit on the Hue system.
[automerge]1580930938[/automerge]

Unfortunately our most unreliable devices are wifi homekit plugs from iHome. Several times per week several plugs will stop working and have to be un-plugged and plugged back in to start being responsive. We had about 12, we're down to 9. At some point I keep thinking we will find the sweet spot as far as how many play well on the same network.

FWIW, I've had good luck (though with smaller numbers) using iDevices switches, and Hue's wall plug switch (also use their dimmer switches but those have an entirely different goal).

 

[jarman92]

It's not that you/they can't communicate across the barrier, but rather that you/they can only communicate in very specific well-defined ways: in this instance, the Hub only communicates with local-network devices via HTTP, and only when the local device initiates the conversation. The Hub can also communicate with a few IP addresses at Philips, if you allow it to "phone home"*. This can be written as a couple ACLs in the router that say "(Hub IP address) can only send HTTP traffic to local network, and only if the other end initiates the conversation", and "(Hub IP address) can send/receive to/from (IP addresses in Philip's domain)".

As far as your original mention of WiFi - it's useful in terms of understanding networking, but doesn't come into play here, because the Hue bulbs talk ZigBee (only) to the Hub, and the Hub (only) speaks ethernet to your home network.

As an aside, the Hub is controlled by the official Hue app - and all the unofficial Hue-related apps (there are many) as well as by HomeKit, and Alexa, and probably your SmartRefrigerator - via a fairly straightforward RESTful interface over HTTP, using JSON. It's quite simple to write scripts that interact with the Hub and turn lights on/off, collect status, and such. (I've got a bunch of python scripts I use for setting up specific scenes and such - and my own custom home weather station has a touchpanel with one column reserved for buttons to select various scenes.) Anyway, if you know how to program, and wish you could make your Hue lights do some particular thing - you probably can. Their developer program is free and provides complete documentation of the interface.

*: Having the Hub "phone home" to Philips is there to allow remote (away from home) control of your lights directly from the Hue app on your phone/tablet. This is from before HomeKit (and its own flavor of remote control) was a thing. You don't really need two such methods active, and HomeKit works with any other IoT devices you have (rather than only Hue devices). So I have the remote access in the Hue app turned off, and control them remotely solely with Apple's Home app (have an Apple TV at home, which handles HomeKit command traffic between Apple and my home). I trust Apple's security more than I do Hue's.
[automerge]1580925430[/automerge]
Nice to see someone who speaks network around these parts.

Awesome explanation, thanks!

 

[mw360]

So, every bulb they've manufactured from 2017 on has hardware that's been redesigned to remove this vulnerability, right? right? Or is that too much to ask?

The article Macrumors linked to, regarding the 2016 ‘unpatchable’ vulnerability, says it was patched in 2016. We’re not exactly working off solid information here.

 

[Xirian]

There are some things I absolutely do not want connected. One friend of mine has a deadbolt on their front door they can unlock with an app. No. Another friend has the Amazon service where the delivery person can open the garage door to deliver packages. Again no. But now that I'm used to smart lighting there is no going back for me.



Google WiFi would be a way around this. When you set up your guest network you can specify what devices on the primary network the guest network has access to.

I have a smart deadbolt and I have no worries. You would need to know I have a smart dead bolt, know what kind it is, know a vulnerability. Seems like a lot of work when you can just smash a window. Don't be so paranoid.

 

[Rigby]

I have a smart deadbolt and I have no worries. You would need to know I have a smart dead bolt, know what kind it is, know a vulnerability.

Finding out what kind of IoT devices you have is easier than you think. For example, you can easily find Bluetooth LE devices with scanner apps such as LightBlue. There are also tools to discover Zigbee and Wifi devices (although they don't run on iOS). If you could hear the emissions of IoT devices many neighborhoods in the US would sound like giant bee hives.

 

[Analog Kid]

Given the frequency of vulnerabilities being found in internet connected devices, is it reasonable to connect all such devices to your router’s ‘guest’ network, rather than your core Wi-Fi network, which holds your computer/PC/iPad/phone?

Would that restrict access to devices on the guest network only, if compromised and hacked? ie your core computers would be safe..

That’s what I’ve done. I also keep an iPod touch signed into a dedicated Apple ID as a remote for the various devices. For the most part it works well. The biggest problem I have, and I can’t figure out why, is that my Homepod stereo pair isn‘t available to devices with shared access to my Home but not on the guest network.
[automerge]1580949843[/automerge]

I keep seeing this suggestion but I can only picture how frustrating this would be in reality.

Lets put the Hue Hub on a secondary network.
Start with HomePod. Tell one of our HomePods to turn on or off a Hue device, but now it cant because the Hue Hub is on our secondary network. Hmm...
Ok so lets put the HomePods on that secondary network. But if the HomePods are on the secondary network I cant stream audio from my phone or ipad to the HomePod because those devices are on the primary network. I also cannot stream audio from apple TV to homepods.
Ok so lets put the apple TV's on that secondary network. But if apple TV's are on the secondary network then I cant stream movies and TV shows to the apple TV's from my mac Mini that acts like a pseudo-server.
Ok so lets put the mac mini to that secondary network. But now all we have left on the primary are phones, ipads and a rarely used macbook pro that is usually asleep. We still cannot stream anything from those devices to the HomePods or Apple TV's but hey, we're more secure, right? If we move phones and ipads to the secondary network all we have left on the primary is that rarely used 2010 MacBook Pro that is usually asleep; but again, more secure!
Or you have some crazy combo here and your constantly switching from primary network to secondary network wasting so much time to avoid a very small chance you'll ever be hacked.

If I share my Home with the Apple ID on my phone, I can control it while staying off the guest network. The one exception seems to be Homepods configured as stereo. If I break the stereo pair I can still stream to them individually.

 

[4jasontv]

Did any of you read the article?

What did I say that makes you think I didn't read it? You quoted me and then said exactly what I said.

To gain access to the ENTIRE network the device must first be compromised and unresponsive, then you must take action to remove that device and re-add it to your zigbee hub. Only at that point, as I understand it, your network becomes infected.

We have been trained that if a device is unresponsive to restart it. If that doesn't fix it we should remove and reconnect it. It's the perfect method of attack because the user action is standard troubleshooting steps. It's rather ingenious.

 

[Chiromac81]

If the software on the bridge is updated is it then safe to delete and re add unresponsive light then?
I have one that is unresponsive some of the time...