Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
Una vulnerabilità di UaniaOS trasformava un semplice accesso alla GUI di UaniaBOX in un possibile controllo completo del dispositivo. Un ricercatore di HackerHood ha scoperto una catena che, sfruttando UBUS e permessi ACL eccessivi, consentiva di leggere e scrivere file di sistema fino a eseguire comandi con privilegi root.
Molti apparati di rete moderni scelgono di affidare l’intera amministrazione a un’interfaccia web, senza lasciare all’operatore alcun accesso a shell: una scelta comune, pensata per semplificare la gestione e ridurre la superficie esposta.
Ma quando quell’interfaccia diventa l’unico punto di accesso al sistema, la sua robustezza finisce per coincidere con la sicurezza dell’intero dispositivo, come dimostra il caso di UaniaOS.
Alessandro Sgreccia, ricercatore di sicurezza noto come rainpwn e appartenente al team di HackerHood, si è imbattuto in una UaniaBOX, apparato SD-WAN prodotto da UANIA per l’aggregazione di banda su più connessioni WAN (fino a tre), durante una valutazione tecnica in vista di una possibile adozione presso alcuni clienti. Prima di lasciar passare il dispositivo verso la produzione, ha deciso di metterlo alla prova.
Il risultato è una catena che parte da una funzionalità apparentemente innocua, la cattura di pacchetti di rete tramite tcpdump, e arriva, passando per un endpoint interno mal protetto, fino all’esecuzione di comandi come root, su un dispositivo che per design non avrebbe dovuto concedere altro che una sessione web autenticata.
UaniaOS espone un’interfaccia di amministrazione web raggiungibile su /cgi-bin/luci (porta 65080), che ricorda immediatamente LuCI, l’interfaccia grafica di OpenWrt. Con le credenziali fornite dal vendor, l’accesso alla dashboard è stato immediato: modello del dispositivo, uptime e lease DHCP attivi.
La schermata di login di UaniaOS 3.0 stable, con l’utente admin già inserito.
La dashboard di UaniaBox dopo il login: modello, uptime e lease DHCP attivi.
Il tentativo di accedere via SSH con lo stesso account amministrativo, invece, è stato respinto:
rainpwn@0xdeadspace:~$ ssh [email protected]
([email protected]) Password:
([email protected]) Password: # Rejected
L’appliance è quindi amministrata esclusivamente tramite GUI web, senza alcuna shell a disposizione dell’operatore. Ed è proprio questo vincolo il motivo per cui l’analisi è proseguita. Se non si può ottenere una shell dalla porta principale, occorre trovare una funzionalità della GUI che esegua comandi per conto dell’utente.
Tra le voci di menu, una in particolare ha attirato l’attenzione: Servizi → Packet Capture, una pagina che consente di configurare ed eseguire una cattura di traffico con tcpdump, con parametri come filtro, durata, numero di pacchetti, risoluzione DNS e verbosità.
La pagina Packet Capture, con i campi filtro, durata, numero di pacchetti e le opzioni di risoluzione domini e verbose.
Osservando le richieste generate dalla pagina, sono emersi due elementi chiave: il frontend dialoga con un endpoint JSON-RPC su /ubus/, e questo endpoint viene interrogato anche solo per verificare l’esistenza di file sul filesystem (ad esempio il file PID di tcpdump o il .pcap prodotto dalla cattura).
Il campo più promettente sembrava il filtro passato a tcpdump, inoltrato tramite una chiamata a /usr/libexec/packet_capture_start. Ogni tentativo di command injection su questo campo, però, è stato respinto lato server con un errore di validazione (“Il filtro inserito non risulta corretto”). Un campo gestito correttamente.
Il download del file .pcap catturato avviene tramite una richiesta a /cgi-bin/cgi-download, che accetta un parametro path indicante il file da restituire:
sessionid=AUTH_TOKEN&path=%2Ftmp%2Fcapture.pcap&filename=...&mimetype=application%2Fvnd.tcpdump.pcap
Sostituendo il valore di path con /etc/passwd, il CGI ha restituito il contenuto del file senza alcun controllo:
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
...
Una lettura di file arbitraria, ottenuta modificando un solo parametro. Il meccanismo non è però completamente privo di controlli. Richiedere /etc/shadow produce un rifiuto esplicito (“Access to path denied by ACL”), segno della presenza di una lista di controllo accessi (ACL) sottostante.
Le chiamate osservate su /ubus/ seguivano tutte lo stesso schema: protocollo JSON-RPC 2.0, oggetto file, metodi come stat, e un parametro path.
Una ricerca su questo pattern ha condotto rapidamente alla documentazione di UBUS, il bus di messaggistica interno di OpenWrt che i vari demoni e moduli del sistema usano per comunicare tra loro, esposto via HTTP tramite rpcd e tipicamente affiancato da LuCI.
In questo link è possiible accedere alla documentazione tecnica https://openwrt.org/docs/techref/ubus e verificare le chiamate read e write usate per exploit.
Il riferimento costante nel percorso delle richieste a /cgi-bin/luci/admin/services/packet_capture ha confermato il quadro che UaniaBOX, sotto la sua interfaccia proprietaria, è un dispositivo OpenWrt.
In OpenWrt le ACL governano l’accesso alle chiamate UBUS esposte dai vari moduli di sistema: un utente autenticato riceve un token di sessione legato a uno specifico insieme di permessi (scope), e ogni chiamata viene confrontata con quello scope. È esattamente questo meccanismo ad aver bloccato la lettura di /etc/shadow.
La domanda successiva, a questo punto, era: cosa consentono davvero queste ACL?
Partendo dalla chiamata file stat già osservata nel traffico legittimo della pagina, sostituendo il metodo con file read è stato possibile leggere /etc/passwd direttamente via UBUS, senza passare dal CGI di download:
[{
"jsonrpc":"2.0","id":1167,"method":"call",
"params":["AUTH_TOKEN","file","read",{"path":"/etc/passwd"}]
}]Anche il metodo list ha funzionato senza restrizioni, restituendo il contenuto completo di directory come /etc/, con nome, dimensione, permessi, UID e GID di ogni voce.
Per velocizzare l’enumerazione manuale, il ricercatore ha scritto un piccolo script Python, battezzato scherzosamente Goofy Shell, capace di tradurre comandi minimali (ls, cat, cd, pwd) nelle corrispondenti chiamate JSON-RPC verso l’endpoint UBUS. Non una vera shell, ma abbastanza per rendere sostenibile e veloce l’esplorazione del filesystem, senza dover costantemente giocare con i payload.
Se la lettura funzionava, restava da capire fin dove si potesse spingere la scrittura. Dopo diversi tentativi bloccati dalle ACL, un percorso si è rivelato scrivibile: /etc/firewall.user.
Chiunque abbia familiarità con OpenWrt sa cosa significa: si tratta di uno script di shell eseguito automaticamente ad ogni (ri)avvio del firewall, con privilegi di root, proprio per permettere agli amministratori di aggiungere regole iptables personalizzate.
Il payload consiste in una singola chiamata file write che aggiunge un comando in coda al file, preservando i commenti originali per non destare sospetti:
{
"jsonrpc":"2.0","id":0,"method":"call",
"params":["AUTH_TOKEN","file","write",{
"path":"/etc/firewall.user",
"data":"# ...commenti originali...\nid > /tmp/capture.pcap"
}]
}Non è nemmeno necessario attendere un riavvio del dispositivo: è sufficiente che la GUI stessa ricarichi la configurazione del firewall, ad esempio salvando una regola di bypass qualsiasi.
Il salvataggio innesca il riavvio di uci-firewall, che esegue lo script, e con esso il payload iniettato.
Il dialogo Bypass con una regola disabilitata usata come innesco, ASN e Nota impostati su “test”.
La regola di test salvata, con una freccia che indica il pulsante Salva e applica.
Il banner “Applying configuration changes… 88s” durante il riavvio del firewall.
Rileggendo il file /tmp/capture.pcap tramite la stessa chiamata file read usata dalla pagina per il proprio output:
[{"jsonrpc":"2.0","id":1167,"result":[0,{"data":"uid=0(root) gid=0(root)\n"}]}]uid=0. Un utente web autenticato, privo per design di qualunque shell, stava eseguendo comandi come root.
L’intera catena — autenticazione, recupero del token, lettura di /etc/passwd come verifica, scrittura del payload, trigger del reload del firewall, lettura dell’output — è stata automatizzata in un unico exploit Python:
[+] UANIA BOX is online
[+] Authentication: Success!
[+] Got CSRF token: 66247a9114d60235ca3eb1563d000b50
[*] Writing: 'id > /tmp/capture.pcap' in /etc/firewall.user ...
[+] Payload delivered successfully!
[*] Restarting uci-firewall will cause an internal network outage for a few seconds. Proceed? (Y/n) Y
[+] It's Raining! Exploit successful!
uid=0(root) gid=0(root)
Da notare che il riavvio di uci-firewall causa alcuni secondi di interruzione della rete interna: lo script chiede conferma prima di procedere, un dettaglio non trascurabile su un apparato che gestisce traffico di produzione.
Da lì, ottenere una shell interattiva è stata una formalità:
rainpwn@0xdeadspace:~$ ssh 192.168.100.1 -l rainpwn
BusyBox v1.31.1 () built-in shell (ash)
---------------------------------------------------
UaniaOS 3.0 - Uania Srl
---------------------------------------------------
root@redacted:~# id
uid=0(root) gid=0(root)
Il caso UaniaOS è un promemoria di una dinamica ricorrente: quando un vendor limita l’amministrazione di un apparato alla sola interfaccia web “per ridurre la superficie di attacco”, il rischio si sposta semplicemente su quell’interfaccia.
Un endpoint interno come UBUS, pensato per la comunicazione tra componenti di sistema ed esposto via HTTP con controlli ACL incompleti, ha permesso a un utente autenticato di leggere e scrivere file arbitrari, e la scrittura su un singolo file (/etc/firewall.user) eseguito automaticamente come root, ha chiuso il cerchio trasformando un accesso web in un’esecuzione di codice completa sul dispositivo.
La vulnerabilità, corretta in UaniaOS 3.0.1, resta priva di CVE assegnata nonostante oltre un anno di processo di disclosure. Non è la prima volta che il team di HackerHood si scontra con questo tipo di attesa: anche nel caso delle vulnerabilità scoperte su BreldoBox, la richiesta di assegnazione presso il MITRE è rimasta a lungo in fase di elaborazione, con l’ente che ha risposto genericamente di operare “su un modello di gestione basato sul rischio” per via dell’elevato volume di richieste ricevute.
Il caso UaniaOS conferma quindi come, indipendentemente dalla qualità tecnica del lavoro svolto dal ricercatore, il percorso amministrativo verso l’assegnazione di un identificativo CVE possa incontrare ostacoli che esulano completamente dal merito della scoperta.
Se sei una azienda che vuole testare la sicurezza dei propri device o infrastrutture, invia una email a [email protected]. Possiamo analizzare gratuitamente la tua infrastruttura o i tuoi device con i nostri ricercatori di sicurezza.
Sono ufficialmente aperte le adesioni al Program Sponsor della Red Hot Cyber Conference 2027, la sesta edizione dell’evento annuale gratuito promosso dalla community di Red Hot Cyber per diffondere cultura, competenze e consapevolezza sui temi della cybersecurity, dell’innovazione e delle tecnologie digitali. La Conference si terrà a Roma, martedì 18 e mercoledì 19 maggio 2027, presso l’Auditorium del Seraphicum, nel cuore del quartiere EUR, con una giornata dedicata ai workshop pratici e alle attività tecniche e una seconda giornata interamente dedicata alla conferenza.
Anche per il 2027, le aziende potranno scegliere di sostenere concretamente il progetto attraverso il Program Sponsor, partecipando alla crescita di un appuntamento che mette in relazione professionisti, aziende, istituzioni, studenti, ricercatori e appassionati di tecnologia. Il programma prevede la possibilità di aderire come Sponsor Sostenitore, una formula pensata per le aziende che desiderano essere tra le prime realtà a credere e contribuire alla realizzazione della nuova edizione, oppure attraverso i tre consueti livelli di sponsorizzazione Platinum, Gold e Silver. Ogni livello di sponsorizzazione acquistato, sarà accompagnato da un pacchetto Advertising, con l'opportunità di visibilità attraverso articoli, banner e contenuti all’interno del circuito editoriale di Red Hot Cyber.
Le aziende interessate a conoscere le formule disponibili, il Media Kit e tutte le opportunità previste dal Program Sponsor 2027 possono richiedere informazioni scrivendo a [email protected].