Hackerato il router bestseller su Temu: è emerso un quadro inquietante

La sicurezza dei dispositivi embedded economici si conferma estremamente critica. L’analisi tecnica di un repeater WiFi da 5 dollari, distribuito massivamente su piattaforme come Temu con oltre 100.000 unità vendute all’attivo, ha rivelato gravi falle di sicurezza, dalla gestione dell’input alla configurazione del firmware.

L’autore definisce il dispositivo un router (anche se è presentato come repeater) a causa delle sue caratteristiche tecniche, funzionali e della sua architettura software, come emerge dalla verifica profonda sul comportamento del firmware.

L’analisi, condotta da Ed, alias Low Level, un ingegnere di sicurezza e ricercatore con oltre 10 anni di esperienza nella programmazione low-level e sicurezza software, ha messo in luce una serie di criticità nella progettazione del firmware, nella gestione dell’input utente e nell’esposizione di interfacce di bootloader non protette

Dal punto di vista storico, il settore dei dispositivi embedded a basso costo ha già vissuto incidenti significativi, come le campagne botnet basate su Mirai che nel 2016 sfruttarono credenziali deboli e servizi Telnet esposti per compromettere centinaia di migliaia di dispositivi IoT. A distanza di anni, modelli economici continuano a presentare difetti elementari, segno di una filiera produttiva orientata al contenimento dei costi più che alla sicurezza.

Nell’immagine, il router non sicuro scoperto da Ed, alias Low Level, commercializzato su Temu. Vanta circa 14.000 recensioni.

Router economico: falle di sicurezza colossali. Interfaccia web e persistenza in NVRAM

Il primo punto di ingresso documentato dal ricercatore è rappresentato dall’interfaccia di amministrazione HTTP del router. Il firmware, basato su una distribuzione Linux embedded con file system SquashFS, espone pagine CGI per la configurazione di parametri fondamentali come SSID e password WiFi.

Durante i test, Ed ha individuato una vulnerabilità di Command Injection nei campi di input, dovuta all’assenza di sanitizzazione dei metacaratteri della shell.

L’iniezione del payload $(reboot) nel campo della password ha provocato un comportamento anomalo persistente: la stringa è stata salvata nella NVRAM, memoria non volatile utilizzata per conservare le configurazioni tra un riavvio e l’altro.

Ogni boot successivo richiamava il parametro compromesso in uno script di inizializzazione, generando un loop infinito di riavvii. Il fenomeno configura un soft-brick permanente finché non si interviene con un reset a livello di bootloader, dimostrando che l’input utente è passato a chiamate di sistema senza alcun filtraggio.

Modalità bootloader e download completo del firmware

Attivando il download del firmware per finalità di backup (esiste una funzione dedicata che permette di farlo), il ricercatore ha scoperto l’esistenza di una modalità di avvio alternativa attivabile tramite pressione prolungata del tasto reset.

Il router entra in un ambiente denominato Breed bootloader, un’interfaccia Web di basso livello frequentemente utilizzata su hardware basato su SoC MediaTek o Realtek per operazioni di recovery.

L’interfaccia espone informazioni “delicate” come identificativo della CPU, data di build e riferimenti Git del firmware. In condizioni normali, l’estrazione di un firmware richiederebbe la dissaldatura del chip SPI flash e la lettura tramite programmatore hardware; in questo caso, l’intero dump è ottenibile via browser senza autenticazione forte, ampliando notevolmente la superficie di attacco.

Analisi del firmware e reverse engineering

Il ricercatore ha potuto mettere ai raggi X l’immagine firmware full.bin (comodamente scaricata attraverso l’interfaccia Web) avvalendosi di binwalk, strumento in grado di identificare e decomprimere automaticamente segmenti compressi e file system embedded.

L’estrazione ha rivelato un ambiente Linux minimale con server Web lighttpd configurato tramite il file lighty.conf. La decompilazione del binario comm mediante Ghidra ha evidenziato una struttura a tabella di lookup che associa parametri HTTP a puntatori di funzione.

Ghidra è una piattaforma open source di reverse engineering sviluppata dalla NSA e rilasciata pubblicamente nel 2019. Serve per analizzare programmi compilati quando non si dispone del codice sorgente. In pratica, permette di caricare file binari (come eseguibili Windows, firmware embedded o malware), disassemblarli e trasformare il codice macchina in una rappresentazione più leggibile. Include un potente decompiler che converte le istruzioni assembly in una forma simile al linguaggio C, facilitando la comprensione della logica interna del software.

Tra le routine analizzate da Ed, la funzione time_config, presente nel firmware del router, si è rivelata vulnerabile. La mancata applicazione di meccanismi di sanitizzazione dell’input, come l’escaping (cioè la neutralizzazione dei caratteri con significato speciale) o l’uso di una whitelist (un elenco di caratteri consentiti), permette di inserire operatori shell come ;, && o i backtick (`), che sono interpretati dal router come comandi: in questo modo, una semplice configurazione dell’orario può essere sfruttata per eseguire codice arbitrario.

Dalla command injection alla shell di root

L’analisi del file system ha portato all’individuazione di una CGI denominata upload.cgi, utilizzata per aggiornamenti firmware e collocata in una cartella specifica.

Tale script consente il caricamento di file arbitrari nella directory temporanea /tmp/firmware senza controlli rigorosi sull’integrità del contenuto. Attraverso una richiesta multipart/form-data Ed ha così potuto caricare uno script shell progettato per avviare il servizio telnetd sulla porta 4444.

Sfruttando l’injection in time_config, il ricercatore ha reso eseguibile lo script avvalendosi del comando chmod +x per poi procedere con l’esecuzione. Il risultato? L’apertura di una sessione Telnet con privilegi di root, senza necessità di autenticazione.

L’intero processo dimostra come vulnerabilità apparentemente isolate possano concatenarsi in una compromissione totale del dispositivo.

Implicazioni per la sicurezza di rete e mitigazioni

Un router compromesso rappresenta un punto di controllo strategico all’interno della rete domestica o aziendale. Un attaccante con accesso root può intercettare traffico, modificare configurazioni DNS, installare backdoor persistenti o integrare il dispositivo in una botnet DDoS.

La mancanza di un produttore chiaramente identificabile, come nel caso del dispositivo messo in commercio su Temu a 5 dollari, rende complessa qualsiasi procedura di responsible disclosure e preclude la distribuzione di patch ufficiali.

Dal punto di vista tecnico, le mitigazioni richiedono pratiche consolidate: validazione rigorosa dell’input con funzioni sicure, eliminazione dell’uso diretto di chiamate system(), disabilitazione delle interfacce di bootloader in produzione o protezione con autenticazione robusta, firma crittografica degli aggiornamenti firmware e segregazione dei privilegi tramite appositi meccanismi.

In assenza di tali misure, dispositivi a costo estremamente ridotto continuano a rappresentare un rischio sistemico, soprattutto quando distribuiti su larga scala attraverso canali di vendita globali.

Il tema della responsabilità

La responsabilità per eventuali danni causati da vulnerabilità in un router commercializzato nell’Unione Europea non è un tema univoco, ma dipende dal tipo di danno, dal ruolo dei soggetti coinvolti e dal quadro normativo applicabile. In ambito italiano ed europeo si intrecciano almeno tre piani: responsabilità da prodotto difettoso, sicurezza generale dei prodotti e protezione dei dati personali.

Responsabilità da prodotto difettoso e filiera di importazione

Sul piano civilistico, il riferimento principale è la disciplina della responsabilità per prodotto difettoso, oggi armonizzata a livello UE dalla Direttiva 85/374/CEE (in fase di aggiornamento con la nuova Direttiva sulla Product Liability del 2024) e recepita in Italia nel Codice del Consumo (artt. 114–127).

Un prodotto è difettoso quando non offre la sicurezza che ci si può legittimamente attendere. Se una vulnerabilità grave – ad esempio una Remote Code Execution sfruttabile da remoto – rende il dispositivo intrinsecamente insicuro, il produttore può essere responsabile dei danni causati a persone o cose. La responsabilità è oggettiva: il danneggiato deve provare il danno, il difetto e il nesso causale, ma non la colpa del produttore.

Quando il produttore non è identificabile o ha sede extra-UE, la normativa europea estende la responsabilità all’importatore stabilito nell’Unione. Se anche questo non è individuabile, può rispondere il distributore, salvo che indichi entro un termine ragionevole l’identità del produttore o dell’importatore.

Obblighi europei di sicurezza e Cyber Resilience Act

Accanto alla responsabilità per danno, interviene la normativa sulla sicurezza dei prodotti. Il Regolamento (UE) 2023/988 sulla sicurezza generale dei prodotti impone agli operatori economici di immettere sul mercato solo prodotti sicuri e di attivare richiami o misure correttive se emergono rischi. Per dispositivi con funzionalità di rete, il quadro si rafforza con il Regolamento (UE) 2019/881 (Cybersecurity Act) e, soprattutto, con il Regolamento (UE) 2024/2847 noto come Cyber Resilience Act, che introduce obblighi specifici di sicurezza by design, gestione delle vulnerabilità e aggiornamenti di sicurezza per i prodotti con elementi digitali. In prospettiva, l’assenza di patch o di un processo di gestione delle vulnerabilità potrebbe integrare una violazione diretta di tali obblighi.

Marketplace e ruolo degli intermediari digitali

Diversa è la posizione del marketplace. In linea generale, queste piattaforme sono ritenute intermediari e non sono automaticamente responsabili per il difetto del prodotto, salvo che svolgano un ruolo attivo tale da configurarle come operatori economici nella catena di fornitura. Tuttavia, con l’entrata in vigore del Digital Services Act (Regolamento UE 2022/2065), aumentano gli obblighi di diligenza, tracciabilità dei venditori e rimozione di prodotti pericolosi su segnalazione.

Note finali

Ed sostiene che ciò che ha scoperto “dovrebbe essere illegale”. L’affermazione va letta come una denuncia della gravità tecnica e della negligenza progettuale emerse dall’analisi.

Il punto critico riguarda la combinazione tra ampia diffusione commerciale e vulnerabilità elementari: oltre 100.000 unità distribuite amplificano esponenzialmente l’impatto di falle come la mancata sanitizzazione degli input e l’uso diretto di system() parametri controllabili dall’utente, che consentono Remote Code Execution (RCE) con privilegi di root. A ciò si aggiunge l’esposizione del firmware tramite interfaccia, che riduce drasticamente le barriere tecniche all’analisi offensiva.

Il tema della responsabilità si complica per l’assenza di un produttore chiaramente identificabile. Senza un soggetto giuridico e tecnico tracciabile, diventa impossibile segnalare le vulnerabilità, gli aggiornamenti firmware risultano inesistenti e non vi è un canale per la distribuzione di patch firmate o advisory di sicurezza.

Ci risulta che il prodotto in questione non sia al momento più acquistabile attraverso Temu, almeno dall’Italia.