Drie kwetsbaarheden ontdekt die ESP-microcontrollers kunnen overnemen en crashen

Er zitten een aantal lekken in de populaire ESP32- en ESP8266-IoT-microcontrollers. Daarmee is het mogelijk ontwikkelbordjes met die soc's te laten crashen, maar ook om een sessie over te nemen. De meeste kwetsbaarheden zijn inmiddels opgelost, maar één staat nog open.

Het gaat om drie lekken in de ESP8266-chips en de daarop gebaseerde ontwikkelboards, waarvan twee ook gelden voor ESP32-chips. De lekken werden ontdekt door Matheus Garbelini, die details over de kwetsbaarheden op GitHub plaatste.

Een van de kwetsbaarheden, CVE-2019-12588, is een vrij simpele methode waarmee een aanvaller de ESP8266 kan laten crashen. Dat is mogelijk omdat de chipset bij het maken van een verbinding niet controleert hoeveel mogelijke authenticatiemethodes er beschikbaar zijn als de ESP met een access point verbindt. Door een grote hoeveelheid informatie te sturen naar een ESP kan een buffer overflow ontstaan waardoor het apparaat kan crashen. Een dergelijke kwetsbaarheid zit ook in de SDK's van de ESP32 en ESP8266. Ook die kan worden bestookt met informatie, zelfs als het apparaat al aan een systeem is gekoppeld. Volgens Garbelini is CVE-2019-12586 gerepareerd voor de ESP32, maar nog niet volledig voor de risc-core voor het besturingssysteem van de ESP8266. De patches die wel beschikbaar zijn, zijn inmiddels doorgevoerd in de Arduino-ide.

De derde kwetsbaarheid, CVE-2019-12587, maakt het mogelijk om een sessie op de ESP's helemaal over te nemen. Dat gebeurt doordat de Pairwise Master Key tijdens het pairen in een sessie kan worden onderschept en gemanipuleerd, zodat een aanvaller met een zelfgemaakt access point een sessie kan afluisteren. Wel lukt dat alleen als de communicatie tussen de ESP's en het access point niet versleuteld zijn met tls, wat vaak wel het geval is. Garbelini wijst erop dat de andere twee lekken kunnen worden gebruikt om de ESP's te resetten, en zo een nieuwe pairing op te zetten die vervolgens met het derde lek kan worden onderschept. Ook dat lek zou volgens de ontdekker nog openstaan op de ESP8266.

Reacties (32)

[Corn]

Bijzonder populaire chips onder IoT hobbyisten. Voor zover ik begrepen heb zijn de twee gevaarlijkste exploits alleen issue bij het gebruik van EAP (WPA-Enterprise), wat door de toch wat complexe achterkant bij weinig mensen gebruikt wordt. Dit beperkt in veel gevallen de effectieve attack-mogelijkheden tot een DoS (Je kunt een gevoelige ESP laten crashen)

[Audiodude]

Is die bug ook in WPA2 Enterprise? Juist door certificaat achterkant is hacken interessanter ?

[ThaStealth]

De veelgebruikte Tasmota firmware is hier ook (deels) vatbaar voor (WPA-Enterprise support ontbreekt in de reguliere versies). Voor de crash attack is er ook een oplossing, maar vereist dat je de dev branch gebruikt, voor meer informatie zie dit github issue: https://github.com/arendst/Sonoff-Tasmota/issues/6348

[CurlyMo]

Je kan Tasmota ook vrij makkelijk laten crashen door een overload aan MQTT berichten erop af te vuren of door de MQTT flow niet te respecteren Of je dat nu als security bug moet zien? Het zijn niet voor niks embedded apparaten die maar een bepaalde load kunnen hebben voordat ze unresponsive worden.

[ThaStealth]

Ik zie dit als een security bug doordat dit door ongeauthoriseerde personen gedaan kan worden. Het crashen door een MQTT flood vereist dat je toegang hebt tot de MQTT broker, in dat geval heb je een groter probleem dan een Tasmota device wat crashed...

[lololig]

Het gaat hier even over de Arduino IDE, maar je kunt nog veel meer soorten code op deze controllers draaien. Dus hoe zit dat nou? Maakt het uit wat voor soort code je hierop draait?

[ThaStealth]

Het is afhankelijk van welke SDK je gebruikt, Arduino en Expressif (denk de meest populaire?) zijn inmiddels gepatched

[lololig]

Maar met Micropython heb je eigenlijk niet echt een SDK, is er ergens makkelijk te vinden wat wel of niet gepatched is?

[ThaStealth]

Micropython maakt gebruik van de esp-open-sdk, die weer afgeleid is van Expressif.
Hoe het precies zit (dus of het een fork is, of weer op deze SDK verder bouwt en dus iedere release geupdate word) weet ik niet. Ik ga er vanuit dat het een fork is, en dat de ontwikkelaar van deze SDK dus ook de patch moet doorvoeren en een nieuwe versie moet uitbrengen, het lijkt me aannemelijk dat Micropython op dit moment dus vatbaar is voor alle issues.

[Polderdijk]

Ik denk dat de eerste laag firmware is gepatched in Arduino IDE, zodat je ESP direct wordt gepatched als je je eigen code gaat uploaden.

Of dit precies zo werkt durf ik niet te zeggen, maar als je een andere IDE gebruikt, zou ik die iig updaten.

[Luc45]

Het vervelende van deze kwetsbaarheden in embedded systemen is dat het updaten handmatig moet gebeuren. In dit geval houdt dat in dat je elke ESP in huis moet flashen met vers gebuilde firmware. Best rot als ze goed weggewerkt zitten.

[Immutable]

Klopt. Je ziet ook steeds vaker Microcontrollers vervangen door low end SoC's met linux kernel erop met daarop weer allerlei services draaien zoals dus update services en natuurlijk de service van het hoofdprogramma.
Je kan bij Microcontrollers wel werken met een bootloader die een Ethernet stack heeft e.d. mjha. Als die bootloader een bug heeft moet je alsnog flashen....

[Luc45]

Dat zal inderdaad wel schelen. Bugs in de bootloader zullen vooral leiden tot kwetsbaarheden in bijvoorbeeld de secure boot sequence. Kwetsbaarheden die van buitenaf te misbruiken zijn zullen dan meestal wel via een reguliere update te patchen zijn.

[foekie01]

Een tweaker heeft deze toch zeker uitgeruist met ESP home en over the air updates via home assistant?

Ik liep hier voorheen ook tegenaan, bij mij zitten ze in de garage achter een muur en kastjes. Erg omslachtig met nieuwe firmware flashen. Sinds ESP home nooit meer last van Kijk er eens naar zou ik zeggen, het is een verademing!

https://esphome.io/
https://esphome.io/guides/getting_started_hassio.html

Kijk ook eens naar tasmota.
https://github.com/arendst/Sonoff-Tasmota

[Reactie gewijzigd door foekie01 op 23 juli 2024 12:39]

[Zynth]

Nadeel is dat je dan je IoT omgeving wat meer inricht op een enkele domotica oplossing.
Ik prefereer gewoon C, maar dan wel met OTA functionaliteit; zit standaard in de examples van de IDE.

[TunderNerd]

Niet waar, de ESP32 kan OTA

[Luc45]

Mits je dit hebt ingeregeld natuurlijk.

[diondokter]

Tijd om Rust te verplichten
Buffer overflow is echt niet meer nodig.

[Immutable]

Als je zo laag tegen de hardware praat, direct op de hardware moet je toch vaak wel unsafe gebruiken?
Kijk eens naar de ARM Cortex HAL libs voor STM32 bijvoorbeeld met Rust. Heel veel unsafe. Omdat je praktisch niet anders kan.

Als je toch denkt dat het wel kan. Zie ik graag het bewijs in vorm van git pull requests bij de desbetreffende opensource Rust HAL libs.

[Reactie gewijzigd door Immutable op 23 juli 2024 12:39]

[diondokter]

Haha nee, als je met registers praat, dan moet dat unsafe zijn.
Maar registers geven geen buffer overflow

Ik ken de software niet waar deze bugs in zitten, maar als ik er zo snel naar kijk, lijkt het er op dat er een packet verstuurd wordt die zegt dat die een x aantal beacons stuurt, maar het er in werkelijkheid y beacons zijn. Dit is puur software en heeft verder niks met hardware te maken. Volgens mij zou in dit deel dus geen unsafe code in hoeven staan.

[Immutable]

Ik probeer niet Rust de grond in te praten. Met unsafe zorg je ervoor dat je de locaties waar het fout kan gaat benoemd en zo klein mogelijk maakt. Als je dat zoveel mogelijk doet tot net op aan de hardware, scheelt dat enorm. Ik zie wel veel potentie daarin hoor.
En ja je hebt gelijk, de verdere software boven de software die met de directe hardware registers praat profiteert er zeer zeker wel van.

[armageddon_2k1]

Jammer dat veel Rust libs te pas en te onpas unsafe gebruiken....

[SuperDre]

Nee dankje......

[Neophyte808]

Bij deze chips is de eerste kwetsbaarheid waar ik aan denk toch vooral dat je het WiFi wachtwoord in je source code moet zetten volgens de meeste voorbeelden.

[WoutervOorschot]

Hoe zou je anders zo’n apparaat met de wifi verbinden als er niks anders op staat dan diezelfde sourcecode?

[Neophyte808]

Zoiets: https://arduino.stackexch...ardcoding-the-credentials

Maar ik zie dat sander85 hieronder inmiddels al hetzelfde principe beschrijft. Daarmee verplaats je het probleem naar het wachtwoord van de AP, maar dan is je WiFi wachtwoord in ieder geval niet meer te stelen via SSID spoofing.

[sander85]

Dat hoeft niet per se. Je zou ook een library kunnen gebruiken als deze: https://github.com/Hierom...ect/blob/master/README.md. Hiermee start de ESP eerst op als AP om dan vervolgens via een webinterface de ssid en wachtwoord op te egeven. Deze waardes worden in de EEPROM opgeslagen. En ja, ook die is weer uit te lezen.

[Neophyte808]

Hoe?
Het lijkt me belangrijk om er voor te zorgen dat:
1. je WiFi wachtwoord niet gecompromitteerd wordt en
2. je ESP powered device geen onderdeel uit gaat maken van een ander (rogue) netwerk

Als je het EEPROM alleen bedraad uit kan lezen, heb je bovenstaande security issues al uit de weg geruimd.

[sander85]

Ik bedoelde dat wat in de EEPROM staat ook clear text is en je andere code zou kunnen uitvoeren (dmv. flashen) en zo het wachtwoord kan uitlezen. Of mogelijk door bedraad de EEPROM uit te lezen. Dus EEPROM is wel meer secure dan in je code.

[r0ut]

Weet iemand of micropython firmware ook gevoelig is? Die gebruikt uiteindelijk expressif sdk. Dus ik denk van wel.

[ThaStealth]

De Expressif SDK is ook vatbaar, maar ook al gepatched: https://github.com/espressif/esp-idf/releases/tag/v3.3

edit:

Ben even wat dieper erin gedoken,

Micropython maakt gebruik van esp-open-sdk (https://github.com/pfalcon/esp-open-sdk) wat weer een afgeleide lijkt te zijn van Expressif, de ontwikkelaar zal denk ik een patch moeten uitbrengen voor zijn SDK, die weer door Micropython opgepikt moet worden.

[Reactie gewijzigd door ThaStealth op 23 juli 2024 12:39]

[r0ut]

Aha, Bedankt voor het uitzoeken!