Tarlogic trekt beschuldiging van backdoor in ESP32-chip in

Het Spaanse securitybedrijf Tarlogic komt terug op zijn eerdere bewering dat de veelgebruikte ESP32-chip een backdoor zou bevatten. In plaats daarvan spreekt het bedrijf nu over een 'hidden feature'. Espressif heeft inmiddels beloofd een software-update uit te brengen.

In een bijgewerkte versie van zijn oorspronkelijke artikel stelt Tarlogic: "We willen verduidelijken dat het gepaster is om te verwijzen naar de aanwezigheid van bedrijfseigen HCI-commando's, waarmee bewerkingen zoals het lezen en wijzigen van het geheugen in de ESP32-controller mogelijk zijn, als een ‘hidden feature' in plaats van een ‘backdoor’." Het bedrijf belooft binnenkort meer informatie vrij te geven.

De kwestie draait om niet-gedocumenteerde commando's in de ESP32-chip, een populaire chip die bluetooth- en wificonnectiviteit verzorgt in iot-apparaten. De ontdekte functionaliteit werd vorige week gepubliceerd door de onderzoekers en heeft de aanduiding CVE-2025-27840 gekregen. Via deze verborgen instructies zou het voor kwaadwillenden dus onder andere mogelijk zijn om aanpassingen te maken in het geheugen.

Volgens de onderzoekers was het onder meer mogelijk om het macadres van vertrouwde apparaten te spoofen, het geheugen te modificeren en packet injections uit te voeren. 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 de verborgen instructies te activeren is echter directe, fysieke toegang tot het apparaat vereist, wat het risico op grootschalig misbruik aanzienlijk verkleint.

Inmiddels heeft fabrikant Espressif gereageerd op de kwestie. Het bedrijf zegt dat het gaat om debugcommando's die zijn opgenomen voor testdoeleinden binnen de bluetoothstack. "Deze commando's zijn bedoeld voor gebruik door ontwikkelaars en zijn niet op afstand toegankelijk”, stelt Espressif in een verklaring. Het bedrijf zegt dat de commando's geen risico vormen voor het op afstand compromitteren van ESP32-apparaten. Espressif geeft daarnaast aan dat alleen de originele ESP32-chips getroffen zijn. Het bedrijf belooft een software-update uit te brengen om de ongedocumenteerde commando's te verwijderen.

Reacties (27)

[Hobbit13]

“He, we hebben een hidden feature gevonden! Zullen we die publiceren?”
“Ja, noem het maar een backdoor, anders pikt niemand het op, en missen we PR”….

[svennd]

Het probleem van vele security onderzoekers is dat ze gewoon domweg genegeerd worden. Je stuurt een mailtje, belt, ... doe maar gelijk wat. Als je al niet zelf (legaal) aangevallen wordt.

Dus noem het gerust PR, het is nodig om serieus genomen te worden en om reactie te krijgen. Overigens blijft de CVE wel, enkel de "beschuldiging" valt weg omdat het over een fout zou gaan en niet kwalijke bedoelingen.

[kodak]

De term is aangepast omdat het geen kwade bedoelingen zou hebben van de fabrikant.

Het is niet alsof het geen beveiligingsrisico's zijn en dit soort verborgen 'features' maar behoorlijk zijn. Eerder juist niet. Omdat de fabrikant er geen duidelijke verantwoordelijkheid voor neemt om problemen te voorkomen. Door de kopers er opzettelijk geen duidelijkheid over te geven wat nog meer gebruikt kan worden, geen duidelijkheid te geven hoe goed of slecht die features beveiliging hebben, door geen moeite te doen de features te documenteren en juist liever verborgen te houden alsof ze geen risico vormen en dat de kopers niets aan gaat. Geen behoorlijke ontwikkelaar laat debugfunctionaliteit zonder enige inhoudelijke verduidelijking in productiesoftware en apparatuur bestaan zonder openlijk verantwoordelijkheid te nemen of de klant te informeren. Doet een fabrikant of ontwikkelaar dat wel verborgen dan zijn ze op zijn minst bezig onbehoorlijke verantwoordelijkheid af te schuiven en de verplichtingen en belangen van de kopers en gebruikers niet serieus te nemen. Dat dit niet nieuw is is al jaren duidelijk. Dat is waarom het al snel neer komt dat dit backdoors genoemd kunnen worden.

[Lord Anubis]

Sorry, maar dit betoog is stemmingmakerij net zoals het Spaanse bedrijf.
Geen duidelijke verantwoordelijkheid nemen voor iets wat nodig is tijdens ontwikkeling? Dit soort mogelijkheden zitten ook in andere chips zoals Raspberry Pico’s chips.

[kodak]

Het feit dat veel fabrikanten dit doen doet er niets aan af dat het risico's geeft die niet meer van deze tijd zijn. Het is geen stemmingmakerij dat de eisen hoger liggen en wetgeving strenger is geworden dan wat jaren geleden gebruikelijk was. Het is misschien confronterend dat die fabrikanten het liever normaal vinden om dit soort functies niet bekend te maken, er niets over te documenteren en gebruikers maar vertrouwen moeten hebben dat dit functies niet misbruikt kunnen worden als de firmware weer eens gebreken heeft, maar dat is juist het hele punt. Men trekt zich er nog steeds nauwelijks iets van aan dat je maar beter of heel duidelijk kan zijn welke functionaliteiten er zijn of gewoon geen verborgen functionaliteiten mee te leveren.

[Lord Anubis]

Je schuift het probleem naar de fabrikant en je haalt FW, chip functies en opcode door elkaar. En wat heeft wetgeving hier mee te maken?

[kodak]

De fabrikant heeft de verantwoordelijkheid omdat die kiest de features te verbergen en de risico's op de gebruikers afschuift.

De firmware is geen verwarring. Een lek in firmware, waar de criminele bijvoorbeeld draadloos bij kunnen, geeft regelmatig mogelijkheden om de hardware features te gebruiken. En dus ook verborgen features. Het idee dat hardware features alleen via fysieke toegang te gebruiken was al achterhaald toen we massaal draadloos gingen communiceren van chip naar chip.

De wetgeving is steeds strenger aan het worden. Zeker in verantwoordelijkheid. Als je als fabrikanten features gaat verbergen doe je dat niet om de kopers en gebruikers weet te laten hebben welke risico's er zijn en deze goed in te kunnen schatten.

[indigo79]

Heb jij al ooit op een embedded systeem ontwikkeld? En dan bedoel ik geen RPi of ander linux systeem zonder scherm dat je via SSH moet benaderen, maar een echt embedded systeem zoals dit, waarbij je een JTAG of vergelijkbaar device gebruikt om te debuggen.

Zowel Tarlogic als Espressif geven aan dat fysieke toegang tot het device noodzakelijk is om deze commando's te kunnen aanroepen. Voor dit soort devices betekent dat effectief een debugging device connecteren met de processor of microcontroller. Niemand heeft tot nu toe zelfs maar gesuggereerd, laat staan aangetoond, dat die functies op een of andere manier misschien remote toegankelijk kunnen zijn. Met dergelijke toegang kan je dergelijke devices sowieso exact laten doen wat je wil, inclusief alle bovengenoemde risico's.

Dat is wat Tasmota bijvoorbeeld (ten goede) doet om ESP32-gebaseerde home automation devices van een custom open firmware te voorzien, gewoon zonder die commando's. Met die debug commando's is het misschien iets eenvoudiger om bepaalde dingen te doen, maar als iemand op dat niveau toegang heeft tot je device, heb je sowieso een probleem.

[kodak]

Er staat geen enkele uitsluiting bij dat deze features niet via bijvoorbeeld lekke firmware van de draadloze interfaces te gebruiken is. En het zal niet voor het eerst zijn als dat kan terwijl fabrikanten en ontwikkelaars dachten dat die features met hun firmware wel veilig genoeg beschermd waren.

[tedades]

Daarnaast is het normaal dat er in chips debug commando's zitten voor het uitvoeren van testen. Zo zullen er ook test functionaliteit in de fysieke hardware zitten. Dat kan inderdaad in sommige gevallen tot een security issue leiden maar meestal niet, zo is de chip eenmaal ontworpen.
Alle 'hidden' features als backdoor adverteren klopt inderdaad niet.

[Ghandi]

Misschien een heel rare vraag, maar hoe wordt het MAC adres gezet bij productie? Zijn dit niet commando's die nodig zijn voor de allereerste initialisatie van de chip, want je wilt natuurlijk een geteste chip hebben met een uniek Mac adres (op netwerk en bluetooth).

[Kalix]

Het MAC adres wordt bij chips in permanent geheugen geschreven tijdens het productieproces.

[Hobbit13]

Ja, maar het "spoofen" van een ander addres is onderdeel van de standaard functionaliteit van de ESP32. Je kan gewoon
esp_base_mac_addr_set(Nieuw_MAC)
uitvoeren, en het MAC address is veranderd. Dit moet je wel bij elke reboot opnieuw doen, je kan het adres niet permanent aanpassen via deze methode.

[sympa]

Dat staat "permanent" in flash of EEPROM, voor zover ik weet. Misschien heeft die ESP32 nog een eigen stukje opslag ervoor en zet de fabrikant het er in. Dat maakt het namelijk wel makkelijker voor de bordjesmaker.
Maar ga er maar van uit dat het niet in de wifihardware zelf zit. En dat een driver het moet kopiëren van een ROM naar de wifihardware.

[DeCo]

Een MAC adres bestaat uit twee delen. Het eerste deel wordt toegekend aan de fabrikant door IEEE en het tweede deel wordt door de fabrikant gegenereerd. Op die manier is een MAC adres altijd uniek in elk netwerk.

[armageddon_2k1]

Ja dat was ook wel een aanfluiting. Een clickbait security post de wereld insturen als verkapte marketing truuk. En na de ophef de titel en de content van de post aanpassen en doen alsof je neus bloed.

Dat bedrijf heeft zichzelf zulke schade aangedaan.

[Reactie gewijzigd door armageddon_2k1 op 11 maart 2025 09:59]

[jaspermeul]

De content passen ze in de toekomst ook alvast aan, of ze weten niet welk datumformat ze willen gebruiken.
Uit hun eigen artikel:

03/09/2025 Update:
We would like to clarify that it is more appropriate to refer to the presence of proprietary HCI commands—which allow operations such as reading and modifying memory in the ESP32 controller—as a “hidden feature” rather than a “backdoor.”
The use of these commands could facilitate supply chain attacks, the concealment of backdoors in the chipset, or the execution of more sophisticated attacks. Over the coming weeks, we will publish further technical details on this matter.

10/09/2025 Update:
Technical details and content of the Bluetooth hacking talk published in the blog article.

[Reactie gewijzigd door jaspermeul op 11 maart 2025 10:04]

[Scribe]

10/09/2025?

[marinostrus]

Kijk helemaal onderaan het bronartikel:

https://www.tarlogic.com/...2-chip-infect-ot-devices/

Dat staat er gewoon zo.

[Scribe]

Was ook niet vervelend bedoeld richting jou. Ga er van uit dat ze 03/10/2025 bedoelde

[marinostrus]

Ik had je ook geen -1 of 0 gegeven hoor . Ik antwoorde gewoon op de "10/09/2025?" waar die vandaan kwam.

Het komt gewoon allemaal heel slordig/amateuristisch over van het bedrijf!

[et36s]

Interessant mijn HiFi Rose RA280 versterker heeft ook zo'n chip. Vroeg me al af waar 'expressif' voor stond in mijn ubiquiti dashboard. Benieuwd naar de 'hidden feature' vanavond maar even in een aparte vlan indelen.

[Reactie gewijzigd door et36s op 11 maart 2025 13:25]

[cyclone]

Benieuwd naar de 'hidden feature' vanavond maar even in een aparte vlan indelen.

Niet nodig, zoals terug te lezen in dit artikel zijn de non documented commands niet remote uit te voeren maar enkel als je fysieke toegang hebt tot het device (tot de HCI interface om exact te zijn en dat betekend dus letterlijk dat je iets op de chip moet aansluiten / solderen).

Tis allemaal nogal een storm in een glas water maar omdat deze chips wijdverspreid zijn is het nieuws met veel bombarie opgepakt.

[Reactie gewijzigd door cyclone op 11 maart 2025 13:35]

[svenk91]

De meeste producten met ESP32 komen sowieso niet met secureboot geactiveerd. Als je fysieke toegang hebt kan je toch vrijwel altijd al doen wat je wilt met die chips. Het wordt pas interessant als dit ook draadloos lukt, via bluetooth of wifi.

[markg85]

En terecht! Nou die CVE organisatie die hier een 6.8 aan gaf ook is onder de loep nemen. Dat is een bizar hoge "hype" score die nergens op slaat.

[darkfader]

Waarschijnlijk Tarlogic zelf.
ChatGPT geeft "Given these changes, the new CVSS score would likely be around 4.5 to 5.3 (Medium) instead of 6.8." als ik vraag opnieuw te evalueren :3 Ik ben benieuwd.

[markg85]

Waarschijnlijk Tarlogic zelf.
ChatGPT geeft "Given these changes, the new CVSS score would likely be around 4.5 to 5.3 (Medium) instead of 6.8." als ik vraag opnieuw te evalueren :3 Ik ben benieuwd.

CVE staat voor:

Common Vulnerabilities and Exposures.

Het is geen lek, geen exploit. Niets. Het is bagger beveiligingsonderzoek van mensen die "dachten" even lekker te kunnen scoren. Die hele CVE zou teruggetrokken moeten worden.

Daarbij is dit ook 1 van de criteria van de CVE:

Is a proven risk
The vulnerability is submitted with evidence of security impact that violates the security policies of the vendor.

Oftewel, CVE zelf of wie die organisatie ook beheert en CVE nummers uitdeelt, heeft hier ook wel wat uit te leggen.

[Reactie gewijzigd door markg85 op 12 maart 2025 14:21]