Afstudeeronderzoek: automatische detectie van aanvallen op IoT-apparaten met IoT-honeypots

IoT-honeypots in een notendop

Traditionele IoT-honeypots zoals IoTPot zijn machines met speciale software die doet voorkomen alsof de honeypot een fysiek IoT-apparaat met securitykwetsbaarheden is. Bijvoorbeeld een slimme lamp met een standaardwachtwoord. De honeypot wacht tot aanvallers misbruik van de kwetsbaarheden maken en verzamelt dan informatie over hun gedrag en de geïnstalleerde malware. Securityonderzoekers kunnen zo het gedrag van aanvallers in kaart brengen, zoals het gedrag van botnets als Mirai en Hajime.

Het probleem van deze IoT-honeypots is echter dat ze zich nooit helemaal hetzelfde gedragen als het echte fysieke IoT-apparaat. Hierdoor kunnen aanvallers erachter komen dat ze een honeypot proberen te compromitteren in plaats van een echt apparaat. Dit omdat de huidige honeypots alleen het externe gedrag van het IoT-apparaat nabootsen en niet de daadwerkelijke firmware van het apparaat gebruiken. Nieuwere IoT-honeypots zoals Honware hebben deze mogelijkheid wel en emuleren de firmware van een IoT-apparaat, vergelijkbaar met een virtuele machine (VM). Hierdoor lijkt het gedrag van deze virtuele IoT-apparaten veel meer op dat van het echte apparaat. Aanvallers doen dan meer moeite om het ‘apparaat’ proberen te compromitteren, wat securityonderzoekers meer inzicht geeft in hun gedrag en waarmee ze nieuwe en voorheen onbekende kwetsbaarheden beter kunnen vinden.

Mijn onderzoek: EPA-IoT-honeypots

Het doel van mijn werk was te onderzoeken wat er nodig is om deze nieuwe generatie IoT-honeypots uit te breiden zodat ze (1) automatische kwetsbare paden in IoT-firmware ontdekken die leiden naar kwetsbare delen in de code en (2) die paden monitoren om te checken of aanvallers ze actief misbruiken. Ik noem dit ‘execution path-aware’ IoT-honeypots, of kortweg EPA-IoT-honeypots. De toegevoegde waarde van EPA-IoT-honeypots is dat ze nog onbekende aanvallen op kwetsbaarheden geautomatiseerd kunnen vinden en zo securityonderzoekers helpen kwetsbaarheden en het misbruik daarvan beter in kaart te brengen. Mijn aanpak bestond uit een literatuuronderzoek en een eerste implementatie om te testen of het principe zou kunnen werken. Voor mijn onderzoek heb ik 2 methodes gebruikt: statische analysetools en firmware emulators. De statische analysetools heb ik gebruikt om mogelijke kwetsbaarheden en kwetsbare executiepaden in IoT-software te vinden. De firmware-emulators heb ik gebruikt om de software die op apparaten draait te virtualiseren. De combinatie maakt het mogelijk om kwetsbaarheden in firmware geautomatiseerd te vinden (analysetools), om daarna te monitoren of aanvallers ze daadwerkelijk misbruiken met behulp van een firmware emulator. In de rest van de blog bespreek ik de belangrijkste componenten van een EPA-IoT-honeypot, mijn implementatie en mijn evaluatie.

Architectuur van een EPA-IoT-honeypot

Figuur 1 toont de architectuur van een EPA-IoT-honeypot, die bestaat uit 3 componenten:

• Firmware Analyzer: detecteert kwetsbaarheden in IoT-firmware. Voor elke kwetsbaarheid slaat de Firmware Analyzer alle relevante informatie op over executiepaden in de firmware die naar de kwetsbaarheid leiden (kwetsbare paden), waaronder de locatie waar de kwetsbaarheid zich voordeed.

• Honeypot: emuleert de firmware van een IoT-device. Met de GNU debugger (GDB) en de informatie van de Firmware Analyzer weet de EPA-IoT-honeypot nu welke commando’s (inputs) aanvallers naar de honeypot moeten sturen om executiepaden bij de kwetsbaarheid uit te laten komen en kan hiermee de echte aanvallen detecteren.

• Input Analyzer: reconstrueert de symbolische formule van de kwetsbaarheid op basis van de kwetsbare paden die de Firmware Analyzer heeft gevonden en analyseert de commando’s die aanvallers op het internet daadwerkelijk naar de honeypot sturen. Aan de hand hiervan kunnen we dan detecteren of de verzamelde inputs van de aanvaller een kwetsbare functie weet te bereiken en te misbruiken.

Figuur 1. Architectuur van een EAP-IoT-honeypot.

Voor onze implementatie maken we gebruik van 2 tools. Voor de Firmware Analyzer gebruiken we Karonte, waarbij we Karonte flink hebben aangepast om het bruikbaar te maken voor ons scenario. Karonte gebruikt statische analyse en symbolische executie om kwetsbare paden in de firmware te vinden die afhankelijk zijn van de inputs (commando’s) van aanvallers. Voor de honeypot gebruiken we FirmAE. Dit is een recente opensource emulator voor IoT-firmware en het kan veel meer firmware-images emuleren vergeleken met de voorganger FirmaDyne. We gaan nu in op de 3 componenten van de EAP-IoT-honeypot in meer detail.

Firmware Analyzer

De kwetsbaarheden waar we ons op richten zijn zogenaamde ‘taint-style vulnerabilities’. Dit zijn kwetsbaarheden die afhangen van de data die een aanvaller propageert naar een kwetsbare functie in de honeypot-firmware. Een voorbeeld is een programma dat de gebruiker vraagt een wachtwoord in te voeren. De variabele waar het programma dit wachtwoord in opslaat, is vanaf dat moment ‘tainted’. Dit betekent dat alle interacties met deze variabele daarna verdacht zijn en moeten bekeken worden. Als het programma op een later moment de invoer niet goed controleert, kan een kwetsbaarheid ontstaan. Een analogie hiervoor is een persoon met modder aan haar hand. Alles dat vervolgens aangeraakt wordt, zoals deurklinken of een afstandsbediening, is daarna vies. Dat hoeft niet erg te zijn, totdat de persoon etenswaren (de kwetsbaarheid) aanraakt zonder zijn handen te hebben gewassen.

Figuur 2 toont de belangrijkste Karonte-modules die we hebben gebruikt voor de Firmware Analyzer: Border Binaries Finder, Binary Dependency Graph, Bug Finder en Sources Parser.

Figuur 2. Karonte-modules die we hebben gebruikt voor de Firmware Analyzer. Een binary van een firmware image kent veel mogelijke executiepaden. Omdat we alleen geïnteresseerd zijn in ‘taint-style vulnerabilities’, gebruikt de Firmware Analyzer als eerste stap de Border Binaries Finder, een module die alle binaries in een firmware-image probeert te vinden. Hiermee kunnen we een graaf maken van alle dataflows door de IoT-firmware. De Border Binaries Finder geeft elke binary een score op basis van de aanwezigheid van zogenaamde ‘data keys’. Dit zijn strings die refereren naar netwerkinteracties, zoals ‘http_referer’ of ‘content_type’ waarmee mogelijk input van een aanvaller de firmware binnenkomt. Het cluster aan binaries met de hoogste score zijn de zogenaamde Border Binaries. De Border Binaries zijn de input voor de Binary Dependency Graph, een Karonte-component die communicatiepatronen tussen binaries detecteert en daar een graaf van maakt. De analyse begint met de data keys in elke border binary en draait een symbolische executie over de functies waarin data keys voorkomen. Deze symbolische executie maakt formules om te bepalen onder welke condities een executiepad delen van een bepaalde functie kan bereiken, bijvoorbeeld met de invoer van specifieke karakters of lengtes. De Firmware Analyzer gebruikt hiervoor de Communication Paradigm Finder (CPF), die detecteert of de binaries onderling netwerkdata uitwisselen. Op dit moment kunnen we met Karonte 5 soorten invoer van gebruikers detecteren, waaronder inkomend netwerkverkeer. Als de CPF communicatie tussen binaries ontdekt, dan maakt het een Role voor een binary aan die informatie over het communicatiepunt in de firmware opslaat, of de functie een setter of getter is (of er informatie ontvangen of verstuurd wordt) en de gebruikte data key. De CPF zoekt hierna naar andere binaries die dezelfde data key gebruiken en voegt deze toe aan de lijst met nog te analyseren binaries. Uiteindelijk stelt dit de Firmware Analyzer in staat om op basis van de gedetecteerde roles een binary dependency graph op te stellen. De Bug Finder is de component die uiteindelijk de kwetsbaarheden vindt. De module gebruikt symbolische executie op elke van de Roles in de Binary Dependency Graph. De Bug Finder detecteert kwetsbaarheden bijvoorbeeld aan de hand van een buffer size detection analysis module die de gealloceerde ruimte voor buffers op de stack en de heap in kaart brengt. Verder gebruikt de module taint-analyse. Als de Firmware Analyzer kwetsbaarheden detecteert, dan slaat het alle informatie over de mogelijke executiepaden op. Zo kan de honeypot later detecteren of een input van een aanvaller de kwetsbaarheid kan bereiken en triggeren. De Sources Parser zet uiteindelijk deze inputs om naar een formaat wat leesbaar is voor de honeypot en maakt een mapping van alle symbolic links in een firmware image. Voor mijn onderzoek heb ik een groot aantal wijzigingen doorgevoerd aan Karonte, bijvoorbeeld een volledige rewrite van de Bug Finder om accurater taint te propageren, een herschreven buffer size detection analysis module en een upgrade naar Python3. Deze wijzigingen hebben we gemerged in Karonte, zodat anderen ook van deze wijzigingen gebruik kunnen maken.

Honeypot

Met de gevonden kwetsbaarheden kunnen we aanvallen op deze kwetsbaarheden automatisch detecteren met de honeypot. Via de opensource emulator FirmAE (zie Figuur 3) hebben we volledige toegang tot de geëmuleerde firmware. Via de Custom FirmAE Communicator verzamelt de honeypot inputcommando’s van aanvallers die via het internetverbinding maken met de honeypot.

Figuur 3. Honeypot-componenten van een EPA-IoT-honeypot. De honeypot verzamelt inputcommando’s via Custom Debugging Scripts die we automatisch genereren op basis van de resultaten (de input sources) van de Firmware Analyzer. Als laatste heeft de honeypot-operator ook de mogelijkheid om handmatige detectieregels toe te voegen. Een voorbeeld hiervan is ‘op plaats x in dit programma zit een kwetsbaarheid’. Dit kan handig zijn voor kwetsbaarheden waarvoor geen bestaande Intrusion Detection System-signature bestaat. Dit hebben we bijvoorbeeld gedaan voor CVE-2021-29302 (een CVE is verwijzing naar een databank met informatie over kwetsbaarheden).

Input Analyzer

De Input Analyzer bekijkt de inputcommando’s die aanvallers via het internet naar de honeypot sturen, of deze inputs een kwetsbaarheid kunnen bereiken en of ze deze kwetsbaarheid ook kunnen activeren. Dit doet de Input Analyzer in 4 stappen: (1) het reconstrueert de symbolische formule, (2) het markeert de gebruikersinvoer, (3) berekent of het pad naar de kwetsbaarheid bereikbaar is met de input en (4) het controleert dat de invoer daadwerkelijk de kwetsbaarheid gebruikt. Om te kijken of de input de kwetsbare functie kan bereiken moeten we als eerste de symbolische formule reconstrueren. Dit doen we door de verzamelde ‘constraints’ in het pad naar de kwetsbare functie aan elkaar te koppelen. Een voorbeeld van een constraint is een if-statement in een executiepad zit, waarbij de input aan de condities van het if-statement moet voldoen om de bijbehorende code uit te voeren. In de Firmware Analyzer was de locatie waar de input verzameld was een symbolische variabele. Om te kunnen verifiëren of het pad bereikbaar is voegen we een extra regel toe om deze variabele gelijk te stellen aan de verzamelde input van de honeypot (constrainen). Als de symbolische formule opgesteld is en geconstrained is, dan kunnen we verifiëren of het pad bereikbaar is door deze formule op te laten lossen door een constraint solver. Hiervoor gebruiken we Z3. Als deze solver zegt dat er een oplossing mogelijk is, dan is het pad bereikbaar en hoeven we alleen nog te verifiëren dat de input de kwetsbaarheid kan triggeren. Dit laatste doen we aan de hand van een sink rule. Voor elk soort kwetsbare functie stellen we een regel op waarmee we kunnen verifiëren of een codepad een kwetsbaarheid kan triggeren. Bij memcpy-functies hebben we bijvoorbeeld de volgende sink rule:

taint & src > dst

In dit voorbeeld triggert de aanvaller de kwetsbaarheid als de inputs in de kwetsbare functie terecht zijn gekomen en de verzamelde input voor de src groter is dan de gealloceerde ruimte in de dst.

Evaluatie

De EAP-IoT-honeypot van Figuur 1 hebben we ter evaluatie als honeypot op het internet aangesloten. Bij het uitkiezen van de firmware image kwamen we er wel achter dat de emulatie-ratio van FirmAE minder goed is dan de auteurs opgeven. Veel van de images kunnen bijvoorbeeld de setup-fase niet voltooien vanwege missende afhankelijkheden en bij andere images lukte het niet om alle services te emuleren. Het meeste succes hadden we met firmware images van TP-Link en D-Link-apparaten, die FirmAE zonder al te veel problemen bleek te kunnen emuleren. We besloten uiteindelijk een firmware image van de TP-Link Archer C3200 V1 te gebruiken, omdat deze ook een kwetsbaarheid had die we met de Firmware Analyzer hadden gevonden was en een kwetsbaarheid bevat die we konden gebruiken als Custom Debugging Rule. We vonden dat onze EPA-IoT-honeypot aanvallen goed kan detecteren. Dit hebben we vastgesteld via proof-of-concept-aanvallen voor de gedetecteerde kwetsbaarheden. Hierbij hebben we wel zelf geprobeerd om de kwetsbaarheid te triggeren. Een voorbeeld van zo’n proof-of-concept die we gebruikt hebben is hier te vinden. Zo’n proof-of-concept bestaat uit code om aan te tonen hoe een bepaalde kwetsbaarheid misbruikt kan worden. Verder hebben we varianten van proof-of-concept-aanvallen gebruikt om te kijken of we false-positives konden genereren. De sink rules werken zeer accuraat om te detecteren of een kwetsbaarheid die kwetsbare functie kan triggeren. Er is nog wel de mogelijkheid dat Karonte een functie in een executiepad nog niet ondersteund, waardoor er een kans is op false positives. Wel is het bijna onmogelijk om de door ons gevonden kwetsbaarheid in de praktijk te misbruiken, omdat de kwetsbare module niet bereikbaar is via de webinterface. Echter, met de Custom Debugging Rules konden we succesvolle aanvallen gericht op een andere kwetsbaarheid in de TP-Link Archer C3200 V1, namelijk CVE-2021-29302, goed herkennen.

Conclusies

In mijn onderzoek heb ik met mijn prototype van een EPA-IoT-Honeypot laten zien dat deze honeypots potentie hebben om aanvallen op nieuwe kwetsbaarheden te detecteren, onder andere op kwetsbaarheid CVE-2021-29302. Ook hebben we laten zien dat het in de praktijk mogelijk is om een EPA-IoT-honeypot te implementeren, iets wat op het moment van schrijven naar mijn weten nog niet eerder gedaan is. Tegelijk voorzie ik dat er nog wel veel werk te verzetten is op het gebied van EPA-IoT-honeypots. Zo is het aantal firmware images met een kwetsbaarheid die we succesvol kunnen emuleren laag, waardoor het systeem helaas nog niet bruikbaar is in de praktijk. De custom detectieregels zijn daarentegen onafhankelijk van de kwetsbaarheden die de Firmware Analyzer vindt en daardoor makkelijker te schalen naar meerdere soorten IoT-devices. Dit is iets wat in toekomstig onderzoek verder onderzocht kan worden.

Geïnteresseerd? Het is opensource!

Mijn onderzoek is te vinden op de SIDN Labs website. Verder is alle code opensource beschikbaar (FirmAE, Static analysis, Honeypot).