Onderzoekers: ESP32-chip kan door kwetsbaarheid worden misbruikt voor aanvallen

Onderzoekers hebben verborgen HCI-commando's gevonden voor de populaire ESP32-microcontroller. Daardoor is het onder meer mogelijk om het ram en flash te modificeren en om bluetoothaanvallen uit te voeren. Wel is hiervoor fysieke toegang tot de module vereist.

De onderzoekers van het Spaanse Tarlogic Security hebben 29 ongedocumenteerde operation codes, ofwel HCI-commando's, gevonden voor de ESP32-microcontroller, die gebruikt wordt in miljoenen iot-apparaten. Met deze opcodes krijgt de software die op het apparaat draait meer privileges.

Zo is het onder meer mogelijk om het macadres van vertrouwde apparaten te spoofen, het geheugen te modificeren en packet injections uit te voeren, zeggen de onderzoekers tegen Bleeping Computer. Hierdoor kunnen kwaadwillenden volgens de onderzoekers in theorie verbinding maken met vertrouwde apparaten als smartphones en computers om toegang te krijgen tot gevoelige gegevens.

Om deze schadelijke commando's uit te voeren is er wel directe toegang tot de microcontroller vereist, waardoor de kans op misbruik klein is. Bleeping Computer speculeert dat het wellicht mogelijk is om de aanvallen op afstand uit te voeren mits er al malafide firmware op de chip is geïnstalleerd, maar ook dat vereist verregaande toegang. Wel kunnen sommige commando's volgens de onderzoekers mogelijk worden ingezet om aanvallen uit te voeren bij andere bluetoothapparaten, maar daarop wordt niet verder ingegaan.

Het is niet duidelijk of de fabrikant van de ESP32-microcontroller, Espressif, deze commando's per ongeluk toegankelijk heeft gemaakt. Het bedrijf heeft vooralsnog niet op de bevindingen gereageerd. De kwetsbaarheid staat bekend onder CVE-2025-27840 en heeft een ernstigheidsscore van 6,8 gekregen.

Reacties (89)

[The Third Man]

De in de CVE gelinkte tweet van Pascal Gujer prikt al aardig door de zeepbel heen van het zogenaamde gevaar:

ESP32 “backdoor”? Not so fast.

Yes, hidden HCI commands allow deep access to memory, flash, and Bluetooth internals. BUT:

❌ Not remotely exploitable via Bluetooth
❌ Not an OTA attack
✔ Requires wired HCI access
✔ Requires high privileges on controller

It’s a post-exploitation tool, not an instant game-over. If an attacker already controls the host device, you’re cooked anyway.

[jameskond]

Waarom denk je dat het een 6.8 CVSS score krijgt?

[laurxp]

Omdat CVSS scores grotendeels betekenisloos zijn. De scores zijn in veel gevallen toegekend door een partij die vrij weinig weet van beveiliging, waardoor achteraf bijvoorbeeld een "CRITICAL" vulnerability met een score van 9.1 terug gaat naar een 3.4.

Daarnaast zijn de scores verschrikkelijk inconsistent: er is een vrij grote kans dat dezelfde reviewer met dezelfde kennis bij een tweede scoring een andere score geeft, en met dezelfde kennis geven reviewers compleet verschillende scores voor dezelfde vulnerability.

Leuk dat het dus een CVSS van 6.8 krijgt, maar dat zegt letterlijk niks over de impact van deze kwetsbaarheid.

Om een analyse te geven van deze score:

• Scope: Changed is twijfelachtig. Om de aanval uit te voeren moet je "root" zijn, en je krijgt daarvoor volledige controle over het apparaat. Hier zou "Scope: Unchanged" logischer zijn.
• Confidentiality: High heeft hetzelfde probleem. Ná de aanval is er inderdaad geen confidentiality, maar die was er voor de aanval ook niet. Er is daardoor geen loss of confidentiality, dus "None" zou beter zijn.
• Integrity: High is idem, en zou daardoor beter "None" kunnen zijn.
• Availability: Low is hier een heel aparte keuze. Gezien de overige scores zou ik hier van hun "High" verwachten, maar omdat je dus roottoegang nodig hebt voor de aanval zou ik ook hier "None" verwachten

Combineer het bovenstaande met het AV:P/AC:H/PR:H/UI:N stukje (waar weinig twijfel over kan bestaan), en het heeft ineens een score van... 0.0.

[Reactie gewijzigd door laurxp op 9 maart 2025 21:28]

[Bor]

Omdat CVSS scores grotendeels betekenisloos zijn.

Dat is wel een behoorlijk (en overdreven) stelling. CVSS is nog steeds de industrie standaard scoring methode wanneer het op kwetsbaarheden aankomt. Je laat het overkomen alsof men "maar wat doet" maar dat is natuurlijk niet waar. CVSS is redelijk eenvoudig in te schalen door bv een calculator te gebruiken. Scores die van een 9.1 naar een 3.4 gaan zijn echt uitzonderingen ipv regel zoals jij het hier laat overkomen.

Houd je er ook rekening mee dat "grotendeels betekenisloos zijn" een persoonlijke blog / mening (van de ontwikkelaar van curl) is die niet industrie breed wordt gedragen en er meerdere redenen zijn te bedenken waarom men zich niet achter CVSS schaart? Er zijn overigens inmiddels nieuwe CVSS iteraties geweest die zaken (deels) anders aanpakken.

Confidentiality: High heeft hetzelfde probleem. Ná de aanval is er inderdaad geen confidentiality, maar die was er voor de aanval ook niet. Er is daardoor geen loss of confidentiality, dus "None" zou beter zijn.
Integrity: High is idem, en zou daardoor beter "None" kunnen zijn.
Availability: Low is hier een heel aparte keuze. Gezien de overige scores zou ik hier van hun "High" verwachten, maar omdat je dus roottoegang nodig hebt voor de aanval zou ik ook hier "None" verwachten

Deze zaken zijn een beetje kort door de bocht en hangen vooral af van de config van de controller in kwestie. Je schrijft hier moedwillig naar de 0.0 toe wat natuurlijk onzin is bij een kwetsbaarheid. Wanneer je alles op "none" inschaalt is er geen kwetsbaarheid. Zo ken ik er nog wel een paar.

Om enkele zaken die je aanhangt te ondervangen wordt er niet met een enkele score gewerkt maar kennen we Base, Temporal, en Environmental scores.

[Reactie gewijzigd door Bor op 10 maart 2025 08:16]

[MSalters]

Je schrijft hier moedwillig naar de 0.0 toe wat natuurlijk onzin is bij een kwetsbaarheid. Wanneer je alles op "none" inschaalt is er geen kwetsbaarheid.

En dat is correct. Dat is niet alleen een opinie van de Curl ontwikkelaar, maar ook van een core Microsoft Engineer, Raymond Chen.

Wat je kunt doen ná het breken van de security is geen security issue meer.

[Bor]

De opinie van de curl ontwikkelaar omtrent CVSS en de blog van Raymond Chen stippen ten eerste met name andere punten aan en zijn nog steeds persoonlijke blogs / visies.

Wat je kunt doen ná het breken van de security is geen security issue meer.

Dat is op zich een vreemde stelling in mijn ogen. Is het (kunnen) breken van de security niet de kwetsbaarheid op zich?

[Reactie gewijzigd door Bor op 10 maart 2025 12:49]

[MSalters]

Het kunnen breken van security is een probleem, maar dat is hier niet aan de orde. Deze opcodes vereisen dat er al een RCE exploit is met root rechten. Dat is dus precies waar Raymond ook naar verwijst, en wat jij niet lijkt te snappen: deze opcodes is geen security exploit. Elke aanvaller die ze zou kunnen gebruiken heeft die niet eens nodig. Daarom is dit noch voldoende noch noodzakelijk voor een security breach.

[killercow]

Je maakt nogal wat stellingen.

kun je aantonen dat het inderdaad vaak voorkomt dat 1 reviewer voor de zelfde (soort) issue een andere score uitdeelt?

[Bor]

Als dat zo is zou je een heel groot aantal CVSS scores moeten zien die enorm zijn aangepast en dat blijkt in de praktijk wel mee te vallen. Foute inschalingen gebeuren maar niet op de schaal wat wordt voorgespiegeld.

[EraYaN]

Dit is ook wel omdat voor heel veel CVE's eigenlijk niemand cared. Het wordt vaak pas aangepast als het een CVE met veel impact of een marketable product betreft. Anders geeft niemand er om wat die score is.

[Bor]

Dat is niet geheel waar gezien o.a. veel vulnerability scanners de CVSS score gebruiken voor inschaling. Niet kloppende scores gaan vanzelf opvallen.

[EraYaN]

Maar als gebruiker heb je vaak erg weinig invloed, ontwikkelaars en de uitgevende instanties geven 0 fucks. Je praat met je vuln scanner vendor en die kan het dan intern regelen als het gekkigheid is. Of je zet een override in je config.

[Bor]

Ik ken geen vulnerability scanner waarbij de leverancier zelf CVSS scores gaat lopen aanpassen binnen zijn / haar product. Dat zou in mijn ogen ook niet zuiver zijn.

[Reactie gewijzigd door Bor op 10 maart 2025 21:21]

[EraYaN]

Nee, ze halen ze nog wel eens uit de db, of zetten het naar een extra lijst of geven het extra tags, zodat als jij in je config 1 van die tags negeert telt hij niet mee. Helemaal zuiver, goed gedocumenteerd en opt-in. En ze hebben natuurlijk een opmerkingen veld, daar zetten ze vaak genoeg wat in na een conversatie met hun support team. Het gebeurt nog al eens dat CVEs niet van de databases gehaald worden terwijl ze wel gewoon invalid zijn. Of bijvoorbeeld de versie constraints compleet verkeerd zijn etc.

[AJediIAm]

Geef het wat tijd. Wordt vanzelf weer bijgesteld.

[YopY]

Hier ook een goeie breakdown; het is een "private API" zoals die ook in andere aanbieders van bluetooth producten zitten, dat betekent niet dat het een backdoor is: https://darkmentor.com/blog/esp32_non-backdoor/

Daarnaast, de esp32 is ondertussen 9 jaar oud en miljoenen keer gebruikt, ontmantelt, etc; het lijkt me heel sterk dat dit de eerste keer is dat deze private API gevonden is.

[B_FORCE]

Precies dit dus.

Er lijkt altijd veel drama rond "kwetsbaarheden", maar in best veel gevallen lijkt het toch steeds weer te gaan om dingen waarbij je fysieke toegang nodig hebt.
Wat praktisch gezien nogal vergezocht is.

Om vervolgens ook maar gemakshalve de use case en praktische impact niet eens mee te nemen.

Bij microcontrollers is het al helemaal nogal een storm in een glas water.
Van de honderden IC's die ik de afgelopen 20 jaar heb gebruikt, heeft het merendeel allerlei bugs en eigenaardigheden.

Bij heel veel designs ligt bv de UART wagenwijd open.
Vaak niet meer dan usb dongle aansluiten, Putty opstarten en in veel gevallen ben je binnen.

[naaitsab]

Inderdaad weer een poging om met twijfelachtige constateringen (of slechte berichtgeving) security te misbruiken voor aandacht. Dit is echt niks nieuws en valt prima onder de welbekende risico factor dat als een aanvaller fysiek toegang heeft, je sowieso de pineut bent. Of als je zonder enige check een binary gaat flashen, dan loop je ook een risico, ook niks nieuws. Helemaal met de wildgroei aan malafide Github repo's de afgelopen tijd.

[Frame164]

Als er een lek in de productiestraat is voor producten waarbij deze modules worden gebruikt kan er wel degelijk misbruik van worden gemaakt. Je ontwerp naar eer en geweten een product, maakt software voor de ESP en levert het geheel aan aan een productie bedrijf. Iets wat geen ongebruikelijk scenario is. Vervolgens wordt er ergens in de keten de vulnerability geëxploiteerd.

[naaitsab]

Dat is exact wat ik bedoel met als iemand fysiek toegang heeft je überhaupt al een probleem hebt. Hardware toegang tot de chip en firmware is al sinds jaar en dag een lek/feature van de ESP. Wellicht niet bekend bij de onderzoekers maar wel bij iedereen die ermee werkt/speelt. Kwaadaardige firmware pushen in de productiestraat is zeker een beveiligingsprobleem. Dat heeft echter niks met de ESP of deze CVE specifiek te maken. Immers kan hetzelfde gebeuren met elk stuk hardware dat voorzien wordt van firmware tijdens fabricage. De chip voert gewoon elke code uit die er wordt gevoed, er zit geen check in of iets wel/niet malafide is.

De term 'zeepbel' is zeker passend bij deze publicatie. Rumoer om niks wat mij betreft.

[TWeaKLeGeND]

Fysiek toegang hebben en ooit fysiek toegang hebben gehad zijn verschillende dingen, om welke van de twee het hier gaat is me niet duidelijk. Is zelf een legitieme firmware flashen de oplossing?

[Reactie gewijzigd door TWeaKLeGeND op 9 maart 2025 19:21]

[Niemand_Anders]

Opcodes zitten niet in de firmware, maar in de hardware. Alle processing (alle vormen dus micro, central, grahpical, neural, etc) units hebben undocumented opcodes. Sommige van deze codes kunnen gebruikt worden voor binning toepassingen voor CPU's. Ook zijn er opcodes om processors te testen vanuit de fabriek op correcte werking.

Veel microprocessors zijn bijvoorbeeld via de JTAG connector al te debuggen, wijzigen (mem state updates) of te flushen. Dit wordt bijvoorbeeld al veel gedaan met home automation IOT devices.

Daarbij de onderzoekers geven ook helemaal niet aan hoe deze opcodes misbruikt kunnen worden. Het document gaat grotendeels over het Spaanse bedrijf van de onderzoekers zelf.

[laurxp]

Sure, maar daar heb je deze vulnerability niet voor nodig. Je kán dan al malafide firmware flashen, dus je hebt al volledige controle over het apparaat.

Het is alsof een aanvaller de radio van een reeds gestolen auto op een willekeurige zender kan zetten. Leuk dat het kan, maar de radio is niet het probleem...

[GertMenkel]

De presentatie zelf vond ik eerlijk gezegd niet zo overdreven. Het ging vooral om reversen van de code en de vendor opcodes waren een toevalligheidje.

In die context is dit ook een hele waardevolle exploit: als je de ROM niet zomaar kunt dumpen, en de hardware die je onderzoekt alle veiligheidsfeatures (secure boot, flash encryption, etc.) aan heeft staan, is het verkrijgen van geheugen en het herprogrammeren van command flows via HID toch heel erg waardevol.

Van hoe ik de slides interpreteer, krijg ik meer het idee dat de ontdekkers het als een handige feature zien die de reverse engineering community wel kan waarderen, alhoewel het technisch gezien een kwetsbaarheid is en praktisch gezien dit soort dingen door Espressif uit hun binaries had moeten zijn gehaald. Vervelend voor bedrijven die topgeheime algoritmes in ESP32's stoppen om ze te verkopen maar niet iets waar de consument last van heeft.

[Reactie gewijzigd door GertMenkel op 9 maart 2025 18:41]

[TheDudez]

Dan valt het inderdaad erg mee!

[JeroenED]

Maar natuurlijk is backdoor leuker om te zeggen dan "gehackt systeem is kwetsbaar". Dat laatste heeft meer waarheid maar is gewoon captain obvious.

[Amanoo]

Tegen die tijd kan je ook gewoon je eigen firmware erop flashen. Of als de fabrikant de security features van de ESP32 gebruikt waardoor het niet kan, gewoon een eigen microcontroller installeren. Daar ga ik niet wakker van liggen.

[Reactie gewijzigd door Amanoo op 9 maart 2025 18:58]

[Aardedraadje]

Ik denk dat men de ernst van dit probleem iets te veel bagatelliseert. Ja, het vereist fysieke toegang. Maar dit is niet per se alleen een probleem voor gebruikers. Dit is vooral een probleem voor productontwikkelaars die een dergelijke chip in hun product toepassen.

Op het werk gebruiken wij vaak NXP-chips. Microcontrollers waarop wij closed-source firmware flashen in productie. Hierbij zorgen we ervoor dat de binary niet meer via de debug-/programmeerport uitleesbaar is. Uit angst dat concurrenten de firmware zouden uitlezen en reverse-engineeren.

Stel nu dat zou blijken dat er backdoor-commando's in de chip zitten waardoor een concurrent toch in onze firmware zou kunnen gaan rondneuzen. Dat zouden we echt niet tof vinden.

En dat is hier het probleem.

[Dennisb1]

Dat kan toch wel mits je de juiste middelen en tijd hebt. Deze manier maakt het slechts wat makkelijker.

[Mellow Jack]

Voelt voor mij als 1 van de problemen. Een ander probleem lijkt me een zogenaamde supplychain aanval. Kan me voorstellen dat veel partijen leunen op externe libraries die wel eens stiekem dit soort commandos kunnen uitvoeren. Misschien dat een ervaren ontwikkelclub de libraries zal doorspitten maar Jan met de korte achternaam niet

[The Zep Man]

Wel is hiervoor fysieke toegang tot de module vereist.

Volgens mij zijn ESP's nooit ontwikkeld om fysiek goede beveiliging te bieden. Dit is niet zo spannend.

[laurxp]

ESP's zijn redelijk veilig, hoor. Ze hebben ondersteuning voor secure boot, waardoor alleen firmware van de oorspronkelijke maker gedraaid kan worden. Daarnaast hebben ze ondersteuning voor flash encryption, wat het onmogelijk maakt om de firmware uit te lezen.

Niet ieder bedrijf maakt hier gebruik van, maar als het aan staat is het zelfs met fysieke toegang nog bijzonder lastig om aanvalscode op de MCU draaiend te krijgen.

[WhatsappHack]

Ja je moet de commando’s uitvoeren vanuit de software die je op de chip schrijft. Om dat nou een backdoor te noemen gaat me wel wat ver… En wat opcodes die niet gedocumenteerd zijn vind ik ook niet direct heel gek. En de MAC kunnen spoofen met de chip: ja…? Dus?

Maar misschien zien we iets over het hoofd, het artikel klinkt voor mij in eerste instantie iig een stuk sensationeler dan wat het in werkelijkheid lijkt te zijn.

[Reactie gewijzigd door WhatsappHack op 9 maart 2025 11:52]

[dasiro]

tot er een supply-chain attack is in de hardware die in een later stadium in software misbruikt kan worden (hoeveel open-source projecten zijn er wel niet waar je code aan kan bijdragen)

[The Zep Man]

tot er een supply-chain attack is in de hardware die in een later stadium in software misbruikt kan worden

Als je in een positie bent dat jou een aantrekkelijk doelwit hiervoor maakt, dan maak je geen gebruik van ESP's. Het was ook voor dit nieuws bekend dat ze niet hardened zijn.

[Zer0]

IoT devices, waar je de ESP regelmatig in tegen komt, zijn een aantrekkelijk doelwit, om als "tool" voor verdere zaken te gebruiken, Dat zou geen nieuws moeten zijn. Dus een supply-chain attack, waarbij bijvoorbeeld een opensource package, software of library misbruikt word, is zeker een mogelijkheid.

[The Zep Man]

Een supply chain attack is niet afhankelijk van, of meer of minder gevoelig door opensource code. Zie bijvoorbeeld de Hamas piepers die onderschept werden door Israël.

Als een supply chain attack realistisch is volgens je risicoanalyse dan kan je dat risico op verschillende manieren mitigeren.

[Reactie gewijzigd door The Zep Man op 9 maart 2025 17:54]

[Zer0]

Een supply chain attack is niet afhankelijk van, of meer of minder gevoelig door opensource code

Daarom staat er ook "bijvoorbeeld"...

Als een supply chain attack realistisch is volgens je risicoanalyse dan kan je dat risico op verschillende manieren mitigeren.

En hoeveel consumenten met IoT apparatuur doen aan een risicoanalyse?

[dasiro]

je gaat er nog steeds van uit dat het om directe, gerichte aanvallen gaat en niet bvb om het opzetten van botnets of ander mogelijk misbruik. Er zijn genoeg landen met digital warfare bezig om bvb de toeleverancier van SD-kaartjes van de Raspberry Pi Foundation te infiltreren en hun toestellen bij het verbinden met een ESP32 wat te laten doen. Ze zoeken niet de moeilijkste manier om binnen te geraken.

[dasiro]

spoiler: heel veel mensen en bedrijven hebben toestellen waarvan ze zelfs niet weten welke chip er in zit, laat staan dat ze weten dat hun toestel een target kan zijn (daarom moet de eigenaar ervan nog niet een (bewust) target zijn).

[The Zep Man]

spoiler: heel veel mensen en bedrijven voeren geen goede risicoanalyse uit.

Fixed. Hardened hardware of niet gaat daar geen verschil in maken.

[dasiro]

het aantal sectoren waar ze die moeite nemen voor elk toestel dat in het netwerk komt is héél beperkt, laat staan dat ze daar het personeel voor hebben met de juiste kwalificaties.

[The Third Man]

Undocumented upcodes zijn wel wat lelijk omdat je een firmware zo niet kan auditen op wat het praktisch doet (of de auditor moet deze set nu reverse engineeren, maar dat blijft een educated guess). En je kan storage manipuleren voor rookits e.d. zodat ook na een reflash het apparaat ‘besmet’ blijft. Het is dus wel een backdoor, maar niet op afstand. Ik ben het er op zich mee eens dat ESP’s al niet inherent superveilig bedoeld zijn, maar een fabrikant hoort wel de obvious zaken te documenteren. En wellicht is dit zelfs een nalatigheid geweest om een ontwikkelingsbackdoor (daar ontstaan ze vaak) niet in productieversies te blokkeren.

[TD-er]

Sowieso is de WiFi implementatie van de ESP-processoren een gesloten boek.
Het is niet meer dan een binary blob waarin overduidelijk nog steeds bugs zitten waar je dan als gebruiker omheen moet werken. Al is het tegenwoordig al een stuk beter dan een paar jaar geleden...

Wat dat betreft is dat het deel van de ESP's waar ik mij nog het meest aan irriteer, omdat het closed source is, op z'n best matig gedocumenteerd en je hebt eigenlijk geen idee wat nu precies de verschillen zijn als er weer een nieuwe versie van zo'n binary blob is vrijgegeven. De changelogs zijn vaak nogal nietszeggend.

Maar om dit nu een backdoor te noemen is wel een beetje 'click-bait'. Feit is dat je met de ESP's best wel low-level toegang kunt krijgen en daar hele leuke dingen mee kunt doen (zie bijv. de deauth firmware voor ESP8266) en het is ook een feit dat de documentatie en openheid van de RF-gerelateerde componenten nogal te wensen overlaat. Maar een backdoor zou ik het niet willen noemen.

[tedades]

Zodra je deze dingen op afstand kunt uitvoeren is er een groter probleem. Want niet ieder consument heeft bewust een ESP32 gekocht, die zit soms verwerkt in een (IOT) product.

[The Zep Man]

Dat is nog steeds een "als", wat niet veranderd is ten opzichte van voor dat dit nieuws uitkwam.

[SuperDre]

Juist door alles wat je eerst moet doen en de benodigde toegang is het zeker niet spannend, en lijken het sowieso gewoon debug commands. Maar je begrijpt natuurlijk wel dat voor een nieuwssite dit als mooie clickbait klinkt want de chip wordt in miljoenen/miljarden verschillende devices gebruikt. Valt nog mee dat Tweakers de beperking om misbruik er van te maken uberhaupt vermeldt, genoeg andere sites doen dat niet, en benoemen het ook expliciet als een chinese backdoor.

[Reactie gewijzigd door SuperDre op 9 maart 2025 19:54]

[eazyq]

Iot apparaten. Wat zou je daar dan mee willen doen als je die hacked vraag ik me af. Buurtje pesten?

[Bor]

Iot apparaten. Wat zou je daar dan mee willen doen als je die hacked vraag ik me af. Buurtje pesten?

Een botnet creëren bijvoorbeeld zoals Mirai of Reaper of een compromised IOT device gebruiken als initial access om zo verder het netwerk en de systemen in te gaan. Helaas staan IOT devices er nog steeds om bekend dat ze amper gepatched worden

[wildhagen]

Nou, vaak (nee, niet altijd) zitten IoT devices op Internet. Als een hacker daar binnen zou kunnen komen, kan hij die devices bijvoorbeeld gebruiken om een onderdeel van een botnet te vormen.

Dat botnet op zijn beurt kan dan weer voor van alles en nog wat gebruikt worden. Van phishing-attacks tot DDoS-attacks tot spamcampagnes, ransomware-aanvallen en weet ik wat nog meer.

Als je als botnet maar genoeg van die devices bij elkaar hebt kan je daar best wel wat mee aanrichten.

Dit in zijn algemeenheid uiteraard, niet specifiek met betrekking tot het (potentiele) lek uit dit artikel.

[TweakerCarlo]

Als die het internet op kunnen dan heb je zomaar eens een botnet met mogelijk miljarden devices die je niet zomaar kan/gaat updaten tot je beschikking. Vast nog wel meer shady dingen mee uit te voeren als ze bijvoorbeeld in jou eigen prive netwerkje hangen.

Dan trouwens, hoeveel apparaten zijn wel niet lek als je fysieke toegang hebt?
Zal wel meevallen dus.

[Reactie gewijzigd door TweakerCarlo op 9 maart 2025 12:29]

[WhatsappHack]

Als het je als aanvaller meezit kan je er een casino mee hacken.

[TheDudez]

Als je het alleen lokaal draait achter home asistant bijvoorbeeld. Dan heb je helemaal geen last van dit lek als ik mij niet vergis. Alleen de buurman kan je dan inderdaad pesten in het ergste geval.

[Frame164]

Grappig om te zien hoe een security flaw bij een product als dit ineens geen probleem gevonden wordt. Als er Intel, Apple, etc op had gestaan hadden er 10 keer zoveel reacties gestaan die dan ook allemaal negatief waren.

[smiba]

Als een intel CPU een ongedocumenteerde opcode heeft, die enkel exploitable is als root/Administrator (met niet significante impact) zou de commotie ook een stuk minder zijn. Sterker nog dat gebeurt volgens mij nog wel eens

[Bor]

Nee de commotie zou naar alle waarschijnlijkheid niet minder zijn. Undocumented "features" zijn zeer ongewenst, niet in de laatste plaats omdat je nooit weet wat de intentie hiervan is.

[AJediIAm]

Duik er even in. Dit soort debugging features zijn redelijk normaal. Veel andere media is het al aan het nuanceren nu het algemeen bekend is dat het om een non-issue gaat.

[Bor]

Heel normaal wanneer ze gedocumenteerd zijn. Dat maakt het eenvoudiger mogelijk om op bv kwetsbaarheden ze zoeken. Ongedocumeteerrde 'features' zijn ongewenst. De veiligheid daarvan is al snel gebaseerd op security by obscurity.

Een ongeducumenteerde kwetsbare feature is geen non issue.

Hoeveel meer ongedocumeteerrde features zijn er nog waar we bv niets van weten?

[Reactie gewijzigd door Bor op 10 maart 2025 15:58]

[AJediIAm]

Elke chip heeft ze. Lees gerust wat andere media bronnen er over schrijven. De storyline is al redelijk omgeslagen.

[Bor]

Het is vrij normaal dit soort zaken te documenteren waar van toepassing . Dat is het grote issue hier.

[kodak]

Het nuanceren lijkt eerder te gaan om geen zekerheid hebben dat de fabrikant de problemen opzettelijk veroorzaakt.

Dat fabrikanten wel vaker verborgen functionaliteiten inbouwen maakt het niet zomaar acceptabel voor het gebruik. Zeker als de fabrikant kan weten dat met de apparatuur belangrijke gegevens zoals persoonlijke gegevens verwerkt zullen worden en de eindgebruikers die niet zomaar genoeg kunnen beschermen als de fabrikant verborgen toegang mogelijk maakt en daar zelf geen verantwoordelijkheid over wenst af te leggen.

Ik ben het er mee eens dat beschermen tegen fysieke toegang belangrijk is om te voorkomen dat malware de functionaliteit van de apparatuur makkelijker kan gebruiken. Maar risico's zijn al jaren niet pas onaanvaardbaar als iemand malware weet te installeren. Wettelijk trekken we de grens al langere tijd bij inzichtelijk moeten hebben wat apparatuur precies als functionaliteiten heeft. En dus dat fabrikanten niets achter horen te houden aan informatie over risico's.

[Reactie gewijzigd door kodak op 10 maart 2025 19:02]

[AJediIAm]

De fabrikant heeft aangegeven dat de functies bestaan maar niet aangegeven wat de functies doen. Daar is dus geen onduidelijkheid over.
Het gaat om debugging functies die het OS kan gebruiken om connectiviteit te debuggen. Dus geen extra risico voor de gebruikers.

[Reactie gewijzigd door AJediIAm op 10 maart 2025 18:33]

[kodak]

Functies met onbekende werking zijn onduidelijk en dus stuk voor stuk een risico. Daarbij zijn dat soort functies, zoals debug functies, vaak ook zeer slecht beveiligd. Beiden horen niet omdat de kopers en verantwoordelijken verantwoordelijkheid hebben nadat het verkocht is.

De fabrikant toont op geen enkele manier zich te interesseren in die risico's en verantwoordelijkheden. Het opzettelijk zo min mogelijk uitleggen welke functionaliteiten er allemaal nog meer zijn, ze niet documenteren, geen inzicht geven in de precieze werking, geen inzicht geven in (het gebrek aan) beveiliging er van, geen risico's erkennen, is geen deugdelijke levering. Dat is eerder het opettelijk verantwoordelijkheid afschuiven.

[AJediIAm]

I rest my case: nieuws: Tarlogic trekt beschuldiging van backdoor in ESP32-chip in

[kodak]

Dat gaat alleen om de beschuldiging dat het als backdoor bedoeld zou zijn. De risico's zijn er niet minder om en de opmerkingen daarover zijn daarmee ook duidelijk niet door ze ingetrokken.

[Z80]

Alleen komt dit nooit op tweakers. Op hackaday komt dit wel ter spraken.
Voor oude cpu's komt het nog wel eens voor dat er iemand in duikt.
Voor de 8086 bijvoorbeeld.
https://www.righto.com/20...ed-8086-instructions.html

En ook in de "x86 Instruction Set" zitten ongedocumenteerde instructies.
YouTube: Breaking the x86 Instruction Set

[MSalters]

De x86 instructieset bestaat niet. Een video die dat suggereert vertelt vooral hoe clueless de maker is.

Dat is al vanaf het allereerste moment het geval: de 8086 en 80286 zijn allebei x86 maar hebben niet dezelde ISA. Linux had al heel snel "386" en "386+CMOV" builds, waar zelfs één instructie verschil al significant was.

[MSalters]

Ongeveer elke Intel CPU heeft ongedocumenteerde opcodes. "Wel eens" is een understatement.

Het hele punt is dat je met root c.q. administrator rechten toch al alles kunt, gewoon met de gedocumenteerde opcodes.

[AJediIAm]

Dat is omdat het eigenlijk ook geen probleem is. Het is een ongedocumenteerde feature die malafide software die op de chip draait kan misbruiken. Je moet dus eerst die malafide software op de chip krijgen. Als dat lukt stelt deze "kwetsbaarheid" in vergelijking niks voor.

[Bor]

Dat is omdat het eigenlijk ook geen probleem is. Het is een ongedocumenteerde feature die malafide software die op de chip draait kan misbruiken.

Kortom een vulnerability die er niet in had moeten zitten. "Undocumented feature" zou je zelfs als potentieel opzettelijke backdoor kunnen bestempelen.

[AJediIAm]

Het is een debugging feature. Geen vulnerabilities. Het zet er "by design" en wordt blijkbaar door de fabrikant genoemd, maar er wordt geen beschrijving gegeven omdat het niet voor gebruikers is.

Veel media sites zijn het al aan het nuanceren van "backdoor" naar "undocumented commands" zoals van (oude link)
https://www.bleepingcompu...sed-by-a-billion-devices/
Naar (nieuwe link)
https://www.bleepingcompu...sed-by-a-billion-devices/

Goed om te zien dan sommige media het nuanceren naarmate de details bekend worden en het een storm in een glas water blijkt te zijn...

[Bor]

On gedocumenteerde features die het mogelijk maken zaken te doen die andere niet op die manier kunnen zijn soort vulnerability. Wie weet hoe lang hier al gebruik / misbruik van wordt gemaakt?

[Reactie gewijzigd door Bor op 9 maart 2025 19:53]

[sympa]

Zo'n chip moet z'n macadres kunnen aanpassen. Voor privacy, maar ook omdat alle devices een verschillend macadres hebben en dat adres niet in de wifihardware zit maar ergens anders, in flash of zo.
Dus daar is een instructie voor.
En dat die instructie niet gedocumenteerd is verandert daar toch niks aan?

[dasiro]

er zijn ook veel meer mensen die weten dat er in hun toestel een Intel CPU zit en die de moeite zouden doen om zulk een artikel te lezen.

[laurxp]

It rather involved being on the other side of this airtight hatchway.

It’s like saying that somebody’s home windows are insecure because a burglar could get into the house by merely unlocking and opening the windows from the inside. (But if the burglar has to get inside in order to unlock the windows…)

[keroner]

Denk dat miljoenen wel miljarden is.
Nou ja, zeker wel 1 miljard schat ik zo.

[Reactie gewijzigd door keroner op 9 maart 2025 11:52]

[DrPoncho]

Je zou gelijk kunnen hebben, al is het hun eigen bron:

https://www.espressif.com/en/news/1_Billion_Chip_Sales

[Sleurhutje]

Denk ik te simpel of is MAC adres spoofen niet gewoon onderdeel van de API? Je kunt de MAC adressen van de WiFi en BT aanpassen voordat je de interfaces activeert zodat ze een ander MAC adres hebben.
https://docs.espressif.co...stem_api.html#mac-address

Risico zit vooral in IoT devices die bijvoorbeeld OTA gebruiken voor updates. Maar die vormen sowieso een risico, ongeacht deze vermeende kwetsbaarheid.

[computer1_up]

Ten eerste… fysieke toegang is vereist. In mijn optiek betekent het hebben van fysieke toegang als aanvaller dat het apparaat dan altijd per definitie gecompromitteerd is. Want hardeare kwetsbaarheid of niet, er zijn dan nog genoeg andere mogelijkheden, zei het gebrekkige software, een fysieke admin interface waar je bij kunt, of wat dan ook…

Daarnaast: ja leuk dat het “ESP-32’s” betreft. Maaruh, welke dan precies? Een ESP32 WROVER is niet exact hetzelfde als een ESP32 WROOM, of S2, of C3 etc. Sommige ESP32 varianten hebben compleet andere cores en architectuur dan andere. Beetje als een krantenkop: “auto’s van het merk BMW vatten spontaan vlam bij gebruik van onjuiste benzine”. Oudere BMW varianten? Moderne BMW’s? Elektrische BMW’s (die uiteraard dan geen benzine gebruiken in de eerste plaats)?

[Shirenzo]

MWhahahhaha, als je toegang tot de ESP32 heb dan kan je zowiezo al alles doen wat je wilt, Zo is die chip ontworpen.

Geld trouwens voor alle Linux bestuurde componenten, als je bij de disk bent kan je wachtwoorden aanpassen bij een reboot.

[fastedje]

Niet helemaal: met disk encryption wens ik je daarbij veel success, tenzij je een zwak password gebruikt voor de encryptie.

[Shirenzo]

Voor een ESP32 niet, de GPIO zorgen er voor dat je mega veel kan doen, de ESP32 is niet krachtig genoeg om een stoppende encryptie toe te passen.

[Mijzelf]

Met deze opcodes krijgt de software die op het apparaat draait meer privileges.

Het is een microcontroller. Heeft die ook maar enige geheugen- of andere protectie?

[laurxp]

Het is 2025, zulke features zijn nou niet bepaald zeldzaam meer onder microcontrollers. Zelfs een €1 chip als de RP2350 heeft ondersteuning voor dingen als ARM TrustZone (verdeling in secure en non-secure code).

De ESP32 loopt op dit vlak nog wat achter, maar dat is de uitzondering en niet de regel.

[Z80]

De ESP32 is uit 2016. Toen was beveiliging op hardware niveau nog niet echt een ding. En helemaal niet bij een hardware van een paar Euro. Tijden zijn veranderd. Rekenkracht is verveelvoudigt. En de prijzen gekelderd.

[jeroen3]

Ja, de meeste hebben twee trust levels. Waarin alleen het os in privileged draait. De rest van de code kan dan niet overal bij. Maar er is meestal geen virtual memory die inter-thread lekken van voorkomen.

Wat vaak wel kan is stukken geheugen non-executable markeren. Zodat zelfs als iemand er malafide code in kan krijgen, deze niet kan uitvoeren.
Maar dat moet allemaal wel juist worden toegepast, en daar zal het vaak missen.