Un gruppo di ricercatori dell'Università di Tel Aviv e del Centro Interdisciplinare di Herzliya (Israele) nuovo metodo di attacco (), che consente di utilizzare eventuali risolutori DNS come amplificatori di traffico, fornendo una velocità di amplificazione fino a 1621 volte in termini di numero di pacchetti (per ogni richiesta inviata al risolutore si possono raggiungere 1621 richieste inviate al server della vittima) e fino a 163 volte in termini di traffico.
Il problema è legato alle peculiarità del protocollo e colpisce tutti i server DNS che supportano l'elaborazione ricorsiva delle query, compresi (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), nonché servizi DNS pubblici di Google, Cloudflare, Amazon, Quad9, ICANN e altre società. La correzione è stata coordinata con gli sviluppatori di server DNS, che hanno rilasciato contemporaneamente aggiornamenti per correggere la vulnerabilità nei loro prodotti. Protezione dagli attacchi implementata nelle versioni
, , , .
L'attacco si basa sul fatto che l'aggressore utilizza richieste che si riferiscono a un gran numero di record NS fittizi mai visti prima, a cui è delegata la determinazione del nome, ma senza specificare nella risposta record di colla con informazioni sugli indirizzi IP dei server NS. Ad esempio, un utente malintenzionato invia una query per risolvere il nome sd1.attacker.com controllando il server DNS responsabile del dominio attacker.com. In risposta alla richiesta del risolutore al server DNS dell'aggressore, viene emessa una risposta che delega la determinazione dell'indirizzo sd1.attacker.com al server DNS della vittima indicando i record NS nella risposta senza dettagliare i server IP NS. Poiché il server NS menzionato non è mai stato incontrato prima e il suo indirizzo IP non è specificato, il risolutore tenta di determinare l'indirizzo IP del server NS inviando una query al server DNS della vittima che serve il dominio di destinazione (victim.com).
Il problema è che l'aggressore può rispondere con un enorme elenco di server NS non ripetitivi con nomi di sottodomini delle vittime fittizi inesistenti (fake-1.victim.com, fake-2.victim.com,... fake-1000. vittima.com). Il risolutore tenterà di inviare una richiesta al server DNS della vittima, ma riceverà una risposta che il dominio non è stato trovato, dopodiché proverà a determinare il server NS successivo nell'elenco e così via finché non avrà provato tutte le Record NS elencati dall'aggressore. Di conseguenza, per la richiesta di un utente malintenzionato, il risolutore invierà un numero enorme di richieste per determinare gli host NS. Poiché i nomi dei server NS vengono generati in modo casuale e fanno riferimento a sottodomini inesistenti, non vengono recuperati dalla cache e ogni richiesta dell'aggressore si traduce in una raffica di richieste al server DNS che serve il dominio della vittima.
I ricercatori hanno studiato il grado di vulnerabilità dei risolutori DNS pubblici al problema e hanno scoperto che quando si inviano query al risolutore CloudFlare (1.1.1.1), è possibile aumentare il 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. Si osservano indicatori più evidenti
Livello3 (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, a causa della parallelizzazione delle richieste, il livello di guadagno può arrivare fino a 1000. In Knot Resolver 5.1.0, il livello di guadagno è di circa diverse decine di volte (24-48), poiché la determinazione di I nomi NS vengono eseguiti in sequenza e si basano sul limite interno del numero di passaggi di risoluzione dei nomi consentiti per una richiesta.
Esistono due principali strategie di difesa. Per sistemi con DNSSEC utilizzare per impedire il bypass della cache DNS perché le richieste vengono inviate con nomi casuali. L'essenza del metodo è generare risposte negative senza contattare server DNS autorevoli, utilizzando il controllo dell'intervallo tramite DNSSEC. Un approccio più semplice consiste nel limitare il numero di nomi che possono essere definiti durante l'elaborazione di una singola richiesta delegata, ma questo metodo potrebbe causare problemi con alcune configurazioni esistenti poiché i limiti non sono definiti nel protocollo.
Fonte: opennet.ru