Kijken naar internetverkeer met behulp van SPIN: een Philips Hue casestudie

Aan de hand van een casestudie laten we zien hoe je het gedrag van IoT-apparaten in de gaten kunt houden met behulp van SPIN.

We zijn nu 3 jaar bezig met de ontwikkeling van 'SPIN', ons IoT-meetplatform voor thuisnetwerken. In deze blogpost laten we zien hoe eindgebruikers die hun veiligheid en privacy willen beschermen, met behulp van SPIN het gedrag van hun IoT-apparaten in de gaten kunnen houden. Dit doen we aan de hand van een casestudie van de slimme lamp Philips Hue, waarin we onze analyse beschrijven.

SPIN klaar voor integratie door marktpartijen Jaar 2 van SPIN

Het SPIN-project

SPIN (Security and Privacy for In-home Networks) is een doorlopend onderzoeksproject bij SIDN Labs dat zich bezighoudt met de security en privacy van IoT-apparaten. In het SPIN-project ontwikkelen we software die draait op een homegateway (of ander geschikt thuisnetwerkapparaat) waarmee gebruikers het netwerkgedrag van hun IoT-apparaten in de gaten kunnen houden en deze apparaten kunnen blokkeren, bijvoorbeeld als ze betrokken zijn bij een DDoS-aanval. SPIN geeft gebruikers een webinterface waarmee ze een grafische weergave van het netwerkverkeer kunnen bekijken en biedt hun de mogelijkheid om bepaalde bestemmingen of apparaten te blokkeren. We gebruiken SPIN regelmatig als meetinstrument (bijvoorbeeld tijdens workshops om te laten zien hoe SPIN werkt en in het kader van de universitaire module Security Services for the IoT, die door ons wordt gegeven). Een van de dingen die we soms waarnemen als we SPIN op die manier gebruiken, is dat Philips Hue-lampen proberen om verbinding te maken met domeinen die niet bij de fabrikant horen, zoals facebook.com, google.com, baidu.com en qq.com. Dat zou kunnen resulteren in gebruikersprofilering door derde partijen die die domeinen beheren. Verder hebben onderzoekers recent aangetoond dat het heel gebruikelijk is dat IoT-apparaten zich zo gedragen. Verschillende bezorgde gebruikers merkten dat de Hue bridge iets soortgelijks deed, wat leidde tot berichten op diverse fora.

Verbindingen visualiseren

Hoewel de verbindingen die de Hue met derde partijen maakte, bedoeld bleken te zijn om de connectiviteit te checken, leek de Hue ons een interessant apparaat om te laten zien hoe SPIN je kan helpen ontdekken wat je IoT-apparaten op het internet uitspoken, vooral als je een gebruiker met bescheiden technische kennis bent die zijn veiligheid en privacy wil beschermen. We installeerden SPIN op een GL-Inet AR150 mini-router (niet moeilijk, klik hier voor instructies). Daarna sloten we de mini-router aan op het internet en verbonden we een Philips Hue bridge. De bridge wordt door Hue-lampen gebruikt om te communiceren met internetdiensten op afstand (zie Figuur 1).

Philips Hue bridge

Figuur 1. Een Hue-bridge die Hue-lampen verbindt met het thuisnetwerk. We keken naar 3 scenario's waarvan de kans groot is dat je ze op je thuisnetwerk tegenkomt: (i) Hue opstarten gevolgd door normaal gebruik, (ii) een online Hue waarvan de internetverbinding ineens wegvalt, en (iii) een niet-werkende internetverbinding bij het opstarten.

Hue opstarten en normaal gebruik

We onderzochten het eerste scenario door te observeren hoe de Hue zich gedraagt tijdens een normale opstartprocedure. Figuur 2 geeft onze waarnemingen weer. Zodra de Hue-bridge klaar is met opstarten, begint de SPIN-interface weer te geven welk verkeer er plaatsvindt (zie Figuur 2). Bij normaal gebruik zagen we dat er veelvuldig verbinding werd gemaakt met subdomeinen van google.com (voor tijdsynchronisatie via NTP), meethue.com en philips.com. Dat zijn domeinen waarvan je zou verwachten dat een Philips Hue-product er verbinding mee maakt. Om alle verbindingen op te sporen, activeerden we verschillende functies van de bridge, zoals de lampen aan- en uitdoen.

Figuur 2. SPIN visualiseert de Philips Hue bij normaal gebruik .

Wegvallen van internettoegang

Om een plotseling optredend probleem met de clouddiensten van de Hue te simuleren (het tweede scenario), stonden we al het verkeer toe van en naar de SPIN-router, die ook de DNS-resolver van het netwerk runt. Vervolgens blokkeerden we de internettoegang naar de bridge (zie Figuur 1) om een situatie na te bootsen waarin de DNS-resolver wel functioneert, maar de clouddiensten niet. Aan de hand van de SPIN-webinterface konden we het volgende vaststellen:

  • Na het blokkeren van de internettoegang was de websocket-verbinding met ws.meethue.com de eerste verbindingspoging die mislukte.

  • Daarna mislukten de verbindingen met de timeservers van Google.

  • Vervolgens mislukte de verbinding met de diagnostische server van de Hue.

  • De Hue bleef een paar minuten proberen om verbinding te maken en ging het toen proberen bij andere servers: www2.meethue.com, philips.com, google.com en ten slotte baidu.com.

Opstarten zonder connectiviteit

Voor het derde scenario, waarin er geen internet is bij het opstarten, keken we wat er gebeurde als we de Hue blokkeerden en daarna uit- en weer inschakelden. Ook hier zagen we eerst uitsluitend mislukte verbindingen met de servers van meethue.com, Philips en de timeservers van Google. En ook hier werd daarna geprobeerd verbinding te maken met Google en Baidu. Het lijkt erop dat de Hue is geprogrammeerd om een voorgeschreven reeks stappen te volgen nadat het niet is gelukt om verbinding te maken met de Hue servers. Als onderdeel van die stappen wordt geprobeerd om verbinding te maken met 2 van de 5 grootste websites qua bezoekersaantallen: een in de VS en een in China. Door de verkeersfilters die door sommige landen worden toegepast, kan gesteld worden dat verbinding zoeken met websites in andere rechtsgebieden waarschijnlijk een goede manier is om de connectiviteit te meten. Wanneer het lukt om verbinding te maken (bijvoorbeeld met Google), gaat de Hue niet verder met het controleren van de connectiviteit (door bijvoorbeeld verbinding te maken met Baidu). SPIN liet zien dat er bij de connectiviteitscontroles van de Hue geen transmissie van HTTP-gegevens plaatsvindt, waardoor de hoeveelheid informatie die het apparaat over zichzelf of zijn gebruikers prijsgeeft, beperkt blijft. In plaats daarvan brengt de Hue-lamp alleen een TCP-verbinding tot stand door eerst een three-way handshake uit te voeren en meteen daarna een four-way handshake om de verbinding te beëindigen. Onze waarnemingen laten zien dat het bij het analyseren van het gedrag van IoT-apparaten belangrijk is om verder te kijken dan de standaard apparaatinteracties. Het netwerkgedrag van een apparaat kan variëren al naar gelang het apparaat volledig, beperkt of helemaal geen toegang heeft tot het internet.

Firmware wijzigt gedrag

We gebruikten SPIN ook om de verschillen te onderzoeken tussen de huidige firmware (december 2019) en de firmware die we eerder testten (maart 2019). Bij de nieuwere firmware waren er minder derde partijen betrokken bij de connectiviteitscontrole; er werden geen verbindingen meer gemaakt met Facebook of qq.com. Firmware die afwijkend netwerkgedrag introduceert, kan problemen opleveren bij het modelleren van IoT-apparaten. Dat is van belang voor eindgebruikers, omdat firmware-updates ertoe kunnen leiden dat beveiligingsprogramma's alarm slaan. Het modelleren van een IoT-apparaat bestaat vaak uit een trainingsfase, waarin een model wordt getraind op basis van een bepaald netwerkverkeer. Als het verkeer verandert, kan het model afwijkingen detecteren. Die afwijkingen kunnen legitiem zijn, zoals nieuw gedrag na een firmware-update of gedrag dat nog niet eerder is geactiveerd, maar ook schadelijk, zoals een malware-infectie. Schadelijke afwijkingen, bijvoorbeeld een DDoS-aanval, zouden idealiter automatisch moeten worden geblokkeerd om de veiligheid van het netwerk te beschermen. Als een legitieme firmware-update echter automatisch zou worden geblokkeerd, zou dat de veiligheid van een thuisnetwerk juist in gevaar brengen. Welke acties worden ondernomen, zou ook moeten afhangen van de voorkeuren van de gebruiker. Zo wil de ene gebruiker misschien dat de internettoegang van een apparaat met afwijkend gedrag automatisch wordt geblokkeerd, terwijl een andere gebruiker geen automatische ingreep wil, maar een e-mail met alle beschikbare informatie.

Tijdsynchronisatie

Tijdens onze observatie van het netwerkverkeer van de Hue merkten we dat er regelmatig synchronisatie plaatsvond tussen de Hue en de timeservers van Google via het Network Time Protocol (NTP). Gebruikers die zich zorgen maken over hun veiligheid en privacy, vragen zich misschien af met welke NTP-servers hun IoT-apparaten verbinding maken en hoe vaak ze ermee synchroniseren. Met behulp van SPIN registreerden we 3,5 uur lang het netwerkverkeer van een Hue (in pcap-formaat). Als we kijken naar de NTP-verzoeken, blijkt de Hue met grote regelmaat NTP-synchronisatieverzoeken te versturen. Tijdens de meetperiode werden er naar elk van de 4 NTP-servers van Google tussen de 89 en 92 verzoeken verstuurd, met gemiddeld 133 seconden tussen elk verzoek. Hoewel het gemiddelde boven het aanbevolen minimale peilingsinterval van 64 seconden ligt, werd 28% van de NTP-verzoeken minder dan de aanbevolen 64 seconden na het vorige verzoek naar dezelfde NTP-server verstuurd. Met een te kort minimaal peilingsinterval is er een risico dat de NTP-servers nodeloos worden overladen met verzoeken. De vraag is hier waarom de Hue-bridge zijn interne klok zo vaak moet synchroniseren.

Ruimte voor diepgaand deskundig onderzoek

SPIN wil toegankelijk zijn voor doorsnee eindgebruikers en tegelijkertijd vakspecialisten de beschikking geven over geavanceerde functionaliteit. Gebruik van de SPIN-interface geeft eindgebruikers inzicht in het netwerkverkeer dat een apparaat genereert. Je hoeft geen expert te zijn op het gebied van netwerken, omdat we ervoor hebben gezorgd dat SPIN de informatie helder verbeeldt. Daarnaast kunnen vakspecialisten aanvullende informatie verkrijgen, ruwe netwerkverkeersgegevens met betrekking tot bepaalde apparaten downloaden (in pcap-formaat) of verbinding maken met de message broker van SPIN als ze analyses willen uitvoeren met behulp van hun eigen tools.

Probeer het zelf

Als je de opensourcesoftware van SPIN graag zelf wilt uitproberen, ga dan naar spin.sidnlabs.nl. Daar vind je meer informatie. Op dit moment bieden we kant-en-klare images voor verschillende GL Inet-apparaten, een Raspberry Pi en een virtuele machine voor het testen van SPIN. We staan open voor feedback en zijn geïnteresseerd in jouw ideeën over de toekomst van IoT-security. Hoewel onze website vooral gericht is op de onderzoekscommunity, is daar ook informatie te vinden die IoT-spelers zoals firmware engineers, ISP's en routerfabrikanten kan helpen bij het gebruiken en toepassen van SPIN.