Un team di ricercatori dell'Università della California, Riverside, ha pubblicato una nuova variante dell'attacco SAD DNS (CVE-2021-20322) che funziona nonostante le protezioni aggiunte lo scorso anno per bloccare la vulnerabilità CVE-2020-25705. Il nuovo metodo è generalmente simile alla vulnerabilità dell'anno scorso e differisce solo nell'uso di un diverso tipo di pacchetti ICMP per controllare le porte UDP attive. L’attacco proposto consente la sostituzione di dati fittizi nella cache del server DNS, che possono essere utilizzati per sostituire l’indirizzo IP di un dominio arbitrario nella cache e reindirizzare le richieste al dominio al server dell’aggressore.
Il metodo proposto funziona solo nello stack di rete Linux grazie alla sua connessione alle peculiarità del meccanismo di elaborazione dei pacchetti ICMP in Linux, che funge da fonte di perdita di dati che semplifica la determinazione del numero di porta UDP utilizzato dal server per inviare un richiesta esterna. Le modifiche che bloccano la fuga di informazioni sono state adottate nel kernel Linux alla fine di agosto (la correzione è stata inclusa nel kernel 5.15 e negli aggiornamenti di settembre ai rami LTS del kernel). La soluzione si riduce al passaggio all'utilizzo dell'algoritmo di hashing SipHash nelle cache di rete anziché a Jenkins Hash. Lo stato di correzione della vulnerabilità nelle distribuzioni può essere valutato su queste pagine: Debian, RHEL, Fedora, SUSE, Ubuntu.
Secondo i ricercatori che hanno identificato il problema, circa il 38% dei risolutori aperti sulla rete sono vulnerabili, compresi i popolari servizi DNS come OpenDNS e Quad9 (9.9.9.9). Per quanto riguarda il software server, un attacco può essere effettuato su un server Linux utilizzando pacchetti come BIND, Unbound e dnsmasq. Il problema non si presenta sui server DNS in esecuzione su sistemi Windows e BSD. Per effettuare con successo un attacco è necessario utilizzare lo spoofing IP, ovvero è necessario che l'ISP dell'aggressore non blocchi i pacchetti con un indirizzo IP di origine falso.
Ricordiamo che l’attacco SAD DNS aggira le protezioni aggiunte ai server DNS per bloccare il classico metodo di avvelenamento della cache DNS proposto nel 2008 da Dan Kaminsky. Il metodo di Kaminsky manipola la piccola dimensione del campo ID della query DNS, che è di soli 16 bit. Per selezionare il corretto identificatore di transazione DNS necessario per lo spoofing del nome host, è sufficiente inviare circa 7000 richieste e simulare circa 140mila risposte fittizie. L'attacco si riduce all'invio di un gran numero di pacchetti con un collegamento IP fittizio e con diversi identificatori di transazione DNS al risolutore DNS. Per impedire la memorizzazione nella cache della prima risposta, ogni risposta fittizia contiene un nome di dominio leggermente modificato (1.example.com, 2.example.com, 3.example.com, ecc.).
Per proteggersi da questo tipo di attacchi, i produttori di server DNS hanno implementato una distribuzione casuale dei numeri di porte di rete di origine da cui vengono inviate le richieste di risoluzione, compensando così la dimensione non sufficientemente grande dell'identificatore. Dopo aver implementato la protezione per l'invio di una risposta fittizia, oltre a selezionare un identificatore a 16 bit, è stato necessario selezionare una delle 64mila porte, aumentando così il numero di opzioni di selezione a 2^32.
Il metodo SAD DNS consente di semplificare radicalmente la determinazione del numero di porta di rete e ridurre l'attacco al classico metodo Kaminsky. Un utente malintenzionato può rilevare l'accesso a porte UDP attive e non utilizzate sfruttando le informazioni trapelate sull'attività delle porte di rete durante l'elaborazione dei pacchetti di risposta ICMP. Il metodo ci consente di ridurre il numero di opzioni di ricerca di 4 ordini di grandezza: 2^16+2^16 invece di 2^32 (131_072 invece di 4_294_967_296). La fuga di informazioni che consente di determinare rapidamente le porte UDP attive è causata da un difetto nel codice per l'elaborazione dei pacchetti ICMP con richieste di frammentazione (flag ICMP Fragmentation Needed) o reindirizzamento (flag ICMP Redirect). L'invio di tali pacchetti modifica lo stato della cache nello stack di rete, il che rende possibile determinare, in base alla risposta del server, quale porta UDP è attiva e quale no.
Scenario di attacco: quando un risolutore DNS tenta di risolvere un nome di dominio, invia una query UDP al server DNS che serve il dominio. Mentre il risolutore attende una risposta, un utente malintenzionato può determinare rapidamente il numero di porta di origine utilizzato per inviare la richiesta e inviare una risposta falsa, impersonando il server DNS che serve il dominio utilizzando lo spoofing dell'indirizzo IP. Il risolutore DNS memorizzerà nella cache i dati inviati nella falsa risposta e restituirà per qualche tempo l'indirizzo IP sostituito dall'aggressore per tutte le altre richieste DNS per il nome di dominio.
Fonte: opennet.ru