Cercato e trovato: Vulnerabilità nel router Zyxel

Martin Wrona

14/4/2025

Traduzione: tradotto automaticamente

Nell'ambito dei preparativi per il lancio della nostra offerta Internet, il team di sicurezza di Digitec Galaxus ha esaminato più da vicino il router Zyxel che abbiamo fornito. Durante l'analisi del router, ci siamo imbattuti in una vulnerabilità precedentemente sconosciuta (CVE-2024-12010) di cui sto scrivendo questo rapporto.

Come team di sicurezza, cerchiamo sempre di mettere alla prova le ultime tecnologie e offerte della nostra azienda. Quando abbiamo scoperto la nostra offerta internet, il nostro team leader Thomas Houiellebecq ha capito subito che avremmo dovuto prestare particolare attenzione a questa implementazione per identificare tempestivamente eventuali rischi per la sicurezza. Questo è importante per noi, in quanto ci permette di influenzare direttamente la sicurezza dei nostri clienti.

Non è passato molto tempo prima che ricevessimo uno dei router Zyxel dal team responsabile del progetto e potessimo iniziare la nostra analisi. Poiché riceviamo un firmware personalizzato da Zyxel, volevamo testare la parte personalizzata per noi e poi testare superficialmente la parte di base che viene utilizzata da tutti i clienti Zyxel.

Interfaccia di amministrazione

Il nostro primo passo nel processo di verifica è quello di avere una panoramica di come è strutturato il router e quali sono le funzionalità in offerta. Per farlo, avviamo Burp Suite, un popolare strumento per la registrazione e la manipolazione del traffico web. Lo usiamo per raccogliere tutti i percorsi e poi controllarli singolarmente.

Con nostra grande sorpresa, tutti i payload e le risposte POST sono criptati, il che rende incredibilmente dispendioso per noi avere una visione d'insieme. All'inizio ho pensato che questo servisse a rendere più complesso il processo di reverse engineering, ma ne riparleremo più avanti. A quel punto, abbiamo deciso di adottare un approccio diverso.

Analisi del firmware

Per fortuna, abbiamo il firmware non criptato in esecuzione sul dispositivo e possiamo smontarlo. Dato che non analizziamo progetti IoT / closed source tutti i giorni, Thomas ha chiesto a un collega di ONEKEY di eseguire un PoC sulla loro piattaforma

ONEKEY è una piattaforma di sicurezza per dispositivi IoT specializzata nell'analisi automatizzata del firmware IoT. Un componente centrale della piattaforma è l'analisi binaria del firmware, che scompatta il firmware, classifica, identifica e opzionalmente decompila tutti gli assemblaggi e poi controlla il codice per individuare potenziali vulnerabilità di sicurezza. I processi automatizzati della piattaforma consentono di identificare rapidamente i potenziali rischi per la sicurezza.

Dopo che il firmware è stato analizzato dalla piattaforma, avevamo un elenco di punti che volevamo esaminare più da vicino.

A prima vista, abbiamo alcune potenziali vulnerabilità che vale la pena indagare ulteriormente. Tuttavia, un'analisi più approfondita mostra che la maggior parte di queste vulnerabilità non sono direttamente accessibili oppure non viene elaborato alcun input dell'utente che consenta di sfruttare la vulnerabilità. Ciò significa che la minaccia reale di queste vulnerabilità è inferiore a quella che appare a prima vista.

La scoperta più interessante, di cui parlerò in dettaglio qui, è stata riconosciuta dalla piattaforma come "iniezione di comandi".

Per analizzare e verificare i rilevamenti in modo più dettagliato, ho caricato la libreria corrispondente del firmware in Ghidra, uno strumento open source di reverse engineering dell'NSA. Nella vista del codice decompilato, vediamo una funzione che assembla un comando mailsend con i dati di un JSON e poi lo esegue. La scoperta sembra promettente perché dati come le email del mittente e del destinatario dovrebbero essere molto probabilmente inseriti dall'utente.

Exploit

Abbiamo quindi un'azione vulnerabile per la quale dobbiamo scoprire se è accessibile con l'input dell'utente e come può essere chiamata. Dopo una breve ricerca, ho trovato quello che cercavo nelle impostazioni dei log. Queste permettono di inviare i syslog a un'email specifica a intervalli regolari.

Per utilizzare la funzione, il nostro payload deve eseguire un comando all'interno del comando stesso. Ulteriori informazioni sull'iniezione di comandi sono disponibili su HackTricks

Tuttavia, il pannello di amministrazione non ci ha permesso di inserire i caratteri speciali necessari per il nostro attacco. E se si trattasse solo di una validazione lato client?

Per poter manipolare le richieste al backend, dovevamo prima bypassare la crittografia lato client. Per farlo, ho impostato un punto di interruzione nella corrispondente funzione di crittografia JavaScript AES nel debugger di Chrome e ho potuto regolare il valore prima della crittografia tramite la console. Il flusso del programma è quindi proseguito e la richiesta manipolata è stata inviata al server.

Il risultato della richiesta manipolata si presentava così. Come possiamo vedere, la convalida dei caratteri speciali era solo un controllo lato client, che abbiamo aggirato con successo.

La configurazione delle impostazioni email è stata preparata e abbiamo dovuto attivare la funzione per eseguire il nostro payload. Per questo abbiamo utilizzato la funzione di log "E-mail Log Now".

Dopo aver verificato la funzionalità dell'iniezione di comandi, ho realizzato un semplice proof of concept in Python, che automatizza l'intero processo.

Durante questa implementazione, ho dovuto ricostruire la crittografia lato client e ho ricreato il seguente processo

1. Il cliente genera una chiave AES casuale
2. Il client recupera una chiave pubblica tramite l'endpoint /getRSAPublickKey
3. Il client invia la chiave AES generata e criptata con la chiave pubblica del router durante il login
4. Il client cripta o decripta tutte le richieste/risposte successive con la chiave AES

Questo processo è simile a un'implementazione semplificata di TLS. I dispositivi possono essere consegnati senza un certificato autofirmato o, come nel nostro caso, con un certificato autofirmato, il che suggerisce che questo metodo è inteso come un'ulteriore misura di protezione contro gli attacchi man-in-the-middle.

Esecuzione del PoC

Abbiamo inviato lo script a Zyxel e il loro team di sicurezza è riuscito a riprodurre il problema nel loro firmware standard.

Timeline:

Relazione del 25 novembre 2024
29 novembre 2024 Revisione / Riproduzione
10 dicembre 2024 CVE assegnato
12 dicembre 2024 Rilascio della correzione
11 marzo 2025 Avviso pubblico

Dispositivi colpiti:

42 dispositivi, da CPE DSL/Ethernet, ONT in fibra a extender Wi-Fi.
Vedi l'avviso di Zyxel

Conclusione

Il team di sicurezza di Zyxel ha trattato le vulnerabilità segnalate con alta priorità e le ha inoltrate al gruppo di prodotti responsabile. La collaborazione è stata professionale e, grazie al proof of concept che ho fornito, è stata sviluppata e distribuita rapidamente una patch ai clienti. La piattaforma ONEKEY ci ha permesso di ottenere rapidamente una panoramica completa dei firmware interessati, accelerando notevolmente l'intero processo.

Sapevi che in Digitec Galaxus abbiamo un programma di divulgazione delle vulnerabilità? Anche gli hacker etici possono cercare con noi le vulnerabilità di sicurezza nel rispetto delle regole. Puoi trovare maggiori informazioni al riguardo nella nostra pagina sulla sicurezza.

Martin Wrona

Senior Security Software Engineer

Martin.Wrona@digitecgalaxus.ch

Potrebbero interessarti anche questi articoli