OWASP IoT Top 10
Het Open Web Application Security Project (OWASP) is een open-source-project rond computerbeveiliging. Individuen, scholen en bedrijven delen via dit platform informatie en technieken. Ook de Belgische tak van OWASP is erg actief en een interessante organisatie indien je van plan bent om een carrière binnen de cybersecurity wereld op te bouwen. Ze organiseren geregeld (meestal gratis) workshops en evenementen.
Het OWASP heeft tal van erg interessante “Top 10” overzichten zoals de meest voorkomende webapp zwakheden, etc. Deze projecten bestaan meestal uit een reeks tools, best practices en gidsen en zijn dus de ideale manier om je te verdiepen binnen een specifiek cybersecurity domein. Eén van de actieve projecten is het “OWASP Internet of Things” project (beschikbaar via owasp.org/www-project-Internet-of-Things/) waarvan we de Top 10 hier zullen bespreken, gerangschikt van meest voorkomend (en dus belangrijkste om aan te pakken) naar minder.
Bekijk zeker ook eens het IoT Goat project via github.com/OWASP/IoTGoat/ dat is een “insecure firmware based on OpenWrt and maintained by OWASP as a platform to educate software developers and security professionals with testing commonly found vulnerabilities in IoT devices. The vulnerability challenges are based on the OWASP IoT Top 10, as well as ‘easter eggs’ from project contributors.”
Om de wel erg algemene term “IoT” wat duidelijker te maken, zullen er hier en daar merknamen en producten worden vermeld. Dit is hoegenaamd geen verdoken reclame (of kritiek) voor deze producten, maar gewoon een poging om de lezer een duidelijkere context te geven.
Paswoorden
Ook bij IoT begint veiligheid bij het hebben van goede, complexe, moeilijk te raden wachtwoorden. Bij IoT-apparaten is er echter een stevige drempel, zeker voor huis-tuin-en-keuken gebruikers: het aanpassen van sommige IoT-apparaten is soms erg omslachtig. Niet alle apparaten hebben een webpagina langs waar de gebruiker wachtwoorden kan aanpassen en dus moet dit ofwel via omslachtige, vreemde tools, ofwel (gruwel) door fysiek het apparaat te bedienen. Deze apparaten zijn natuurlijk niet gemaakt om complexe wachtwoorden eenvoudig in te voeren. Denk maar aan een digitale weegschaal: die heeft vaak een eenvoudig LED-scherm waarop je gewicht wordt getoond. Sommige weegschalen kan je vervolgens “bedienen” door links of rechts op de schaal te klikken, afhankelijk van wat je wilt doen. De auteur kan je garanderen: je wachtwoord zal niet lang zijn, als je een goed wachtwoord wilt invoeren zal je na enkele minuten in het zweet staan van de tapdans die je moet uitvoeren op je weegschaal.
Omdat het aanpassen van die wachtwoorden vaak omslachtig is, zullen gebruikers meestal opteren om het default wachtwoord te gebruiken. Ze redeneren dat toch niemand dit simpele IoT-apparaat zal willen hacken. “Wat kan een hacker nu doen met toegang tot mijn digitale thermometer.” Wat echter vergeten wordt is dat cyberstropers altijd op zoek gaan naar de weakest link, om die vervolgens te misbruiken om tot het eigenlijk doel te geraken. Kortom, ieder IoT-apparaat in je omgeving is een potentiële toegangspoort tot de rest van je netwerk!
Zet je IoT in quarantaine: als je er toch niet zeker van bent dat je slimme lamp, thermostaat of camera veilig is (en eerlijk: dat ben je zelden), zorg er dan voor dat die toestellen niet aan de rest van je netwerk kunnen. Dat heet netwerksegmentatie. Thuis kan dat al door alle IoT-toestellen op het gastnetwerk van je router te zetten: de slimme stekker kan dan wel aan het Internet, maar niet aan de laptop met je bankgegevens of de NAS met je foto’s. In een bedrijf gebeurt hetzelfde op grotere schaal, met aparte netwerksegmenten (bijvoorbeeld via VLANs) voor camera’s, printers, productiemachines en kantoor-pc’s. Wordt één toestel gepwnd, dan zit de stroper vast in dat ene segment in plaats van vrij rond te lopen. Dit is layering en limiting uit de principes van verdedigen in de praktijk. Hoe je zo’n segmentatie concreet opzet, zie je in het vak Network Security.
Ongebruikte of onveilige netwerkservices
Als je vandaag een printer koopt dan zal dit apparaat bijna altijd een IoT-apparaat zijn dat je toelaat om vanop afstand te printen. Echter, dergelijke apparaten hebben vaak tal van netwerkservices draaien waarvan de gewone huis-tuin-en-keuken gebruiker weinig of niets van afweet.
Vergelijk dit bijvoorbeeld met je Microsoft Windows besturingssysteem: heb je al eens gekeken welke services allemaal permanent op je systeem draaien (Start -> uitvoeren -> services.msc) ?
Dit soort diensten uitzetten behelst ook weer dat de gebruiker weet heeft van een webpagina met administrator-instellingen. Soms zijn die diensten op de koop toe essentieel voor de goede werking van het apparaat en ze uitzetten is dan geen optie. Maar wat als die service op zich inherent onveilig is?! Zo zijn er apparaten die enkel telnet-sessies gebruiken om het apparaat in te stellen. Een telnet-sessie geeft je een remote shell die echter onversleuteld met het apparaat communiceert (in tegenstelling tot bijvoorbeeld SSH, Secure Shell, dat wél veilige communicatie aanbiedt).
Kortom, het is aangeraden om altijd te controleren welke services nu eigenlijk actief zijn op je apparaat.
In 2017 was er een grayhat hacker die vermoedelijk 150.000 printers vanop afstand in Nederland kon benaderen. Vervolgens printte hij “ludieke” berichten op de printers om de gebruikers er op te wijzen dat ze een onveilig apparaat gebruikten. In dit geval gebruikte hij poort 9100 van de printer die in veel merken wordt gebruikt om vanop afstand print-opdrachten door te sturen.
Onveilig ecosysteem
Een IoT-apparaat bestaat niet alleen: meestal maakt het deel uit van een verzameling apparaten en diensten die de gebruiker via online dashboards en apps kan bedienen. Denk maar aan de verschillende Google Nest producten (thermostaat, deurbel, maar ook de Hub, etc.) of lichten van Philips (Hue) die ook met behulp van andere toestellen kunnen bediend worden (bijvoorbeeld drukknoppen van Niko of Ikea). Kortom, IoT-apparaten maken meestal deel uit van een heus ecosysteem en dus de mate van veiligheid van die externe zaken bepaalt ook die van het IoT-apparaat. Als bijvoorbeeld de dashboards van fitbit.com zouden gecompromitteerd worden bestaat de kans dat de digitale stropers ook toegang tot je gegevens of apparaten krijgen die gebruik maken van het fitbit-portaal.
Gebruikers vergeten ook met welke externe diensten ze hun apparaten hebben gekoppeld. Het gebeurt vaak dat een gebruiker “even iets wil testen” (denk maar de nuttige website “If this then that” (ifttt.com) dat toelaat om services en apparaten te koppelen die iets moeten doen gegeven zelfgekozen triggers en regels) maar nadien wel vergeet deze koppeling uit te zetten. Dit geldt ook voor de vele third-party websites en services die toegang tot uw Google of Facebook/Meta-accounts wensen. Gebruikers kijken dit zelden na en hebben mogelijk tien jaar geleden al toegang gegeven aan een service die ondertussen al door digitale stropers is gecompromitteerd.
Geen of onveilig updatemechanisme
Dit werd al in de introductie van dit hoofdstuk aangehaald. Het updaten van fysieke apparaten is niet evident, zeker niet als het gaat om kleine, low-power-apparaten die mogelijk op de koop toe op een moeilijk bereikbare plaats hangen en dus enkel praktisch geüpdatet kunnen worden als ze een remote update-mechanisme ondersteunen.
Daarnaast kan het ook gebeuren dat een update, om welke reden dan ook, mislukt waardoor het systeem potentieel gebrickt geraakt en de gebruiker of administrator dan alsnog een fysieke rollback moet doen (als het apparaat die mogelijkheid heeft). Er zijn ondertussen erg dikke boeken geschreven over de wondere wereld van het updaten van IoT-apparaten. Weet dus dat het belangrijk is dat je als cyberboswachter van IoT-netwerken goed weet wat de update-strategieën van je IoT-apparaten zijn en wat je moet doen als er hier problemen optreden. Merk op dat die problemen zowel het gevolg van digitale stropers kunnen zijn, maar ook van slechte updates van de fabrikant die op hun beurt mogelijk nieuwe beveiligingsproblemen in je apparaten introduceren.
Het is ook essentieel dat je je als cyberboswachter abonneert op de juiste informatiekanalen (CVEs, fabrikant-RSS feeds, etc.)
We zijn afhankelijk van de fabrikanten om beveiligingslekken te dichten in onze software en hardware. Uiteraard zijn er fabrikanten die maar x aantal jaren patches uitbrengen, en er zijn ook al tal van IoT-apparaten op de markt waarvan de fabrikant al jaren niet meer bestaat.
In Europa komt daar stilaan verandering in: de Cyber Resilience Act verplicht fabrikanten om hun producten van beveiligingsupdates te voorzien gedurende een ondersteuningsperiode die past bij de verwachte levensduur van het toestel (in principe minstens vijf jaar). Die verplichtingen gelden vanaf december 2027.
Of wat te denken als er een kritieke bug wordt gevonden in een chip die ontelbare apparaten gebruiken. Wie moet dan de patch voorzien: de fabrikant van het IoT-apparaat, of die van de chip?
In september 2021 verscheen een nieuwe Bluetooth kwetsbaarheid, getiteld BrakTooth die mogelijk op miljoenen IoT-apparaten kan misbruikt worden. De bug zelf bevindt zich in de Bluetooth-chip van de apparaten. Aardig wat fabrikanten van dergelijke chips hebben al beloofd een patch uit te brengen, maar er zijn er ook die simpelweg zeggen “we zullen enkel patchen als er genoeg vraag naar is”, nochtans kan de kwetsbaarheid erg veel schade aanbrengen (DoS-aanvallen en arbitrary code execution (ACE))
Oude of onveilige componenten
Het voorgaande voorbeeld i.v.m. BrakTooth kan ook in deze sectie gebruikt worden. Een IoT-apparaat is en blijft een combinatie van tientallen, soms honderden hardware-onderdelen. De kans dat al deze onderdelen van de IoT-fabrikant zelf zijn is onbestaande. Gooi eender welke smartphone of digitale horloge open en je zal tal van onderdelen vinden van een andere fabrikant. De IoT-fabrikant moet er dus vanuit gaan dat deze componenten voldoen aan de veiligheidseisen die hij van z’n eigen product verwacht. Dat is geen evidentie.
Een zelfde fenomeen zien we enkele lagen hoger in de OSI-stack: ook op software niveau gebeurt het zelden dat de IoT-ontwikkelaars alle bibliotheken en protocollen van scratch hebben ontwikkeld (en dus ook zelf kunnen instaan voor de robuustheid ervan inzake cyberveiligheid). Wanneer er een bug (of bewuste backdoor) wordt ontdekt in een protocol of bibliotheek, dan heeft dit gevolgen voor alles en iedereen die deze dingen in zijn of haar apparaten gebruikt (denk maar aan de Log4J en Heartbleed voorvallen die we in hoofdstuk 1 vernoemden).
In 2020 was er veel heisa omtrent de SolarWinds-hack bij SolarWinds. Duizenden grote bedrijven (en Amerikaanse overheidsinstellingen) zoals Microsoft gebruiken het Orion Platform van dit bedrijf. Dit platform laat toe om enterprise netwerken te monitoren en managen, iets wat niet evident is op de schaal waarmee de klanten van SolarWinds werken. Deze tool moet natuurlijk waterdicht zijn, wat deze niet bleek te zijn: hackers (vermoedelijk van de Russische inlichtingendienst) slaagden erin om binnen te dringen in de omgeving waar SolarWinds zijn software bouwde, en konden zo een backdoor (Sunburst) in het Orion platform inbouwen. Dat de beveiliging bij SolarWinds niet waterdicht was, bleek trouwens ook uit een apart voorval: het wachtwoord van een van hun update-servers (solarwinds123…) stond een tijdlang gewoon publiek op GitHub. Vervolgens, wanneer de klanten van SolarWinds, hun Orion-installatie updateten, kregen ze onvrijwillig een versie met een bewust ingebouwde backdoor die de hackers vervolgens konden misbruiken.
Dit soort aanval heet een supply chain attack: de aanvallers richten zich op de weakest link binnen de supply chain om zo finaal tot bij de klant achteraan de keten te geraken.
Onvoldoende privacy bescherming
Ook IoT-fabrikanten moeten natuurlijk op een veilige, GDPR-compliant, manier omgaan met de persoonlijke informatie van hun gebruikers. Helaas wordt dit geregeld over het hoofd gezien. Ook hier hebben we weer het probleem van de vele potentiële manieren waarmee een digitale stroper (of de fabrikant zelf!) een IoT-netwerk en apparaat kan misbruiken. De persoonlijke data staat mogelijk wel op een ultra-beveiligde database bij de fabrikant on-premise, maar wat baat dat als deze informatie ook als plaintext op het apparaat wordt bewaard. Wat ons ook automatisch bij het volgende punt brengt.
Onveilige datatransfer en opslag
Herinner je je de McCumber kubus aan de start van dit handboek? Er werd toen benadrukt dat C.I.A. toepassen op je data geen nut heeft als je geen rekening houdt met alle vormen waarin de data zal voorkomen. Als je enkel encryptie gebruikt tijdens het versturen van data, maar niet tijdens het verwerken en bewaren ervan, dan is je data nog steeds kwetsbaar en geef je de gebruiker een false sense of security. De encryptie tijdens transport is dan niet nutteloos (ze beschermt nog steeds tegen afluisteren op het netwerk), maar wel onvoldoende.
We vallen in herhaling, maar dus zeker bij IoT-systemen die binnen een groot ecosysteem werken, met tal van third-party modules en bibliotheken, is het uitermate belangrijk dat ten allen tijde de IoT-data in al z’n vormen, op alle momenten, aan confidentialiteit, integriteit en beschikbaarheid doet.
Gebrek aan apparaat management
Spreken over IoT in een enterprise of industriële omgeving is spreken over IoT netwerken met honderden tot duizenden apparaten die bediend moeten worden (denk maar aan remote upgrades, instellingen wijzigen, etc.). Er zijn vele factoren waarom een robuust IoT device management systeem vereist is:
- De hoeveelheid apparaten: te veel om manueel te bedienen.
- De locatie: mogelijk bevinden de apparaten zich op moeilijk te bereiken of gevaarlijke plekken.
- Alarmen benodigd: soms wil je op de hoogte gesteld worden wanneer een bepaalde IoT sensor iets meet of niet goed werkt.
- Nuttig gebruik van personeel: personeel enkel naar je IoT-apparaten sturen als dat écht nodig is.
- Deel van mission critical applicaties: als je apparaten deel uitmaken van bedrijfskritische systemen is het uitermate belangrijk dat deze apparaten maximaal functioneren, daar iedere downtime of crash in winstverlies of boetes kan resulteren.
Een deftig apparaat management systeem moet natuurlijk zelf ook veilig en robuust zijn. Er zijn meerdere high-end oplossingen beschikbaar maar het spreekt voor zich dat dit soort systemen zelden goedkoop zijn.
Onveilige standaard instellingen
Dit item komt nog steeds voor in alle “10 veiligheidsproblemen die het meeste voorkomen”-lijstjes. Wanneer een apparaat uit de doos wordt gehaald is deze ingeladen met een hele hoop standaard instellingen. Instellingen die digitale stropers kunnen opzoeken en misbruiken. Niet alleen het wachtwoord moet ogenblikkelijk aangepast worden, vaak staan ook bepaalde services open zonder dat de gebruiker deze ooit zal gebruiken. Kortom, het is een gezonde gewoonte om, zowel als professional als huis-tuin-en-keuken IoT-gebruiker, steeds alle instellingen van je vers geïnstalleerde apparaat te controleren.
Je las het al bij wormen: wie begin jaren 2000 een ongepatchte Windows XP-computer aan het Internet hing, liep het risico dat die gepwnd werd nog voor je goed en wel alle updates had kunnen installeren. Het SANS Internet Storm Center mat in 2004 een gemiddelde survival time van zo’n 20 minuten. Bronnen:
Gebrek aan fysieke hardening
IoT-apparaten liggen meestal verspreid over grote gebieden, ruimtes of gebouwen. De kans dat ze op publiek toegankelijk plekken operationeel zijn is groot, daardoor ook de kans dat digitale stropers toegang tot de apparaten krijgen. Het is daarom belangrijk dat het apparaat ook op fysiek niveau gehardened is zodat dit apparaat niet als een open boek uitgelezen of aangepast kan worden. Het is natuurlijk niet evident om dit te voorkomen, net vanwege de aard van het beestje. IoT-apparaten werken dagen, weken, maanden zonder dat er iemand naar om ziet. Computers en telefoons maken deel uit van onze dagelijkse aandacht en daar is het dus veel moeilijker voor aanvallers om ongezien, fysieke, toegang tot te krijgen.
Computers zijn tegenwoordig goed beschermd tegen aanvallers die een laptop stelen en er trachten op in te breken: moderne beschermingen zoals Secure Boot (hoofdzakelijk om rootkits tegen te gaan) en Trusted Platform Module (TPM) voorkomen toegang door niet geautoriseerde gebruikers tot de data op het toestel. Dit soort systemen zit zelden in kleine, goedkope, IoT-apparaten waardoor inbreken op dit soort apparaten dus vaak eenvoudig is. Zeker als het apparaat op de koop toe een UART (een eenvoudige seriële poort, vaak gewoon een paar pinnetjes op het printplaatje) of andere onbeveiligde interface heeft die door de fabrikant worden gebruikt om problemen op te lossen. Ook aanvallers kunnen deze hardware interfaces natuurlijk gebruiken om bijvoorbeeld hun eigen firmware op het apparaat te plaatsen.
Er is gelukkig een trend gaande waarbij de TPM-chip (of alternatief) steeds meer z’n weg vindt in nieuwe IoT-apparaten. De initiële kost ervan vergaat meestal in het niets in vergelijking met de schade die kan opgelopen worden wanneer onbeveiligde toestellen (zonder TPM) worden gecompromitteerd.
De Mccumber kubus in gedachte nemende spreekt het natuurlijk voor zich dat ook de data geëncrypteerd op het IoT-apparaat moet bewaard worden.