In the Philips Hue system, the authentication between the CP and the HS relies on the user to press the button on the hub. However, after the pressing, this protocol does not guarantee that the HS only responds to the benign CP. Consequently, a malicious CP which knows the HubIP of the HS can send a valid authentication request (e.g., an HTTP/POST request with a nonce as the request parameter and HubIP as the destination) to obtain a token (e.g., hash(nonce)) from the HS. In this way, the malicious CP gets authenticated by the benign HS. To conduct this attack in reality, the malicious CP can continuously send authentication requests until the user presses the button on the hub. After being authenticated, the malicious CP becomes capable of sending control commands, such as turning on/off and changing color, to the HS to control the SD.

Sending LinkButtonTrue command.

– Uncontrolled CP Authentication. Due to the lack of restriction on administrative commands, an authenticated malicious CP can force a benign HS to remain “linkbutton”in the true state by sending the LinkButtonTrue command.This causes the victim HS to authenticate any other malicious CPs in the LAN upon authentication requests, without the button clicking on the hub.

The Philips Hue system does not enforce any restriction on invoking the administrative commands. Hence, any CP authenticated by the HS can re-configure the system by sending administration commands including adding/removing SDs (SearchLight/DeleteLightRequest) and deleting whitelisted CPs (DeleteUserIDRequest). This security issue may result in the following consequences.

– Denial-of-Service against the HS. The malicious CP can delete all other authentication tokens stored in the whitelist at the benign HS by continuously sending DeleteUserIDRequest. Hence, the benign CP is unable to be authenticated by the benign HS.

– Denial-of-Service against the SD. The malicious CP can delete SDs which have been connected to the hub by sending DeleteLightRequest. If this command is sent continuously, the SD will not be able to have a stable connection with ZFE. Consequently, these attacks show that a common assumption of smart home systems, i.e., trust on home Wi-Fi can result in serious consequences if it is invalidated. Nevertheless, attackers can deceive the benign users into installing malicious applications on the CP to exploit the vulnerabilities behind the home Wi-Fi and launch these attacks.

We have found that the SD of the Philips Hue system responds to beaconrequests from ZigBee enabled devices, even after it has joined a ZigBee network. This reveals its identity (DeviceID). In addition, the touchlink commissioning of ZigBee Light Link Protocol (ZLL) used by Philips Hue can reset the existing configuration on a benign SD and establish a new connection with the initiator. As a consequence, the malicious ZFE with the similar configuration as the benign ZFE (e.g., another Philips Hue hub) can first discover the benign SDs in the neighborhood, and then trigger the touchlink commissioning to reset and connect to the discovered benign SDs. In this way, the benign SDs are hijacked by the malicious hub.