Would you buy light globes from the Apple Store?
Would you spend a cool $60 each, or $200 for a pack of three?
That’s the price that enthusiastic early adopters are paying for the Philips Hue Connected Bulb.
The Hue is a light globe that’s different in more than just its price.
It can controlled wirelessly, and contains three LEDs that can be individually tweaked (and even animated) to produce a wide range of different colours, although it doesn’t seem to be terribly good at blue and green.
The wireless part uses a lightweight protocol called ZigBee Light Link, which means that a full-on internet software stack and Wi-Fi adpapter isn’t needed in every lamp.
Instead, there’s a single network-facing device, about the size of a toffee tin, that talks to the ZigBee-enabled globes, known as the Hue Bridge.
(The curious pricing above, where three $60 globes cost $200, reflects the fact that you get a Bridge in every three-pack. One Bridge can control up to 50 lamps. Assuming you have $3000 to splash on light globes, that is.)
You connect the Bridge to your network – and, despite the prestigious pricing, you have to plug it in with a network cable, because it doesn’t have a Wi-Fi adapter either – and then you control the Bridge from a computer.
Groovily, Philips has published a programming interface so you can roll your own Hue control software for any sort of device.
Nevertheless, as you can imagine for a third-party product that can only be purchased from an Apple store, the control platform of choice is an iPhone or iPad.
There’s an Android app in the Play Store, too, but some of the reviews suggest it’s a rather poor cousin of the iDevice version.
I’m sure you’ve guessed what’s coming next.
That’s right: the Hue Bridge isn’t terribly secure, as the technology press has been pointing out for the past few days, thanks to a report by a security researcher called Nitesh Dhanjani.
Indeed, judging from headlines like El Reg’s pejorative “Philips’ smart lights left in the dark by dumb security” to Gizmodo’s ultra-capitalised “Philips Hue Light Bulbs Are Highly Hackable,” things don’t sound too good for the Eindhoven Engineers.
Here’s why.
The application programming interface (API) uses HTTP, so you make web requests to the Bridge, and it converts these into the appropriate Zigbee commands to pass on to the lights.
The URLs you use to issue commands have to include a username that is pre-authorised by the Bridge.
Here’s an HTTP request to turn off Light One:
PUT /api/username/lights/1/state { "on": false }
Er, that’s it.
There’s no HTTPS, and not even any HTTP digest authentication, to protect the commands from eavesdropping or replay.
Once you know any of the usernames that the Bridge will accept, you can use it to create URIs and issue any supported command, such as turning lights on and off, or flashing out the message URPWN3D in Morse code.
Actually instructing the Bridge to start trusting a new user in the first place is a little less free-for-all.
You have to press the button on the Bridge less than 30 seconds before issuing an add user command, a step the Philips documentation says “prove[s] that the user has physical access to the Bridge.”
But it doesn’t really “prove” anything, of course – it just means someone pressed the button in the last 30 seconds.
A miscreant on your network – a shameless visitor, for example – could run a script to create a new user every 29 seconds, and if anyone were to press the Bridge button at any time during their visit, they’d have a username they could use indefinitely.
According to Dhanjani, however, even that sort of effort is over the top if you use Hue’s official app.
That’s because the official app generates its username by taking the MD5 hash of your iDevice’s network MAC address.
As you probably know, MAC addresses are pretty much a matter of public record, at least if you have ever tried to associate to a Wi-Fi access point (encrypted or not), because the MAC address is broadcast as a unique device identifier when you try to connect.
Ironically, this means that if you use Wi-Fi at home, and rely on shortcuts like MAC address filtering so you don’t need to bother with encryption, anyone who connects unlawfully to your network by “borrowing” your MAC address will also get implicit authorisation to do wild things to your Hue lighting.
That’s probably not what you want.
Richard Chirgwin of The Register dubbed this “dumb-as-a-sack-of-hammers security,” and Dhanjani himself fitted out his paper with the attention-grabbing section header “Malware Can Cause Perpetual Blackout.”
I’ll be a little more conciliatory, and say merely that this is “underwhelming,” not least because randomly-generated usernames by the Hue app and HTTPS for the API would have been easy enough to build into the system from the start.
→ The argument that the memory and processor demands of HTTPS are a bit of a budget-stretcher for tiny embedded devices with low-powered CPUs, such as the Hue Bridge, holds no water. Lightweight, BSD-licensed TLS implementations such as axTLS compile down to a few tens of kilobytes, and were designed for precisely this sort of application.
By the way, to learn why MAC addresses are a poor basis for access control, you might like to take a look at this video we made earlier this year, Three Wireless Security Myths – Busted!.
I’ll leave you with a pertinent comment from Dhanjani’s paper on Hue security, pointing out how important it is that:
...consumer IoT organizations take issues like these seriously. In the age of malware and powerful botnets, it is vital that people's homes be secure from vulnerabilities like these that can cause physical consequences.
In case you’re wondering, IoT is short for Internet of Things, a networking vision in which the internet is populated by fridges, TVs and, indeed, each light in your home.
The light globes in your Hue Starter Pack might not yet have their own IP numbers (the Bridge is their internet proxy), but by golly, they’re close.
Goes on to show that people do things because they can. I find no practical use for this apart from someone wanting to show off a bulb. Also if you have to plug in a LAN cable, I wonder how much wireless it really is. It makes me laugh when people talk about security and encryption, for heavens sake, its just a bulb, just turn it off.
I have not done any research into this, and to be quite honest this is the first time I have heard of this product.
My question would be, does this product have the capability of a strobe effect? Based on the color output, and if it is possible to have a strobe effect, in theory this could be used to induce seizures, remotely.
Another possible use for a hack like this would be a house raid at night. Having control of a lighting system as you're breaking into a home could prove to be invaluable.
I'm sure at some point someone will use this same insecure technology on their motion detector lights. My assumption would be they would use it to send a text or an e-mail notification when the light turns on. But I could also see someone disable all functionality of the motion detecting light as well.
Paul Duckling is quite wrong about WiFi ACLs. For domestic users of WiFi systems setting up an Access Control List means that the casual piggy-back usage of a WiFi system is prevented and protected against all but the determined hacker. Anyone trying to connect to the home WiFi is prevented from doing so unless the MAC of the device being used is listed in the Allowed list. If it isn’t, then access is prevented.
[comment edited for length]
In a domestic situation, it is ESSENTIAL that some security measure be taken to prevent the casual misuse of the home owner’s bandwidth and an ACL is one such measure that should be encouraged and not discouraged.
I fear you have missed the point of the video.
MAC address filtering provides safety against accidental connections from unexpected devices.
It does effectively nothing to prevent *misuse* of your network, whether casual or otherwise, by anyone who cares to connect unlawfully.
You do *not* need to be a "determined hacker" to bypass MAC address filtering. You need to be able to use a search engine, to download some MAC spoofing software, and to read some brief instructions on how to use it.
To prevent misuse, casual or otherwise, WPA or WPA2 plus a decent password is what you want, as it provides both access control *and* confidentiality.
MAC addresses are *not* secret, nor are they meant to be. Therefore using them as if they were secret passwords only gives a false sense of security, and recommending them as if they were secure is a measure that should be discouraged.
Once you have your WPA password sorted, *then* feel free to use MAC filtering. Or not.
[comment edited for length]
That MACs are not secret is true but you have the know the make and serial number of the equipment that is allowed to connect to even start making any educated guess at a MAC that might be listed in the ACL as allowed.
That's not correct. If you watch the video you will see me using a sniffer to collect the MAC addresses of the devices on a Wi-Fi network. So acquiring a list of MACs that are in someone's ACL requires no hacking, skill or even guesswork.
Just run the sniffer, wait a while, and the results are collected for you.
Easy-to-use, free Wi-fi sniffers are widely available online.
[This thread is now closed.]
The admins have ruined my submission and cut it by over 80% – so it now doesn't say what I wrote.
MAC Access Control can prevent WiFi access by unlisted devices. WPA2 can prevent access even by listed devices if the passkey is wrong. Both together can control access.
A sniffer can only 'see' active devices and traffic. It cannot 'see' inactive devices. The OFF switch is great security at the expense of doing anything.