Sesam, open u! – Advies over beveiliging van een slimme thermostaat

Door: Kevin Valk, Riscure

Als beveiligingsanalist bij Riscure werk ik voornamelijk aan mobiele beveiligingen zoals bij online-betalingen, HCE (Host Card Emulation) en mPOS (Mobile Point of Sale). Onlangs kocht ik een IoT-thermostaat genaamd Anna van Plugwise waarmee ik de temperatuur in mijn huis beter kon regelen. Bij het instellen van Anna moet je naar een webinterface gaan om het apparaat te configureren. Ik herinner me dat ik op een specifieke instellingenpagina een HTTP-statuscode ‘500 Internal server error’ kreeg met een volledige stacktrace gegenereerd door een Lua-script. Zoals je je wel kunt voorstellen, maakte dit me nerveus toen ik me realiseerde dat dit apparaat mogelijk een gat kon slaan in mijn thuisnetwerk. Om mezelf gerust te stellen voerde ik een kleine veiligheidsevaluatie uit om te verifiëren dat Anna inderdaad geen problemen zou opleveren in mijn huis … Achteraf gezien geen verkeerde gedachte.

 Binnenkant van de thermostaat: de printplaat met antenne.

Op onderzoek uit

Voor elk beveiligingsbewust persoon met enige kennis van basiselektronica levert de printplaat een schat aan waarde; alles is duidelijk gelabeld en voorzien van enkele debug-headers. Je kunt de voornaamste componenten zoals de microcontroller, RAM en flash duidelijk zien. Bovendien blijkt dat de 5-pins header een UART-interface is. Die is vast uitgeschakeld in een productieomgeving, toch?

Meekijken naar het opstarten tijdens het autobootproces. 

Helaas. Door eenvoudigweg een UART-kabel aan te sluiten en op het juiste moment een toets aan te slaan om het automatische opstartproces te stoppen, heb ik runtime-controle over Anna verkregen. Met de commandline-interface gepresenteerd door U-Boot kun je talloze dingen doen zoals het lezen van het flash-geheugen. Dit maakte me nieuwsgierig en ik wilde er dieper in duiken. Daarvoor had ik wel een flashdump van het bestandssysteem nodig.

Verder spitten

Een mogelijkheid om het bestandssysteem te verkrijgen, is door de flash-IC  direct uit te lezen met behulp van gebruikelijke hardware. We hebben echter al toegang tot de U-Boot-shell. Waarom zou ik die niet gebruiken?

Python-script voor het maken van een memorydump. 

Een klein Python-script en twee memorydumps later heb ik met succes een geverifieerde inhoud van de volledige flash-IC verkregen. Op basis van de initiële U-Boot shell wist ik al dat er een aangepaste versie van het OS (besturingssysteem) OpenWrt op dit apparaat werd gebruikt. Dit betekent dat er een SquashFS-partitie voor het read-only root-bestandssysteem is en een JFFS2-partitie voor alle gebruikersgegevens.

Herinner je de Lua stacktrace nog?

Het rootbestandssysteem was inderdaad een aangepaste versie van OpenWrt met één significant verschil: een vrij grote Lua -toepassing. Lua is een scripttaal en als je het bestand in een teksteditor opent dan zie je normaal gesproken de broncode verschijnen. Om betere prestaties te leveren kunnen Lua-scripts tot bytecode worden gecompileerd die de Lua VM (Virtual Machine) direct kan uitvoeren.
Net als de meeste bytecode-gecompileerde talen, bestaat er ook een decompiler voor Lua, namelijk LuaDec. Ik verwachtte dat ik daarmee de originele code gemakkelijk terug zou kunnen halen. Toch zat ik er flink naast. Bij het openen van sommige Lua-bestanden op de SquashFS-partitie kreeg ik de volgende gegevens te zien:

 

Dat is geen tekst. Maar het was ook geen Lua bytecode. Nader onderzoek toonde aan dat dit een aangepast coderingsschema is, gemaakt door Plugwise om zijn Intellectuele Eigendom (IP) op al zijn producten te beschermen.

Het duurde even maar enkele reverse engineering-inspanningen later lukte het om met een relatief eenvoudig Python-script de gecodeerde bytecode en de gecodeerde broncode te ontcijferen. De coderingssleutel zat in de Lua-interpreter zelf en is daarom gemakkelijk verkrijgbaar via statische reverse-engineering.

Na het decoderen van alle bestanden heb ik de originele broncode (inclusief opmerkingen en TODO’s) en de bytecode verkregen. Voor verdere analyse is het mogelijk een aanval te bedenken om het systeem binnen te dringen met behulp van HTTP-verzoeken (dus geen fysieke toegang tot het apparaat). Dit is vooral interessant omdat de web-interface rootgebruiker-rechten heeft zodat een aanvaller direct dezelfde rechten krijgt wanneer de aanvalt lukt.

En verder?

Tijdens het onderzoek van het bestandssysteem en de web-interface bleef een functie met de naam SSH-relay tevoorschijn komen. Normaal gesproken gebruikt men SSH-relays om firewalls te omzeilen door reverse-tunnels in te stellen. De Anna-thermostaat is in onbekende netwerken geïnstalleerd en SSH-relays gebruikt men om de toegang tot apparaten van buitenaf mogelijk te maken.

Illustratie van de samenhang tussen de ontwikkelaar Plugwise (links), de relay-server (onder) en de thermostaat achter een firewall (rechts). 

Bij nadere beschouwing was dit precies wat Anna deed om Plugwise toegang te geven tot de verkochte thermostaten. Er kunnen veel geldige redenen zijn om een dergelijke functie te implementeren. Dat moet wel op een veilige manier worden uitgevoerd om geen gevaarlijke gaten te maken in de beveiliging van het thuisnetwerk van consumenten. Daarom heb ik besloten om te onderzoeken hoe de omgekeerde tunnels zijn gemaakt.

De wereld aan je voeten

Plugwise heeft een complexe en dynamische HTTP-API om de apparaten te laten communiceren met de back-end. Een van deze eindpunten gebruikt Plugwise om een persoonlijke sleutel te verkrijgen om in te loggen in de back-end en een omgekeerde SSH-tunnel in te stellen. Als de SSH-gebruikers op de externe server niet goed zijn beveiligd, kan een aanvaller deze privésleutel gebruiken om een onbevoegde shell op de back-end te krijgen.

De architectuurkeuze van omgekeerde SSH-tunnels is niet optimaal, maar wanneer goed opgezet kan het voldoende zijn voor de oplossing. Een minimumvereiste is in ieder geval dat je de instellingen correct instelt zodat een aanvaller de server niet gemakkelijk kunt binnendringen. Om dat te verifiëren heb ik dezelfde API-verzoeken uitgevoerd als Anna om de persoonlijke sleutel te verkrijgen. Met de privésleutel zou ik kunnen proberen een interactieve SSH-shell in te stellen, volledig met de verwachting dat ik daarin niet zou slagen omdat alleen tunnels nodig zijn.

Je begrijpt mijn verbazing toen ik de boodschap volgens bovenstaande afbeelding kreeg. Ik beëindigde onmiddellijk de SSH-sessie en dacht na over wat er gebeurde. Niet alleen kreeg ik een shell zonder root rechten, het systeem draaide ook een OS (image) uit 2014! Dat betekent dat er veel kans is op misbruik om root-rechten voor dit systeem te krijgen. Wie weet hoe andere servers zijn verbonden en wat een rootgebruiker op het relay-systeem van het netwerk van Plugwise kan aanrichten? Er was slechts één laatste probleem dat ik wilde verifiëren voordat ik contact opnam met Plugwise. Als een aanvaller het IP-adres van de Plugwise-relayserver kent, kan de aanvaller dan een poortscan uitvoeren en rechtstreeks een verbinding maken met de apparaten in de thuisnetwerken?

Proef op de som

Bij het uitvoeren van een eenvoudige poortscan op de relayserver, kreeg ik een open poortlijst te zien. In totaal waren er 205 omgekeerde SSH-tunnels die rechtstreeks naar een Plugwise-apparaat in thuisnetwerken gaan. Gelukkig staan de SSH-servers in de apparaten alleen een rootgebruiker toe om in te loggen met een SSH-sleutel. Hoe dan ook, het feit dat dit systeem firewalls van een thuisnetwerk omzeilt en de Anna-thermostaat effectief openzet naar jan-en-alleman, is verre van ideaal.