IoT gehackt? Als cyberbeveiligingsbedrijf organiseren we regelmatig interne wedstrijden voor de lol en voor educatieve doeleinden. De laatste was gericht op het hacken van een IoT-toepassing. Dit artikel – bewerkt door een van onze cybersecurity consultants – kan interessant voor je zijn, vooral als je nieuwsgierig bent naar cybersecurity of bezig bent met het ontwikkelen van een veilige applicatie.
Inleiding
Hier in Approach hebben we het geluk om bekwame mensen te hebben die graag hun kennis delen, met name tijdens wat we onze “Kennislunch” noemen. De onderwerpen kunnen variëren van cyberbeveiliging, veilig coderen tot webpenetratietesten.
Het laatste onderwerp werd gepresenteerd door onze Senior Cyber Security Consultant, David Bloom. David presenteerde ons een aantal webhackingtechnieken die eenvoudig uit te voeren zijn, maar een verwoestende impact hebben als eindresultaat.
Het doel van deze sessie was om aan te tonen hoe eenvoudig het is om een server te compromitteren of een browser van een client te infecteren als de webapplicatie geen goede invoervalidatie toepast of als de webserver niet goed is beveiligd.
De uitdaging: “Hack een goedkope, oude, merkloze muziekstreamingbox” – context en regels
Na de informatieve presentatie had David nog een cadeau voor ons: een uitdaging. David bracht een goedkope, oude, merkloze muziek streaming box mee die hij van zijn broer had geleend om ons een missie te presenteren: krijg beheerderstoegang en vind de vlag die hij erop heeft geplant ergens verborgen in de bestanden van de streaming box.
Er waren maar 2 regels voor de uitdaging:
REGEL 1 – Geen beschadigingen/vernielingen/veranderingen die anderen kunnen verhinderen om deel te nemen (en mogelijk zijn broer boos maken).
REGEL 2 – Geen verbinding van de box op ons eigen netwerk of op het internet om te voorkomen dat er een kwetsbaar object in onze kantooromgeving wordt geplaatst.
De functionaliteit van de box is vrij eenvoudig. Het creëert een Wi-Fi-netwerk waarmee je verbinding kunt maken om muziek te streamen en bestanden te delen. Het presenteert een beperkt webportaal met de volgende functionaliteiten:
– Een bestandsbeheerder om bestanden op een USB-stick of een USB-harde schijf te beheren.
De Wi-Fi-hotspot instellen.
Een manier om verbinding te maken met het internet en je netwerk via een andere Wi-Fi-antenne.
-De audiodienst instellen.
-Instellen van een gedeelde map.
– De firmware upgraden.
De penetratietest
Als cybersecurityconsultant was ik benieuwd hoe veilig de applicatie was en of er een uitdaging lag in het black-box testen ervan. Op het eerste gezicht was de beveiliging niet de belangrijkste focus van dit product. Onversleutelde services (HTTP, telnet…), zeer permissieve cookies en, nog belangrijker, een zwakke veldvalidatie waren de zwakke punten die snel opvielen. Bovendien verwijderden sommige velden de haakjes “<>” alleen client-side via JavaScript (zwakke beveiliging die kan worden omzeild met een eenvoudige proxy), sommige velden valideerden niets en sommige velden deden alleen aan tekencodering.
Deze hoeveelheid potentieel uit te buiten kwetsbaarheden in zo’n kleine applicatie maakte het moeilijk voor me om te raden welke kwetsbaarheden het beste uitgebuit konden worden. Ik werd al snel moe van het uitproberen van elk veld en URL parameter. Belangrijker nog, ik wilde eerst de vlag vinden.
Sleutel voor hacken
De sleutel tot het hacken van dit apparaat lag echter in de extensie van de pagina’s: shtml. SHTML is een speciale extensie waarmee de webserver, als dat is toegestaan, Server Side Includes (SSI) instructies kan uitvoeren als ze worden gepresenteerd in een statische pagina. SSI is een eenvoudige geïnterpreteerde taal waarmee bepaalde opdrachten aan de serverzijde kunnen worden uitgevoerd.
SSI was dus duidelijk de exploit-taal waarnaar we moesten zoeken. Maar hoe injecteer je het in de doos?
Ik had SSI-injectie kunnen proberen, of een shtml-bestand op de server kunnen maken door commando-injectie, of zelfs code-injectie. Maar het zou lang kunnen duren om uit te vinden hoe je de stukjes code die injectie mogelijk maken kunt gebruiken, dus nam ik een kortere weg.
Ik heb mijn eigen shtml-pagina gemaakt met wat eenvoudige SSI-code: 
Ik kopieerde het bestand op een USB-stick, reikte discreet naar de doos om het in de USB-poort van de doos te steken, kwam toen terug naar mijn bureau en deed alsof ik koffie ging halen.
Daarna ging ik naar de pagina Bestandsbeheer en opende daar het shtml-document:
Tot niemands verrassing werd de shtml-pagina server-side uitgevoerd. De reden is eenvoudig: om de inhoud van de USB-sleutel te kunnen weergeven, werd het apparaat gemount in de werkmap van de webapplicatie.
Resultaat
De resulterende pagina gaf:
Het eerste deel van de uitdaging was gewonnen. Ik werd root! Remote File Inclusion door gewoon een USB-sleutel in te pluggen. Leuk!
Dus nu kon ik eigenlijk alles doen wat ik wilde op de doos. Het enige wat ik hoefde te doen is andere bestanden maken om te bladeren en het vlagbestand te openen.
Nadat ik mijn bevindingen had gerapporteerd, kreeg ik te horen dat dit slechts één van de kwetsbaarheden was en dat er nog andere waren, waarbij het inderdaad ging om injectie van commando’s/codes/bestanden.
Tot slot, hoe veilig was het?
Deze doos was een geweldig voorbeeld van een onveilig systeem, omdat het verschillende soorten fouten illustreerde:
– Softwarefout: veld(en) die injectie mogelijk maakten.
– Configuratiefout: de webserver draait als root.
– Fout in fysieke beveiliging: de doos was fysiek toegankelijk.
– Ontwerpfout: het zal elk bestand van een USB verwisselbaar medium uitvoeren, terwijl het alleen bekende bestanden zou moeten toestaan.
Deze doos is een extreem geval van een IoT-apparaat dat niet is ontworpen met beveiliging in gedachten. Maar wat hadden ze kunnen doen om de toepassing te beveiligen?
Enkele adviezen voor vergelijkbare ontwikkelaars van IoT-toepassingen
Afgezien van de fysieke beveiliging van het apparaat, die het voor mij alleen maar gemakkelijker maakte en waar verkopers geen invloed op hebben, zouden ontwikkelaars deze doos kunnen hebben:
– Draai de webserver niet als root.
– Beperk de werkdirectory van de webserver.
– Beperk de uitvoering van shtml-bestanden tot één bekende map via de configuratie van de webserver of .htaccess-bestanden.
– Geen schrijfrechten geven in de werkdirectory en subdirectories (om het genereren van nieuwe shtml pagina’s door een aanvaller te voorkomen).
– Configureer de webserver om het SSI-commando “exec” niet toe te staan. Bijvoorbeeld, op Apache, de optie IncludesNOEXEC.
– Betere veldvalidatie.
Wil je penetratietests uitvoeren voor je IoT-toepassingen? Neem een kijkje op onze pentest-pagina
Wilt u beveiligde toepassingen ontwikkelen? Bekijk onze pagina over veilige ontwikkeling
Advies voor de eindkopers van IoT-apparaten
Als je van plan bent om een nieuw apparaat te kopen dat op je netwerk en/of op het internet kan worden aangesloten, moet je er rekening mee houden dat het minder krachtig en slim is dan een computer, en dus kwetsbaarder. Als het gaat om je veiligheid en privacy, moet je rekening houden met het risico dat zo’n apparaat slechts een paar stappen verwijderd is van je computer en/of smartphone,
Om de risico’s te beperken, moet je je richten op bekende merken met een goede reputatie op het gebied van veiligheid en minder bekende of onbekende merken vermijden. Deze laatste, die geen reputatie te verliezen hebben, kunnen geneigd zijn de kantjes eraf te lopen om de ontwikkelingskosten te drukken.
Eenmaal gekocht is het eerste wat je moet doen met een nieuwe IoT: vervang het standaard beheerderswachtwoord door een sterk wachtwoord!
Ook:
– Zorg ervoor dat het niet fysiek toegankelijk is voor een aanvaller. Laat het bijvoorbeeld niet onbeheerd achter in de gang van je flatgebouw.
– Zet hem uit als je hem niet gebruikt.
– Gebruik een wachtwoord voor de Wi-Fi als deze als router fungeert.
– Houd het apparaat up-to-date.
Wil je op de hoogte blijven van de nieuwste bedreigingen? Schrijf je dan in voor onze SOC-nieuwsbrief.
