Dispositivi IoT a rischio DNS Poisoning: c'è una falla in una diffusa libreria C
Una libreria C utilizzata in moltissimi dispositivi IoT e distribuzioni Linux per applicazioni embedded contiene una vulnerabilità che può portare ad azioni di DNS Poisoning con esiti anche particolarmente gravi
di Andrea Bai pubblicata il 04 Maggio 2022, alle 11:01 nel canale SicurezzaNozomi Networks Labs
E' stata individuata una vulnerabilità nel componente DNS di una popolare libreria C che è presente ed utilizzata in una vasta gamma di prodotti connessi e potrebbe rappresentare per milioni di dispositivi il rischio di cadere vittima di attacchi di tipo DNS Poisoning.
La vulnerabilità, individuata dai ricercatori di Nozomi Networks, è a carico della libreria uClibc e del suo fork uClibc-ng ad opera del team OpenWRT. Tutte e due le varianti sono usate dai principali produttori di dispositivi di rete (Netgear, Axis e Linksys, per citarne alcuni) e nelle distribuzioni Linux dedicate a sistemi embedded. I ricercatori di Nozomi Networks avvertono che al momento non è disponibile una soluzione da parte dello sviluppatore di uClibc, con il risultato che la vulnerabilità va ad interessare i prodotti di almeno 200 fornitori.
uClibc è una libreria standard C per sistemi embedded che mette a disposizione una serie di risorse necessarie per l'esecuzione di funzioni e modalità di configurazione su tali dispositivi. L'implementazione DNS in quella libreria fornisce un meccanismo per eseguire richieste relative al DNS come ricerche, traduzioni di nomi di dominio in indirizzi IP e via discorrendo.
I ricercatori di Nozomi hanno analizzato le richieste DNS eseguite da un dispositivo che fa uso di uClibc, riscontrando alcune dinamiche di funzionamento causate da una funzione di ricerca interna. In particolare è stato riscontrato che l'ID della transazione di richiesta di ricerca DNS poteva essere prevedibile, il che potrebbe consentire l'esecuzione di una azione di DNS Poisoning.
Si tratta di un attacco che induce il dispositivo di destinazione a puntare verso un endpoint definito dall'aggressore, così da instaurare con esso una comunicazione di rete. Così facendo l'aggressore avrebbe la possibilità di reindirizzare il traffico di rete verso un server sotto il suo diretto controllo.
"L'aggressore potrebbe sottrarre o manipolare le informazioni trasmesse ed eseguire altri attacchi contro quei dispositivi per comprometterli totalmente. Il problema principale in questo caso è il modo il cui gli attacchi DNS poisoning possono forzare una risposta autenticata" sottolineano i ricercatori.
Il problema è stato scoperto nel corso del mese di settembre 2021 da Nozomi Networks che ha informato il CISA e successivamente, a dicembre, ha notificato la scoperta anche al centro di coordinamento del CERT. La vulnerabilità è stata poi comunicata a gennaio 2022 agli oltre 200 fornitori potenzialmente interessati. La vulnerabilità, che al momento ripetiamo essere senza patch, è tracciata con il codice CVE-2022-05-02.
"Poiché questa vulnerabilità rimane senza patch, per la sicurezza della comunità non possiamo rivelare i dispositivi specifici su cui abbiamo effettuato i test. Possiamo però rivelare che si è trattato di una gamma di noti dispositivi IoT con le ultime versioni del firmware, con alta probabilità che fossero implementati all'interno di infrastrutture critiche" osservano i ricercatori.
Dal momento che i fornitori dovranno applicare le patch con l'implementazione di una nuova versione della libreria uClibc negli aggiornamenti del firmware è verosimile immaginare che sarà necessario un po' di tempo prima che le opportune correzioni possano arrivare nelle mani degli utenti e degli amministratori di rete.
9 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infohttps://securityboulevard.com/2022/...ng-iot-at-risk/
che descrive in modo più dettagliato la cosa, con anche file e pezzo di codice incriminato
per ovviare alla cosa bisogna evitare di usare i dns relay interni del router e impostarli direttamente sulle macchine o farli impostare al dhcp
il problema alla fine si ridurrebbe solo alle richieste dns che il router da solo fa verso l'esterno (aggiornamenti, segnale orario, cose cosi'...)
...bella pezza perchè praticamente quasi tutti i router casalinghi sono messi cosi' (mi sembra pero' che le ultime versioni di openwrt usino direttamente libc)
Mi sa che lo sfruttamento ed il caporalato non è solo nel settore dell'agricoltura.
hai detto niente...
Mi sa che lo sfruttamento ed il caporalato non è solo nel settore dell'agricoltura.
concordo.
pigliano lavoro open, lo sbattono nel loro schifo di firmware closed, e vendono prodotti in cui non puoi nemmeno mettere le mani...
le mani gliele puoi anche mettere, ma sperare che la gente a casa risolva i problemi presenti sulle tue macchine, è come portare la macchina rotta anzichè dal meccanico a casa di un altro, praticone, che ce l'ha uguale
intendevo che usano roba open per fare roba closed, per cui spendono poco e poi non documentano e non aggiornano nè permettono a te (se sai farlo) di aggiornare.
poi ovvio che non è che la signora pina si mette a sostituire il kernel al router... ma che ci sia la possibilità è cosa diversa dal doverlo fare da soli per forza. E' una opportunità.
Mi sa che lo sfruttamento ed il caporalato non è solo nel settore dell'agricoltura.
ma che discorsi sono??
come puoi metterti a fare qualunque tipo di test??
potrebbero volerci anni prima di "scovare" qualcosa come non arrivare mai a niente.
e nel frattempo aspetti?
hai presente Spectre e Meltdown, tanto per fare un esempio?
vulnerabilità "scoperte" ai giorni nostri che riguardano anche prodotti di 10-15 anni fa.
potevano scoprirle 10-15 anni fa?
boh, forse si, forse no...
netgear mette le taglie ai bug di sicurezza in base alla gravità e urgenza
..il problema è che le mettono dopo che è uscito il fix, per cui
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".