Looking at internet traffic using SPIN: a Philips Hue case study

The SPIN project

SPIN (Security and Privacy for In-home Networks) is an ongoing research project at SIDN Labs concerned with the security and privacy of IoT devices. In the SPIN project, we are developing software that runs on a home gateway (or other capable homenet device) and enables users to inspect the network behaviour of their IoT devices and potentially block them, for instance if they’re participating in a DDoS attack. SPIN offers a web interface that allows users to see a graphical representation of the network traffic and offers the option of blocking certain destinations or devices. We regularly use SPIN as a measurement tool (e.g. to demonstrate SPIN at workshops and for a university module that we teach, called Security Services for the IoT). One of the things we sometimes observe when using SPIN that way is Philips Hue lightbulbs trying to connect to domains not associated with the manufacturer, such as facebook.com, google.com, baidu.com and qq.com. That could result in user profiling by the third-party operators of those domains. Furthermore, researchers recently showed that such behaviour is common in IoT devices. Several concerned users spotted the Hue bridge behaving in a similar way, leading to forum posts.

Visualising connections

Although it turned out that the Hue's third-party connections were for connectivity checking, we figured the Hue would be an interesting device for illustrating how SPIN helps you learn what your IoT devices are doing on the Internet, in particular if you’re a security and privacy-conscious user with modest technical knowledge. We installed SPIN on a GL-Inet AR150 mini router (easy as pie, go here for instructions). We then hooked up the mini router to the internet and connected a Philips Hue bridge. Hue light bulbs communicate with remote services on the internet via the bridge (see Figure 1).

Fig 1. A Hue bridge that connects Hue lights to the home network. We looked at three scenarios that you’ll likely run into on your home network: (i) Hue start-up followed by normal operation, (ii) an online Hue that suddenly loses its internet connection, and (iii) no internet at start up.

Hue start-up and normal operation

We examined the first scenario by observing the Hue's behaviour during normal start-up. Our observations are illustrated in Figure 2. Once the Hue bridge has finished starting up, traffic starts to appear at the SPIN interface (see Figure 2). During normal operation, we observed frequent connections to subdomains of google.com (for synchronising time using NTP), meethue.com and philips.com. One would expect a Philips Hue product to connect to those domains. In order to find all connections, we triggered various bridge functionalities, such as turning light bulbs on and off.

Fig 2. SPIN visualising the Philips Hue during normal operation

Losing internet access

To simulate a sudden problem with the Hue’s cloud services (the second scenario), we allowed all traffic from and to the SPIN router, which also runs the network’s DNS resolver. We then blocked internet access to the Philips Hue bridge (see Figure 1) to simulate a situation where the DNS resolver works, but the cloud services do not. Using the SPIN web interface, we made the following observations:

• After blocking, the websocket connection to ws.meethue.com was the first attempted connection to fail.

• Connections to the Google time servers were next to fail.

• That was followed by failure of the connection to the Hue diagnostic server.

• After a couple of minutes of attempting to connect, the Hue started trying to connect to other servers: www2.meethue.com, philips.com, google.com and finally baidu.com.

Start-up without connectivity

For scenario 3, where there is no internet at start-up, we blocked and then power-cycled the Hue and observed what happened. Again, we initially saw only failed connections to the meethue.com servers, Philips and Google’s time servers. And, again, that was followed by connection attempts to Google and Baidu. It appears that the Hue is programmed to follow a prescribed series of steps after failing to connect to the Hue servers. Those steps include trying to connect to two of the five largest websites in terms of visitors: one US-based and one China-based website. Due to the traffic filtering that some countries apply, connecting to websites from different jurisdictions is arguably a good method of measuring connectivity. When a connection (to Google, for example) succeeds, the Hue does not continue its connectivity checks (by connecting to Baidu, for example). SPIN revealed that the Hue's connectivity checks do not involve transmission of any HTTP data, limiting the amount of information that the device reveals about itself or its users. Instead, the Hue lightbulb only sets up a TCP connection by completing a three-way handshake and immediately proceeds to the four-way connection termination. Our observations show that it is important to look beyond the standard device interactions when analysing IoT device behaviour. The network behaviour of a device may differ, depending on whether the device has full internet access, limited internet access or no internet access at all.

Firmware changes behaviour

We also used SPIN to investigate the differences between the current firmware (December 2019) and the previously tested firmware (March 2019). The newer firmware reduced the number of third parties in the connectivity check; there were no longer connections to Facebook or qq.com. Firmware that introduces different network behaviour can lead to difficulties when modelling IoT devices. For end users, that is important because firmware updates may trigger alerts from security solutions. Modelling an IoT device often consists of a training phase, in which a model gets trained based on certain network traffic. When the traffic changes, the model might detect abnormalities. Those may either be legitimate, such as new behaviour after a firmware update or previously untriggered behaviour, or harmful, such as a malware infection. Harmful abnormalities, such as a Denial-of-Service attack, should ideally be blocked automatically to protect the security of the network. However, automatically blocking a legitimate firmware update is harmful to the security of a home network. The actions should also depend on the user's preferences. For example, one user may want an offending device’s internet access to be blocked automatically, while another user may want to receive an e-mail with all available information instead of enabling automated intervention.

Synchronising time

While looking at the Hue network traffic, we observed regular synchronisation between the Hue and Google’s time servers using the Network Time Protocol (NTP). Security and privacy-conscious users may be curious which NTP servers their IoT devices connect to, and how often they synchronise. We used SPIN to record the network traffic of a Hue (in pcap format) for 3.5 hours. Looking into the NTP requests, it turns out that the Hue sends very regular NTP synchronisation requests. During the measurement period, between 89 and 92 requests were sent to each of the four Google NTP servers, with an average interval of 133 seconds between each request. Although the average is above the suggested minimum polling interval of 64 seconds, 28% of the NTP requests were sent less than the recommended 64 seconds after the previous request to the same NTP server. With an unduly short minimum polling interval, there is a risk of unnecessarily overloading the NTP servers with requests. The question to ask here is why the Hue bridge needs to synchronise its internal clock so often.

Scope for in-depth expert analysis

SPIN aims to be understandable for non-expert end users, while at the same time offering advanced features for expert users. Using the SPIN interface gives end users insight into the network traffic that a device generates. No networking expertise is needed, because we've designed SPIN to present information in clear visual form. However, experts are able to obtain additional information, download raw network traffic data (pcap format) regarding particular devices, or connect to the SPIN message broker with a view to performing analyses using their own tools.

Try it out

If you are interested in trying out the open-source SPIN software yourself, you can find more information on spin.sidnlabs.nl. We currently offer pre-built images for several GL Inet devices, a Raspberry Pi and a virtual machine for testing SPIN. We are open to feedback and your ideas on the future of IoT security. While our website is intended mainly for the research community, we also provide some support to help IoT players such as firmware engineers, ISPs and router manufacturers to use and deploy SPIN.