Onveilige Internet of Things apparaten (IoT-apparaten) worden gebruikt om Distributed Denial of Service (DDoS) aanvallen uit te voeren. Een bekend voorbeeld hiervan is de Mirai-botnet aanval op DNS-operator Dyn, die leidde tot grootschalige uitval van DNS-diensten. Om het schaderisico van onveilige IoT-apparaten te beperken, lanceerde SIDN Labs het SPIN-project. Hierbij evalueerden we de bruikbaarheid van de Manufacturer Usage Description (MUD) specificatie, die momenteel wordt ontwikkeld door de Operations and Management Area Working Group (OPSAWG) binnen de Internet Engineering Task Force (IETF).
De achterliggende gedachte hierbij is dat wanneer een IoT-apparaat verbinding zoekt met een netwerk, het apparaat doorgeeft welke resources het nodig heeft om goed te kunnen functioneren. Deze informatie wordt vastgelegd in een MUD-profiel, dat het beoogde netwerkgedrag van het apparaat beschrijft op basis van een ‘whitelist’. Deze whitelist zou compleet moeten zijn en dus kan de toegang tot andere netwerkresources worden geweigerd zonder dat dit de goede werking van het apparaat belemmert.
In dit onderzoek bestudeerden we de toepasbaarheid van MUD voor het beveiligen van IoT-apparaten tegen hackpogingen. Ook onderzochten we of de bruikbaarheid van IoT-apparaten voor DDoS-aanvallen afneemt door een profiel te handhaven. De MUD-specificatie is echter nog niet klaar voor gebruik en dus nog nergens geïmplementeerd. Om MUD-profielen te kunnen meten creëerden we daarom een tool die het netwerkgedrag van een IoT-apparaat observeert en een bijpassend MUD-profiel genereert. Deze tool voert 3 taken uit:
het verzamelen van informatie;
het genereren van een bijpassend profiel;
het handhaven van dat profiel.
Aanpak
De eerste stap is het verzamelen van de benodigde informatie. Het MUD-profiel bevat een whitelist die het gewenste netwerkgedrag van het apparaat specificeert. Simpel gezegd is dit een lijst met domeinnamen of IP-adressen waarmee het apparaat mag communiceren. Voor elke domeinnaam of IP-adres op de lijst kan aanvullende informatie worden gegeven, zoals de transport layer protocol (bijvoorbeeld TCP of UDP) en andere karakteristieke gegevens, zoals poortnummers. De informatie wordt verzameld op de thuisrouter, die hiervoor bij uitstek geschikt is omdat hij al het verkeer tussen de hosts in het lokale netwerk en het internet kan observeren.
Het doel van het verzamelen en analyseren van informatie over het internetverkeer is drievoudig:
om eventuele thuisnetwerkapparaten in het verkeer te identificeren (door naar ARP en NDP te kijken);
om vast te stellen welk apparaat de verbinding initieerde (d.m.v. de SYN-vlag in de TCP header);
om IP-adressen in de flow records te koppelen aan de corresponderende DNS-bevragingen die voorafgaand aan het verkeer werden verstuurd.
Vaak wordt een verbinding tot stand gebracht door middel van een hostnaam (zoals example.nl) en vervolgens vertaalt naar een IP-adres, met behulp van het DNS. Om de domeinnamen aan IP-adressen in de flow records te kunnen koppelen moeten de DNS-pakketten met de relevante bevragingen en antwoorden worden geanalyseerd.
Om een nauwkeurig profiel te kunnen genereren moeten voldoende gegevens over het netwerkverkeer worden verzameld, zodat alle mogelijke verbindingen in kaart worden gebracht. Dat houdt in dat over een lange periode moet worden gemeten. Veel apparaten voeren periodieke taken uit, bijvoorbeeld elke 24 uur checken voor software updates. Het is echter belangrijk dat alle functionaliteiten van een IoT-apparaat tijdens de meetperiode worden gebruikt, omdat elke functionaliteit specifiek netwerkgedrag kan vertonen.
Wanneer er genoeg meetgegevens zijn verzameld, kan de tool een MUD-profiel van het netwerkgedrag van een apparaat genereren. Dat gebeurt door eerst alle verzamelde flow records te filteren, zodat alleen het verkeer overblijft waarbij het te profileren apparaat betrokken is. Al het verkeer van en naar het MAC-adres van het apparaat wordt geselecteerd. Wij werken bij voorkeur met MAC-adressen, omdat IP-adressen vaak dynamisch worden toegekend en een apparaat aan meer dan één IP-adres gekoppeld kan zijn.
Nadat er een profiel voor het IoT-apparaat is gegenereerd, moet het profiel vervolgens worden gehandhaafd. Dat betekent dat de netwerktoegang van het apparaat moet worden beperkt tot het gedrag dat in het profiel wordt gespecificeerd. In ons prototype doen we dat door het profiel te converteren naar een reeks iptables-regels.
Evaluatie
We hebben het hierboven beschreven systeem als prototype geïmplementeerd en daarna geëvalueerd of het prototype aan onze eisen voldeed. Bij deze evaluatie stelden we onszelf drie vragen:
Kan het IoT-apparaat zijn werkzaamheden nog steeds correct uitvoeren als het profiel wordt gehandhaafd?
Kan het handhaven van een profiel voorkomen dat een apparaat wordt gehackt?
Als een apparaat toch wordt gehackt, maakt het handhaven van een profiel het apparaat dan minder bruikbaar voor een DDoS-aanval?
Om de eerste vraag te beantwoorden genereerden en handhaafden we profielen voor een aantal IoT-apparaten. We gingen vervolgens na of de apparaten nog goed werkten. Bij een op het internet aangesloten lamp controleerden we bijvoorbeeld of we de lamp nog steeds aan en uit konden zetten met een mobiele telefoon. Voor het beantwoorden van vraag 2 en vraag 3 moesten we meer weten over hoe IoT-apparaten precies voor aanvallen worden misbruikt. Literatuuronderzoek naar DDoS-aanvallen via het IoT leverde interessante informatiebronnen op, zoals diverse wetenschappelijke rapporten over de Mirai-aanval, waarin de eigenschappen van dit botnet in detail worden toegelicht. Vervolgens vergeleken we de relevante eigenschappen met de gegenereerde profielen.
Resultaten
De beschreven benadering bleek goed te werken voor de apparaten voor specifieke doeleinden die we tijdens ons onderzoek evalueerden. De aanpak is echter minder geschikt voor apparaten voor algemeen gebruik, zoals mobiele telefoons en laptops. Met dergelijke apparaten kunnen gebruikers verbinding maken met een willekeurige host, waardoor profilering van apparaten op basis van whitelists onuitvoerbaar wordt. Het netwerkgedrag van apparaten voor specifieke doeleinden is daarentegen doorgaans vrij beperkt, waardoor we de netwerktoegang kunnen whitelisten.
Bovendien constateerden we dat het aanvalsoppervlak van een apparaat bij het handhaven van een profiel afneemt. Apparaten kunnen alleen worden benaderd via specifiek in het profiel vastgelegde routes. Dit betekent in veel gevallen dat het apparaat niet vanaf het internet bereikbaar is. Vanzelfsprekend bieden MUD-profielen geen bescherming tegen aanvallen via kanalen op de whitelist. Desondanks maakt profilering het een stuk moeilijker om een apparaat te compromitteren.
Figuur 1: Apparaat A en Apparaat B lanceren een denial-of-service aanval op respectievelijk example.net en example.org. Beide domeinen draaien op hetzelfde cloudplatform.
Daarnaast bleek de bruikbaarheid van apparaten als DDoS-aanvalsmedium enigszins te zijn afgenomen. Het aantal diensten dat doelwit kan worden is namelijk beperkt tot de diensten die in het profiel op de whitelist staan. Er wordt echter steeds meer gebruik gemaakt van cloudplatforms als Amazon Web Services (AWS) en Google Cloud Platform (GCP). Een aantal IoT-apparaten bleken bijvoorbeeld verbinding te maken met diensten die op AWS draaien. Hierbij is het volgende scenario denkbaar. Stel dat we onderlinge verschillende profielen hebben gegenereerd voor apparaat A en apparaat B en dat apparaat A toegang heeft tot example.net en apparaat B tot example.org. Als example.net en example.org beiden op hetzelfde cloudplatform worden gehost, kunnen apparaat A en apparaat B nog steeds een DDoS-aanval op dat platform uitvoeren (zie Figuur 1), ondanks dat zij verschillende profielen hebben.
Toekomstig werk
De slagkracht van IoT-apparaten in DDoS-aanvallen kan nog verder worden gereduceerd. Zo kan gedacht worden aan rate-limiting wanneer IoT-apparaten niet de hele beschikbare bandbreedte nodig hebben. Ook zou het nuttig zijn om te onderzoeken of door de fabrikant meegeleverde MUD-profielen kunnen worden gevalideerd. Wanneer apparaten die MUD ondersteunen op de markt komen, dan kan het door de fabrikant opgegeven profiel bijvoorbeeld worden vergeleken met het door het prototype gegenereerde profiel.
Deze scriptie kan worden gedownload van de website van de Universiteit Twente.
