commandinjection

Cosa si nasconde davvero dentro il firmware del router che il provider Internet recapita a casa? Un controllo di sicurezza apparentemente di routine ha portato un ricercatore indipendente a scoprire vulnerabilità rimaste sepolte nel software di un dispositivo distribuito a milioni di abbonati. Tra queste, una falla di tipo command injection sfruttabile dopo l’autenticazione che, unita ad altre debolezze già conosciute, ha permesso di ottenere una shell completa sul dispositivo. In altre parole, il controllo totale su un apparato che gestisce tutto il traffico di rete domestico. Router, modem e gateway residenziali restano uno dei punti più fragili dell’infrastruttura, sia in casa che in ufficio. Diversi rapporti pubblicati negli ultimi anni da aziende del settore confermano che questi apparati sono tra i bersagli preferiti di botnet e gruppi criminali, soprattutto perché ricevono aggiornamenti con grande ritardo oppure continuano a girare su firmware derivati da codice scritto anni prima. Detto questo, si capisce bene quanto il classico consiglio di riavviare il router sia quasi una presa in giro. Nel caso specifico, l’analisi era partita dopo aver verificato la presenza di due vulnerabilità già registrate come CVE e riconosciute dal produttore. Una command injection nascosta nel codice L’indagine ha messo in luce una vulnerabilità di command injection accessibile dopo l’autenticazione nell’interfaccia di amministrazione. In pratica, chi possiede già credenziali valide potrebbe eseguire comandi arbitrari sul sistema operativo del router, sfruttando una gestione sbagliata degli input. È una categoria di falle parecchio insidiosa: anche quando richiede un accesso preliminare, può trasformare un account con privilegi limitati in una porta aperta verso il controllo completo del dispositivo. Nel caso dei router il problema pesa ancora di più, visto che l’apparato gestisce traffico Internet, configurazioni VoIP, DNS, regole firewall e spesso l’intera segmentazione della rete locale. Il ricercatore è riuscito a ottenere una reverse shell, cioè una connessione remota interattiva che permette di controllare il router compromesso. La dimostrazione, insomma, non si fermava all’esecuzione di singoli comandi: garantiva un accesso remoto completo e continuativo. A rendere il tutto ancora più interessante c’è poi l’account supervisor, un’utenza con credenziali diverse rispetto agli altri profili amministrativi raggiungibili dall’interfaccia web. Dopo aver ottenuto la shell, il tecnico ha cambiato la password di quell’utente e si è collegato via SSH, finendo dentro una shell Linux standard con funzioni aggiuntive non disponibili agli amministratori normali. Il provisioning remoto e il ruolo del TR-069 Un altro elemento citato riguarda il protocollo TR-069, adottato dagli operatori per configurare automaticamente modem e router installati a casa dei clienti. Tramite questo protocollo, noto anche come CWMP, il dispositivo dialoga con un server ACS dell’operatore e riceve impostazioni su connettività, servizi VoIP, aggiornamenti firmware e altri parametri. Tutto molto comodo per la gestione, ma anche fonte di complessità non banale dal punto di vista della sicurezza. Un router che supporta il provisioning remoto deve esporre componenti software in più, meccanismi di autenticazione e processi sempre attivi: ogni pezzo aggiuntivo è un potenziale punto debole da tenere d’occhio. Per arrivare a questi risultati, l’approccio più realistico parte da una workstation Linux. Prima cosa, identificare l’hardware: via SSH, seriale o leggendo le informazioni dell’interfaccia web si raccolgono modello, versione firmware, kernel e chipset. Strumenti come nmap servono a enumerare i servizi esposti, mentre il firmware vero e proprio si scarica dal sito del produttore. Comandi come strings firmware.bin restituiscono spesso indizi preziosi, come la presenza di BusyBox, OpenSSL o dropbear. Da qui entra in gioco Binwalk, uno degli strumenti più usati nella ricerca embedded: scompone il firmware nelle sue parti interne, individua filesystem SquashFS, CramFS, UBIFS e kernel compressi, restituendo una copia navigabile del filesystem. L’analisi diventa allora simile a quella di un comune server Linux. I ricercatori vanno a frugare in /etc, /usr/bin, /www, /cgi-bin e nelle aree con gli script di configurazione, dove spesso compaiono file XML, JSON o database SQLite che descrivono utenti e privilegi. La caccia agli account nascosti passa per ricerche elementari ma sorprendentemente efficaci, come grep -Ri "supervisor" oppure grep -Ri "password". Sembra banale, eppure salta fuori una quantità notevole di account tecnici, URL nascosti e credenziali di test dimenticate. Per le password hardcoded si usano strumenti di analisi statica, e quando ci sono binari proprietari entra in scena il reverse engineering con Ghidra o IDA Pro, capaci di scovare routine di autenticazione, URL segreti e API interne. A completare il quadro ci sono l’analisi della sequenza di avvio tramite connettori UART e adattatori USB-TTL, lo studio del bootloader U-Boot e l’emulazione del firmware con framework come FirmAE. È proprio l’incrocio di tutte queste tecniche a far emergere nuove CVE e debolezze nascoste. Dopo la segnalazione al produttore secondo le procedure di responsible disclosure, il ricercatore ha continuato in laboratorio fino a scoprire l’account supervisor e i suoi privilegi extra, a riprova che anche un dispositivo appena ricevuto dall’operatore merita verifiche approfondite.

commandinjection

Router del provider a rischio: una falla nel firmware dà il controllo totale