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 amplificatore di traffico, raggiungendo un fattore di amplificazione fino a 1621 volte in termini di pacchetti (per ogni richiesta inviata al risolutore, si possono ottenere 1621 richieste inviate al server della vittima) e fino a 163 volte in termini di traffico.
Il problema è legato alle peculiarità del protocollo e riguarda tutti i server DNS che supportano l'elaborazione ricorsiva delle richieste, tra cui (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), e (CVE-2020-12662), oltre ai servizi DNS pubblici di Google, Cloudflare, Amazon, Quad9, ICANN e di altre aziende. La correzione del problema è stata coordinata con gli sviluppatori dei server DNS, che hanno contemporaneamente rilasciato aggiornamenti per risolvere 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 fanno riferimento a un numero elevato di registrazioni NS fittizie mai viste prima, a cui viene delegata la risoluzione del nome, ma senza includere nel responso le registrazioni 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 resolver al server DNS dell'attaccante, viene fornita una risposta che delega la risoluzione dell'indirizzo sd1.attacker.com al server DNS della vittima tramite l'indicazione di registrazioni 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 resolver 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 un attaccante può restituire un enorme elenco di server NS non ripetuti con nomi fittizi di sottodomini della vittima (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Il resolver cercherà di inviare una richiesta al server DNS della vittima, ma riceverà una risposta che il dominio non è stato trovato, dopodiché cercherà di determinare il successivo server NS nell'elenco e così via, fino a esaurire tutti i record NS elencati dall'attaccante. Di conseguenza, per ogni richiesta dell'attaccante, il resolver invierà un numero enorme di richieste per determinare gli host NS. Poiché i nomi dei server NS vengono generati casualmente e fanno riferimento a sottodomini che non esistono, non vengono estratti dalla cache e ogni richiesta dell'attaccante porta a un'ondata di richieste al server DNS che gestisce il dominio della vittima.
I ricercatori hanno studiato il grado di vulnerabilità dei resolver DNS pubblici al problema e hanno determinato che inviando richieste al resolver CloudFlare (1.1.1.1) si può ottenere un fattore di amplificazione dei 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ù significativi 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 alla parallelizzazione delle richieste, il livello di amplificazione può raggiungere 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 avviene in modo sequenziale e si scontra con il limite interno sul numero di passaggi di risoluzione dei nomi consentiti per una singola richiesta.
Si delineano due principali strategie di protezione. Per i sistemi con DNSSEC utilizzare per prevenire l'aggiramento della cache DNS, poiché le richieste vengono inviate con nomi casuali. L'essenza del metodo è generare risposte negative senza contattare i server DNS autoritativi, utilizzando la verifica per intervalli tramite DNSSEC. Un metodo più semplice è limitare il numero di nomi che possono essere risolti durante la gestione di una singola richiesta delegata, ma tale metodo può portare a problemi con alcune configurazioni esistenti, poiché i limiti non sono definiti nel protocollo.
Fonte: opennet.ru
