Gesucht und gefunden: Sicherheitslücke in Zyxel Router

Martin Wrona

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.

Als Security-Team sind wir stets bestrebt, die neuesten Technologien und Angebote unseres Unternehmens auf Herz und Nieren zu prüfen. Als wir von unserem Internetangebot erfahren haben, war für unseren Teamleiter Thomas Houiellebecq sofort klar, dass wir dieser Umsetzung besondere Aufmerksamkeit schenken sollten, um etwaige Sicherheitsrisiken frühzeitig zu identifizieren. Das ist wichtig für uns, da wir dadurch direkt die Sicherheit unserer Kunden beeinflussen können.

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.

ONEKEY ist eine Sicherheitsplattform für IoT-Geräte, die sich auf die automatisierte Analyse von IoT-Firmware spezialisiert hat. Ein zentraler Bestandteil der Plattform ist die Firmware-Binäranalyse, welche die Firmware entpackt, alle Assemblies klassifiziert, identifiziert und optional dekompiliert und anschliessend den Code auf potenzielle Sicherheitslücken prüft. Die automatisierten Prozesse der Plattform ermöglichen eine schnelle Identifikation von potentiellen Sicherheitsrisiken.

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.

Zur genaueren Analyse und Verifizierung der Erkennungen habe ich die entsprechende Library aus der Firmware in Ghidra geladen, einem Open Source Reverse-Engineering-Tool der NSA. In der Ansicht des dekompilierten Codes sehen wir eine Funktion, die ein mailsend command mit Daten aus einem JSON zusammenbaut und anschliessend ausführt. Das Finding sieht vielversprechend aus, weil Daten wie Absender- und Empfänger-Email mit hoher Wahrscheinlichkeit Benutzereingaben sein sollten.

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.

1. Client generiert einen random AES Key
2. Client holt sich einen Public Key über den Endpunkt /getRSAPublickKey
3. Client sendet während des Logins den generierten AES Key verschlüsselt mit dem Public Key des Routers
4. 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.

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.ch

Diese Beiträge könnten dich auch interessieren