Achter de schermen
Lego en iPhone: waar klanten het vaakst naar zoeken
van Manuel Wenk
Gezocht en gevonden: Kwetsbaarheid in Zyxel router
14-4-2025
Vertaling: machinaal vertaald
Als onderdeel van de voorbereidingen voor de lancering van ons internetaanbod, nam het Digitec Galaxus beveiligingsteam de door ons geleverde Zyxel router onder de loep. Tijdens het analyseren van de router stuitten we uiteindelijk op een voorheen onbekende kwetsbaarheid (CVE-2024-12010) waarover ik dit rapport schrijf.
Als beveiligingsteam proberen we altijd de nieuwste technologieën en producten in de sale van ons bedrijf te testen. Toen we ons internetaanbod leerden kennen, was het voor onze teamleider Thomas Houiellebecq meteen duidelijk dat we bijzondere aandacht aan deze implementatie moesten besteden om eventuele beveiligingsrisico's in een vroeg stadium te kunnen identificeren. Dit is belangrijk voor ons, omdat we zo direct invloed kunnen uitoefenen op de veiligheid van onze klanten.
Het duurde niet lang voordat we een van de Zyxel-routers ontvingen van het verantwoordelijke projectteam en konden beginnen met onze analyse. Omdat we gepersonaliseerde firmware van Zyxel ontvangen, wilden we specifiek het deel testen dat voor ons op maat was gemaakt en daarna oppervlakkig het basisdeel testen dat door alle klanten van Zyxel wordt gebruikt.
Admin interface
Onze eerste stap in het auditproces is een overzicht krijgen van hoe de router is opgebouwd en welke functionaliteiten in de sale zijn. Om dit te doen, starten we Burp Suite, een populaire tool voor het registreren en manipuleren van webverkeer. We gebruiken het om alle routes te verzamelen en ze vervolgens afzonderlijk te controleren.
Tot onze verbazing zijn alle POST payloads en antwoorden versleuteld, wat het voor ons ongelooflijk tijdrovend maakt om een overzicht te krijgen. In eerste instantie nam ik aan dat dit was om het reverse engineering proces complexer te maken, maar daarover later meer. Op dat moment besloten we het anders aan te pakken.
Firmware analyse
Gelukkig hebben we de onversleutelde firmware op het apparaat staan en kunnen we het uit elkaar halen. Omdat we niet elke dag IoT / closed source projecten analyseren, vroeg Thomas een collega bij ONEKEY om een PoC uit te voeren op hun platform
ONEKEY is een beveiligingsplatform voor IoT-apparaten dat gespecialiseerd is in de geautomatiseerde analyse van IoT-firmware. Een centraal onderdeel van het platform is de binaire analyse van de firmware, die de firmware uitpakt, alle assemblages classificeert, identificeert en optioneel decompileert en vervolgens de code controleert op potentiële beveiligingslekken. Dankzij de geautomatiseerde processen van het platform kunnen potentiële beveiligingsrisico's snel worden geïdentificeerd.
Nadat de firmware door het platform was geanalyseerd, hadden we een lijst met punten die we nader wilden bekijken.
Op het eerste gezicht hebben we een aantal potentiële kwetsbaarheden die het waard zijn om verder te onderzoeken. Een diepere analyse laat echter zien dat de meeste van deze kwetsbaarheden niet direct toegankelijk zijn of dat er geen gebruikersinvoer wordt verwerkt waarmee de kwetsbaarheid zou kunnen worden uitgebuit. Dit betekent dat de werkelijke dreiging van deze kwetsbaarheden kleiner is dan op het eerste gezicht lijkt.
De meest opwindende bevinding, die ik hier in meer detail zal bespreken, werd door het platform herkend als een "command injection".
Om de detecties in meer detail te analyseren en te verifiëren, laadde ik de corresponderende bibliotheek van de firmware in Ghidra, een open source reverse engineering tool van de NSA. In de weergave van de gedecompileerde code zien we een functie die een mailsend commando samenstelt met gegevens uit een JSON en deze vervolgens uitvoert. De bevinding ziet er veelbelovend uit, omdat gegevens zoals e-mails van afzender en ontvanger hoogstwaarschijnlijk door de gebruiker moeten worden ingevoerd.
Exploit
Dus we hebben een kwetsbare actie waarvan we moeten uitzoeken of deze toegankelijk is met gebruikersinvoer en hoe deze kan worden aangeroepen. Na even zoeken vond ik wat ik zocht in de loginstellingen. Deze maken het mogelijk om syslogs met regelmatige tussenpozen naar een specifieke e-mail te sturen.
Om de functie te gebruiken, moet onze payload een commando uitvoeren binnen het eigenlijke commando. Meer informatie over opdrachtinjectie is te vinden op HackTricks
Het beheerderspaneel liet ons echter geen speciale tekens invoeren die we nodig hadden voor onze aanval. Wat als dit gewoon een validatie aan de clientzijde was?
Om verzoeken naar de backend te kunnen manipuleren, moesten we eerst de versleuteling aan de clientside omzeilen. Om dit te doen, zette ik een breekpunt in de corresponderende JavaScript AES encryptie functie in de Chrome debugger en was toen in staat om de waarde voor encryptie aan te passen via de console. De programmastroom ging daarna verder en het gemanipuleerde verzoek werd naar de server gestuurd.
Het resultaat van het gemanipuleerde verzoek zag er als volgt uit. Zoals we kunnen zien, was de validatie van de speciale tekens slechts een controle aan de kant van de client, die we met succes hebben omzeild.
De configuratie van de e-mailinstellingen was voorbereid en we moesten de functie triggeren om onze payload uit te voeren. Hiervoor gebruikten we de logfunctie "E-mail Log Now".
Nadat we de functionaliteit van de commando-injectie hadden geverifieerd, bouwde ik een eenvoudig proof of concept in Python, dat het hele proces automatiseert.
Tijdens deze implementatie moest ik de client-side encryptie opnieuw bouwen en het volgende proces opnieuw maken
- Client genereert een willekeurige AES sleutel
- Client vraagt een publieke sleutel op via het eindpunt
/getRSAPublickKey - De client verzendt de gegenereerde AES-sleutel versleuteld met de openbare sleutel van de router tijdens het inloggen
- Client versleutelt of ontsleutelt alle volgende verzoeken/antwoorden met de AES-sleutel
Dit proces is vergelijkbaar met een vereenvoudigde implementatie van TLS. De apparaten kunnen worden geleverd zonder een zelfondertekend certificaat of, zoals in ons geval, met een zelfondertekend certificaat, wat suggereert dat deze methode bedoeld is als een extra beschermende maatregel tegen man-in-the-middle aanvallen.
PoC exploit
We stuurden het script naar Zyxel en hun beveiligingsteam kon het probleem reproduceren in hun standaard firmware.
Tijdlijn:
Nov 25, 2024 Rapport
29 nov 2024 Review / Repro
10 dec 2024 CVE toegewezen
12 dec 2024 Fix vrijgegeven
11 mrt 2025 Public Advisory
Betrokken apparaten:
42 apparaten, van DSL/Ethernet CPE, glasvezel ONT tot Wi-Fi extender.
Conclusie
Het Zyxel Security Team heeft de gemelde kwetsbaarheden met hoge prioriteit behandeld en doorgestuurd naar de verantwoordelijke productgroep. De samenwerking was professioneel en dankzij het proof of concept dat ik had geleverd, werd er snel een patch ontwikkeld en gedistribueerd naar klanten. Het ONEKEY platform stelde ons in staat om snel een uitgebreid overzicht te krijgen van de getroffen firmware, wat het hele proces aanzienlijk versnelde.
Wist je dat we bij Digitec Galaxus een Vulnerability Disclosure Programma hebben? Ook ethische hackers kunnen bij ons volgens de regels op zoek gaan naar beveiligingslekken. Meer informatie hierover vind je op onze beveiligingspagina.
Martin Wrona
Senior Security Software Engineer
Martin.Wrona@digitecgalaxus.ch
2 opmerkingen
later