Un gruppo di ricercatori dell'Università di Tel Aviv e del Centro interdisciplinare di Herzliya (Israele) un nuovo metodo di attacco (), che consente di utilizzare qualsiasi risolutore DNS come amplificatori di traffico, fornendo un grado di amplificazione fino a 1621 volte nel numero di pacchetti (per ogni richiesta inviata al risolutore, è possibile ottenere l'invio di 1621 richieste al server della vittima) e fino a 163 volte per il traffico.
Il problema è legato alle peculiarità del funzionamento del protocollo e riguarda tutti i server DNS che supportano l'elaborazione ricorsiva delle richieste, inclusi (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), e (CVE-2020-12662), così come i servizi DNS pubblici di Google, Cloudflare, Amazon, Quad9, ICANN e altre aziende. La correzione del problema è stata coordinata con gli sviluppatori di server DNS, che hanno simultaneamente rilasciato aggiornamenti per eliminare la vulnerabilità nei loro prodotti. La protezione contro l'attacco è stata implementata nelle versioni
, , , .
L'attacco si basa sull'utilizzo da parte dell'attaccante di richieste che si riferiscono a un gran numero di record NS fittizi mai visti prima, a cui viene delegata la risoluzione del nome, ma senza specificare nella risposta i record glue con le informazioni sugli indirizzi IP dei server NS. Ad esempio, l'attaccante invia una richiesta per la risoluzione del nome sd1.attacker.com, controllando il server DNS responsabile del dominio attacker.com. In risposta alla richiesta del risolutore al server DNS dell'attaccante, viene fornita una risposta che delega la definizione dell'indirizzo sd1.attacker.com al server DNS della vittima, specificando nelle risposte i record NS senza dettagli sugli IP dei server NS. Poiché il server NS menzionato non è mai stato visto prima e il suo indirizzo IP non è specificato, il risolutore cerca di determinare l'indirizzo IP del server NS inviando una richiesta al server DNS della vittima, che gestisce il dominio target (victim.com).
Il problema è che l'attaccante può restituire un'enorme lista di server NS univoci con nomi di sottodomini fittizi inesistenti della vittima (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Il risolutore cercherà di inviare una richiesta al server DNS della vittima, ma otterrà una risposta che indica che il dominio non è stato trovato, dopo di che cercherà di determinare il successivo server NS nella lista e così via, finché non avrà esaminato tutti i record NS elencati dall'attaccante. Pertanto, per ogni richiesta dell'attaccante, il risolutore invierà un'enorme quantità di richieste per identificare gli host NS. Poiché i nomi dei server NS sono generati casualmente e si riferiscono a sottodomini inesistenti, non vengono estratti dalla cache e ogni richiesta dell'attaccante porta a una valanga di richieste al server DNS che gestisce il dominio della vittima.
I ricercatori hanno studiato il grado di vulnerabilità dei risolutori DNS pubblici e hanno determinato che, inviando richieste al risolutore CloudFlare (1.1.1.1), è possibile ottenere un aumento nel numero di pacchetti (PAF, Packet Amplification Factor) di 48 volte, Google (8.8.8.8) — 30 volte, FreeDNS (37.235.1.174) — 50 volte, OpenDNS (208.67.222.222) — 32 volte. Indicatori più evidenti si osservano per
Level3 (209.244.0.3) — 273 volte, Quad9 (9.9.9.9) — 415 volte
SafeDNS (195.46.39.39) — 274 volte, Verisign (64.6.64.6) — 202 volte,
Ultra (156.154.71.1) — 405 volte, Comodo Secure (8.26.56.26) — 435 volte, DNS.Watch (84.200.69.80) — 486 volte, e Norton ConnectSafe (199.85.126.10) — 569 volte. Per i server basati su BIND 9.12.3, grazie al parallelismo delle richieste, il livello di amplificazione può arrivare fino a 1000. In Knot Resolver 5.1.0, il livello di amplificazione è di circa alcune decine di volte (24-48), poiché la determinazione dei nomi NS viene eseguita in modo sequenziale e si scontra con un vincolo interno sul numero di passaggi di risoluzione dei nomi consentiti per una singola richiesta.
Si evidenziano due strategie principali di protezione. Per i sistemi con DNSSEC di utilizzare per prevenire la elusione della cache DNS, poiché le richieste sono inviate con nomi casuali. L'essenza del metodo è nella generazione di risposte negative senza contattare i server DNS autorevoli, utilizzando verifiche per intervalli tramite DNSSEC. Un modo più semplice è limitare il numero di nomi che possono essere risolti durante l'elaborazione di una singola richiesta delegata, ma questo metodo può portare a problemi con alcune configurazioni esistenti, poiché i limiti non sono definiti nel protocollo.
Fonte: opennet.ru
