Hue! Let there be light!

As we already checked the IKEA TRÅDFRI Lighting system in one of our latest Quick-Checks, we now take a look at one of the main contenders in this sector – the Philips Hue Lighting system. Compared to the IKEA system, Hue packs a full-fletched remote access into the system and thereby provides a potentially larger attack surface. Whether or not this fact influences the overall security level is one of the questions we try to answer in this Quick-Check.

Application

The Android application (tested version: 2.11.0) left a really good impression on our testers: The app implements standard security mechanisms, like an adequate use of obfuscation, and shows no weaknesses in regards to secure local storage, any hard-coded secrets or overly open information exposition via Android logcat. In respect to these points the Hue application seems rather flawless.

Device pairing

There are two ways of pairing new devices. To pair the Hue App with the Bridge, you need to push the Link-button of the Bridge, which works like a WPS button and simply connects the devices after pressing. The pairing of new Hue accessories like bulbs, switches or motion sensors runs over the app itself.

What we missed was an overview of connected Apps and services. The Philips Hue system has a great API for several services and new Hue Apps are paired fast and simple – but once paired, the owner can’t know, who is able to control the lights or gain information from the sensors etc. (This affects other solutions, like IKEA TRÅDFRI, as well)

The list of paired Apps and services and their last access date is being transferred to Hue apps, but cannot be viewed (or deleted) from inside the app. Also, other information can be eavesdropped, which will be discussed at the part “Local communication.”

Online communication

Observing and analysing the communication between the Bridge and Philips servers, we were at first quite surprised – almost all communication is performed over HTTP. At second look, we realized it is nevertheless adequately secure: Philips decided to use an extra layer in their communication by encrypting the payload separately with AES but transferring it via HTTP. Regarding the reasons, we can only speculate, but we guess this might be to avoid the extra infrastructure and implementation effort for a secure SSL communication along with classic problems, a secure certification, key exchange, and authentication can inherit – No problem with that as long as the AES keys can be kept secret. Nevertheless, we suspect that there is no key exchange at all between Bridge and servers (otherwise there is no reason why Philips Lighting would not just use standard SSL) and that the keys consequently must be hard-coded into the firmware of the bridge. Of course we are just speculating here, as we did not check for the possibility of retrieving the firmware from the bridge nor we eavesdrop into encrypted communication in a Quick-Check.

The communication between Android application and server is secured very efficiently as well by integrating the use of the internal Android Internet browser into the app – the authentication for and the remote access itself is performed over the api.meethue.com website to which the application just redirects.  The advantage of this implementation is that certificate validation to prevent Man-in-the-Middle attacks is performed by the browser and the connection is adequately secure. This way an explicit Certificate-Pinning is obviously not possible but all standard checks for e.g. a trusted certificate authority (CA) or the common name (CN) are performed automatically without the app needing to validate these by itself. Man-in-the-Middle attacks on application connections are therefore quite unlikely and for most scenarios adequately prevented.

Local communication

Whereas the online communication is adequately (although unconventionally) secured, the local communication between Android application and Hue Bridge is not secured at all – There is no encryption and no real authentication to be found. In our tests, we checked for possible replay attacks of just resending command packages and these worked as expected.

As you have seen in the part “Device pairing” (Picture 1), the necessary data for accessing the Hue Bridge and other information like the state of the Link-button or the connection to MeetHue.com is also being transferred unencrypted, so we tried to switch the lights via the debug web interface (http://huebridge/debug/clip.html).

Direct API access is also possible using any registered user id. More details about the debug interface’s possibilities you can find here: https://github.com/tigoe/hue-control or here: https://www.princesspolymath.com/hacking-a-philips-hue-remote-api-in-node.html.

Many products we tested recently completely ignore security for the local communication presuming a completely secure local network their product is integrated in.  But even with this assumption in mind one cannot additionally assume that all clients in one network are allowed to have access to everything connected to it. So at least an adequately encrypted authentication is obligatory in our opinion.

Digital assistants

Third party services like IFTTT, and of course digital assistants like Siri or Alexa, can be connected to the Hue Bridge. In our tests, the connections between these services and the Hue Bridge were always TLS 1.2 encrypted.

Hacks in the past

Due to the popularity of the Hue brand, it was and is also a popular target for hackers. The Hue Bridge had some issues – but Philips Lighting did a good job in fixing the security flaws. In 2016, researchers hacked Hue lights via ZigBee over a distance of more than 200 meters. They mounted their ZigBee equipment on a drone and infected the bulbs in passing the building. (Details: http://iotworm.eyalro.net/iotworm.pdf) They found a flaw in the ZigBee Light Link protocol, which also allowed them to spread their malware among other lights, once one bulb got infected. All bulbs lighted up in SOS Morse code.

Other researchers, went a step further and built an Arduino-based receiver, which can receive information from infected bulbs, flickering in a frequency of 60Hz, so human eyes aren’t able to see the difference. This was more a prove of concept – they could send/receive only 10 Kilobytes a day. (Details: http://www.wisdom.weizmann.ac.il/~eyalro/EyalShamirLed.pdf)
Even if the effective use of such a hack is negligible, it shows that even inconspicuous IoT devices can be misused by others and security should be given a higher priority in product design.

Rooting the Hue Bridge

It’s possible to root the Hue Bridge, but access to its hardware is necessary. A serial cable can be connected to an internal testing point. After shortening two other testing points, the Bridge boots into debug mode and can be controlled via the serial interface. For more details, please visit http://colinoflynn.com/2016/07/getting-root-on-philips-hue-bridge-2-0/

Privacy

The privacy policy of MeetHue.com aka Philips Lighting explains in detail, which data is recorded from their App, Website and devices. It should be easily understood by 14 to 15 year olds (Flesch Kincaid Reading Ease).

Collected data differs in dependence of bought products and if the user is registered at MeetHue.com. E.g. if the HueSensor (motion sensor) is being used, light levels and motion information are being collected. Usage information are being collected for all devices. For details about which data is being collected, please visit http://www2.meethue.com/en-US/privacy-policy (too much to list here). For privacy concerns, only the default contact form can be used.

What we miss, is a listing of which data is being stored for which time and shared with which partner. The privacy policy doesn’t clarify both topics and names them only imprecisely.

The permissions of the Android App are limited to the necessary scope:

• Location (Geofencing / coming home feature)
• Storage (Saving or importing pictures and lighting scenes)
• Network access (Communication with the Bridge)

Conclusion

Philips Lighting provides a great lighting system with their Hue brand, with lots of features like motion sensors that change the brightness in the room depending on the time, connection to other services like Amazon Alexa, Apple HomeKit and Siri or IFTTT. Their Bridge and App had some security flaws in the past, but Philips fixed them, mostly within short time. Local communication is completely unencrypted, which should be a No-go in this price range. Here, Philips Lighgting has to improve the existing solution by putting effort into an encrypted communication channel. Once this has been fixed, the rating will improve to three stars.