Un gruppo di ricercatori dell'Università della California a Riverside ha pubblicato una nuova variante dell'attacco SAD DNS (CVE-2021-20322), che funziona nonostante la protezione aggiunta lo scorso anno per bloccare la vulnerabilità CVE-2020-25705. Il nuovo metodo è in generale analogo alla vulnerabilità dello scorso anno e si differenzia solo per l'uso di un altro tipo di pacchetti ICMP per controllare le porte UDP attive. L'attacco proposto consente l'inserimento di dati falsi nella cache del server DNS, il che può essere utilizzato per sostituire l'indirizzo IP di un dominio qualsiasi nella cache e reindirizzare le richieste al dominio verso un server malintenzionato.
Il metodo proposto è operativo solo nello stack di rete Linux a causa del legame con una caratteristica del meccanismo di elaborazione dei pacchetti ICMP in Linux, che funge da fonte di fuga di dati, semplificando l'identificazione del numero di porta UDP utilizzato. server per inviare richieste esterne. Le modifiche che bloccano le perdite di informazioni sono state integrate nel kernel di Linux alla fine di agosto (la correzione è stata inclusa nel kernel 5.15 e negli aggiornamenti di settembre delle branche LTS del kernel). La correzione consiste nel passaggio all'uso dell'algoritmo di hashing SipHash nei cache di rete invece di Jenkins Hash. Lo stato di risoluzione della vulnerabilità nelle distribuzioni può essere valutato sulle seguenti pagine: Debian, RHEL, Fedora, SUSE, Ubuntu.
Secondo i ricercatori che hanno identificato il problema, circa il 38% dei resolver aperti disponibili su Internet è vulnerabile, inclusi servizi DNS popolari come OpenDNS e Quad9 (9.9.9.9). Per quanto riguarda il software del server, l'attacco può essere effettuato utilizzando su un server Linux pacchetti come BIND, Unbound e dnsmasq. Nei server DNS eseguiti su Windows e sistemi BSD, il problema non si manifesta. Per portare a termine con successo l'attacco, è necessario utilizzare lo spoofing IP, quindi il provider dell'attaccante non deve bloccare i pacchetti con un indirizzo IP di origine falsificato.
Ricordiamo che l'attacco SAD DNS consente di eludere la protezione implementata nei server DNS per bloccare il classico metodo di avvelenamento della cache DNS, proposto nel 2008 da Dan Kaminsky. Il metodo di Kaminsky manipola la dimensione ridotta del campo riguardante il numero identificativo della richiesta DNS, che è di soli 16 bit. Per trovare il corretto identificatore della transazione DNS necessario per lo spoofing del nome host, è sufficiente inviare circa 7000 richieste e simulare circa 140.000 risposte fittizie. L'attacco consiste nell'inviare al risolutore DNS un numero elevato di pacchetti con un'associazione IP fittizia e con identificatori di transazione DNS differenti. Per prevenire la memorizzazione nella cache della prima risposta, in ogni risposta fittizia viene indicato un nome di dominio leggermente modificato (1.example.com, 2.example.com, 3.example.com e così via).
Per proteggersi da questo tipo di attacco, i produttori di server DNS hanno implementato una distribuzione casuale dei numeri delle porte di rete sorgente da cui vengono inviati i richieste di risoluzione, il che ha compensato la dimensione insufficiente dell'identificatore. Dopo l'implementazione della protezione, per inviare una risposta fasulla è diventato necessario scegliere non solo un identificatore a 16 bit, ma anche una delle 64.000 porte, aumentando così il numero di varianti da ricercare fino a 2^32.
Il metodo SAD DNS semplifica notevolmente la determinazione del numero della porta di rete, riducendo l'attacco al classico metodo di Kaminsky. L'attaccante può individuare le richieste ai porti UDP inutilizzati e attivi, sfruttando la fuga di informazioni sull'attività delle porte di rete durante l'elaborazione dei pacchetti ICMP di risposta. Questo metodo riduce di 4 ordini di grandezza il numero di combinazioni da esplorare, passando da 2^32 (4_294_967_296) a 2^16+2^16 (131_072). La fuga di informazioni che consente di identificare rapidamente le porte UDP attive è dovuta a una mancanza nel codice di elaborazione dei pacchetti ICMP con richieste di frammentazione (flag ICMP Fragmentation Needed) o di reindirizzamento (flag ICMP Redirect). L'invio di tali pacchetti modifica lo stato della cache nello stack di rete, permettendo di determinare, sulla base della risposta del server, quale porta UDP sia attiva e quale no.
Scenario di attacco: Quando un risolutore DNS tenta di determinare un nome di dominio, invia una richiesta UDP al server DNS che gestisce il dominio. Nel momento in cui il risolutore attende una risposta, l'attaccante può rapidamente determinare il numero della porta di origine utilizzata per inviare la richiesta e inviare una risposta fasulla, spacciandosi per il server DNS che gestisce il dominio, utilizzando lo spoofing. Indirizzi IPIl risolutore DNS memorizzerà nella cache i dati inoltrati nella risposta fasulla e per un certo periodo restituirà l'indirizzo IP sostituito dall'attaccante per tutte le altre richieste DNS del nome di dominio.
Fonte: opennet.ru
