Hinter den Kulissen
Lego und iPhone: Danach sucht die Kundschaft am häufigsten
von Manuel Wenk
Gesucht und gefunden: Sicherheitslücke in Zyxel Router
14.4.2025
Im Zuge der Vorbereitung auf die Einführung unseres Internetangebots haben wir als Security Team von Digitec Galaxus den von uns ausgelieferten Zyxel Router etwas genauer angeschaut. Während der Analyse des Routers stiessen wir schliesslich auf eine bis anhin unbekannte Schwachstelle (CVE-2024-12010) über die ich diesen Bericht schreibe.
Es dauerte nicht lange, bis wir vom verantwortlichen Projektteam einen der vorgesehen Zyxel Router erhielten und mit unserer Analyse beginnen konnten. Da wir von Zyxel eine personalisierte Firmware erhalten, wollten wir speziell den für uns angepassten Teil prüfen und anschliessend noch oberflächlich den Basisteil, der von allen Zyxel Kunden genutzt wird.
Zu unserem Erstaunen sind alle POST Payloads und Responses verschlüsselt, was es für uns unglaublich aufwändig macht, einen Überblick zu verschaffen. Im ersten Moment bin ich davon ausgegangen, dass dies den Reverse-Engineering-Prozess aufwändiger machen soll, aber dazu später mehr. Zu diesem Zeitpunkt haben wir uns dazu entschlossen einen anderen Ansatz zu verfolgen.
Firmware Analyse
Glücklicherweise haben wir die unverschlüsselte Firmware die auf dem Gerät läuft und können diese auseinandernehmen. Da wir nicht alltäglich IoT / Closed Source Projekte analysieren hat Thomas einen Kollegen bei ONEKEY angefragt um einen PoC auf ihrer Platform durchzuführen.
Nachdem die Firmware durch die Platform analysiert wurde, hatten wir eine Liste von Punkten, die wir genauer anschauen wollten.
Auf den ersten Blick haben wir einige potenzielle Schwachstellen, die es wert sind, genauer untersucht zu werden. Bei einer tiefergehenden Analyse zeigt sich jedoch, dass die meisten dieser Schwachstellen entweder nicht direkt zugänglich sind oder keine Benutzereingaben verarbeitet werden, die es ermöglichen würde die Schwachstelle auszunutzen. Dies bedeutet, dass die reale Bedrohung dieser Schwachstellen geringer ist, als es auf den ersten Blick erscheint.
Das spannendste Finding auf das ich hier genauer eingehe, wurde von der Platform als “Command Injection“ erkannt.
Exploit
Wir haben also eine verwundbare Aktion für die wir herausfinden müssen ob diese mit Benutzereingaben erreichbar ist und wie diese aufgerufen werden kann. Nach kurzer Suche wurde ich in den Log-Einstellungen fündig. Diese erlauben in regelmässigen Intervallen Syslogs an eine bestimmte E-Mail zu senden.
Um die Funktion auszunutzen, muss unser Payload einen Command innerhalb des eigentlichen Commands ausführen. Weitere Informationen zu Command Injection auf HackTricks
Das Admin-Panel hat uns jedoch keine Sonderzeichen eingeben lassen, die wir für unseren Angriff benötigten. Was wäre wenn es sich dabei nur um eine Client-Side Validierung handelt?
Um Requests zum Backend manipulieren zu können, mussten wir erstmal die Client-Side Verschlüsselung umgehen. Dazu habe ich im Chrome-Debugger einen Breakpoint in der entsprechenden Javascript AES-Verschlüsselungsfunktion gesetzt und konnte anschliessend über die Konsole den Wert vor der Verschlüsselung anpassen. Danach wurde der Programmfluss fortgesetzt und die manipulierte Anfrage an den Server übermittelt.
Das Resultat der manipulierten Anfrage sah wie folgt aus. Wie wir sehen handelte es sich bei der Sonderzeichenvalidierung lediglich um eine clientseitige Prüfung, die wir erfolgreich umgangen haben.
Die Konfiguration der Email Einstellungen war vorbereitet und wir mussten die Funktion auslösen damit unser Payload ausgeführt wird. Dazu verwendeten wir die Log Funktion “E-mail Log Now“.
Nachdem wir die Funktionalität der Command Injection verifiziert haben habe ich in Python einen einfachen Proof of Concept gebaut, welcher den vollständigen Ablauf automatisiert.
Während dieser Umsetzung musste ich die clientseitige Verschlüsselung nachbauen und habe folgenden Ablauf nachgestellt.
- Client generiert einen random AES Key
- Client holt sich einen Public Key über den Endpunkt
/getRSAPublickKey - Client sendet während des Logins den generierten AES Key verschlüsselt mit dem Public Key des Routers
- Client verschlüsselt bzw. entschlüsselt alle nachfolgenden Requests / Responses mit dem AES Key
Dieser Prozess ähnelt einer vereinfachten Implementierung von TLS. Die Geräte werden möglicherweise ohne oder wie bei uns mit einem selbstsignierten Zertifikat ausgeliefert, was darauf schliessen lässt, dass diese Methode als zusätzliche Schutzmassnahme gegen Man-in-the-Middle-Angriffe gedacht ist.
PoC Exploit
Wir haben Zyxel das Script zugesendet und ihr Security Team konnte das Problem in ihrer Standard Firmware reproduzieren.
Timeline:
Nov 25, 2024 Report
Nov 29, 2024 Review / Repro
Dez 10, 2024 CVE assigned
Dez 12, 2024 Fix Released
Mär 11, 2025 Public Advisory
Betroffene Geräte:
42 Geräte, von DSL/Ethernet CPE, Fiber ONT bis Wi-Fi extender. Siehe Zyxel Advisory
Wusstest du, dass wir bei Digitec Galaxus ein Vulnerability Disclosure Program haben? Ethical Hackers können unter Einhaltung der Regeln auch bei uns nach Sicherheitslücken suchen. Weitere Informationen dazu gibt es auf unserer Security Seite.
Martin Wrona
Senior Security Software Engineer
Martin.Wrona@digitecgalaxus.chHinter den Kulissen
Neuigkeiten zu Features im Shop, Infos aus dem Marketing oder der Logistik und vieles mehr.
Alle anzeigen
