Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MacRumors

macrumors bot
Original poster
Apr 12, 2001
67,515
37,817



A new vulnerability has been discovered in the Philips Hue smart lighting system that could let hackers gain access to the local host network and other devices connected to it.


Discovered by Check Point Research and demonstrated in a video, the flaw relates to the Zigbee communication protocol used by Philips Hue bulbs and a number of other smart home devices, including Amazon's Ring, Samsung SmartThings, Ikea Tradfri, and Belkin's WeMo.

According to the security researchers, the vulnerability could allow a local attacker to take control of Hue light bulbs using a malicious over-the-air update and cause the bulbs to exhibit random behavior and become uncontrollable. If the user then deletes the bulb and re-adds it in the Hue app, the attacker is able to gain access to the Hue bridge.
The hacker-controlled bulb with updated firmware then uses the ZigBee protocol vulnerabilities to trigger a heap-based buffer overflow on the control bridge, by sending a large amount of data to it. This data also enables the hacker to install malware on the bridge - which is in turn connected to the target business or home network.
Every Philips Hue Hub connected to the internet should have automatically updated itself to version 1935144040, which patches this specific vulnerability. Users can check themselves by looking to see if any updates are available for the Hue app.

The flaw actually relies on a vulnerability that was originally discovered in 2016 and which can't be patched, as it would require a hardware update to the smart bulbs.

"Many of us are aware that IoT devices can pose a security risk," said Yaniv Balmas, Head of Cyber Research at Check Point Research. "But this research shows how even the most mundane, seemingly 'dumb' devices such as lightbulbs can be exploited by hackers and used to take over networks, or plant malware."

Article Link: Security Researchers Expose Vulnerability in Philips Hue Smart Bulbs
 
So what a hacker is going to change the color of my lights :oops:

How far is too far with connected devices, lightbulbs, door locks, doorbells, refrigerators, toasters. Do we really need all that much connectivity?
 
Given this is down to a Zigbee vulnerability there are non IoT ramifications. Many alarm systems use Zigbee for their sensors to talk to the control unit. Using the same underlying vulnerability could you trick a sensor into saying everything is fine when it isn’t?
 
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..
 
So my Bridge says that it's got the software version referenced in the OP, however that number does not reflect what my bulbs, light strips, or switches have.
[automerge]1580909802[/automerge]
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 a thought.

At the same time... Bring on those HomeKit Secure routers.
 
So what a hacker is going to change the color of my lights :oops:

How far is too far with connected devices, lightbulbs, door locks, doorbells, refrigerators, toasters. Do we really need all that much connectivity?
I like the idea of these IOT devices, but have no appetite for this type of thing, where vulnerabilities exist in an IOT that could possibly cause harm on your network. (Of course there is an idea of network segregation, but too much for most home users)

I would rather just flip a light switch.
 
From the checkpoint article it seems a hue bridge firmware update is available:
The research was disclosed to Philips and Signify (owner of the Philips Hue brand) in November 2019. Signify confirmed the existence of the vulnerability in their product, and issued a patched firmware version (Firmware 1935144040) which is now available on their site. We recommend users to make sure that their product received the automatic update of this firmware version.
 
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..
It is generally a good idea to connect IoT devices to an isolated network from a security perspective. However, in many cases this means you'll no longer be able to control the devices from a phone unless it is also connected to the isolated network. The latter, in turn, makes it difficult to use some of Apple's integration features such as Continuity, since they generally require that the phone and other Apple computers/devices are on the same network.
 
VLANs people. IoT devices should never touch the same network as your normal devices.
I’d like to learn more about these. Would it allow me to keep my iPhone and Apple Watch on my main network with my computers, but still ask Siri to run scenes on my HomeKit devices?
 
So what a hacker is going to change the color of my lights :oops:

How far is too far with connected devices, lightbulbs, door locks, doorbells, refrigerators, toasters. Do we really need all that much connectivity?

They get access to the machines on the same network.

Even more reason not to have such a ludicrously high level of connected devices. ;)

Given this is down to a Zigbee vulnerability there are non IoT ramifications. Many alarm systems use Zigbee for their sensors to talk to the control unit. Using the same underlying vulnerability could you trick a sensor into saying everything is fine when it isn’t?

Did any of you read the article? 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.

So if you have a zigbee device that goes unresponsive, be very weary of it. We've been running zigbee devices for too many years to count and I haven't had one go unresponsive yet (knocks on wood). So thank you MR for this tip that if one ever does go unresponsive it needs to be dealt with accordingly.

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..

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.
 
Yeah instead of fixing the issues and continuing to enjoy smart devices, let's go back to the stone age, I agree. Hang on, I'll get the candles lit and then we'll go out hunting

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 is generally a good idea to connect IoT devices to an isolated network from a security perspective. However, in many cases this means you'll no longer be able to control the devices from a phone unless it is also connected to the isolated network. The latter, in turn, makes it difficult to use some of Apple's integration features such as Continuity, since they generally require that the phone and other Apple computers/devices are on the same network.

Are you sure about that? I have separate 2.4 and 5 GHz networks, and some of my devices are on the 2.4 and some on the 5, but they all still communicate with each other. Would it be the same with a VLAN? Or is the entire idea that you can’t communicate across that barrier?
 
Are you sure about that? I have separate 2.4 and 5 GHz networks, and some of my devices are on the 2.4 and some on the 5, but they all still communicate with each other. Would it be the same with a VLAN?
No. In your case both Wifi bands are connected to the same IP subnet, so they are not isolated at all. When using VLANs with Wifi, you'd typically use multiple Wifi SSIDs and connect them to different VLANs.
Or is the entire idea that you can’t communicate across that barrier?
Yes, that's the point. Once you have set up separate VLANs (which are used to create separate IP subnets), you can control the traffic flow between them by setting up routing and firewall rules between them with an appropriate router. It does require some networking knowledge.
 
According to the security researchers, the vulnerability could allow a local attacker to take control of Hue light bulbs using a malicious over-the-air update and cause the bulbs to exhibit random behavior and become uncontrollable. If the user then deletes the bulb and re-adds it in the Hue app, the attacker is able to gain access to the Hue bridge.
So, for now, if your bulbs suddenly go wacky, don't just delete and re-add them. (I'm not sure I've ever had to do that anyway, in the past 4 years.)

Every Philips Hue Hub connected to the internet should have automatically updated itself to version 1935144040, which patches this specific vulnerability.
If you have automatic updates turned on in the Hue app. Some of us like to read the release notes first.

The flaw actually relies on a vulnerability that was originally discovered in 2016 and which can't be patched, as it would require a hardware update to the smart bulbs.
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?

Some of the discussion here describes the upstreaming problem as the re-added bulbs causing a buffer overflow on the hub by sending too much data - that certainly seems like something that can be thorougly patched in the Hub (if you get more than X amount of data from a bulb in Y transaction, dump the remaining incoming data rather than adding it to the buffer). And, better, also flag the transmitting bulb as rogue and requiring a reset/reload. At that point, the vulnerability is reduced to "bad guys can DoS your lightbulbs" (the old ones, because surely Philips removed that vulnerability for newly manufactured bulbs back in 2017, right? right?).
 
  • Like
Reactions: imola.zhp
I keep seeing this suggestion but I can only picture how frustrating this would be in reality.
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.
 
  • Love
  • Like
Reactions: Val-kyrie and CarlJ
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.

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.

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.
 
  • Disagree
Reactions: Xirian
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.