NXNSAttack, la vulnerabilità nei server DNS sfruttabile per attacchi DDoS su larga scala: i dettagli

Si chiama NXNSAttack la vulnerabilità, scoperta dai ricercatori dell’Università di Tel Aviv che espone i meccanismi ricorsivi dei Server DNS. Lo studio condotto dimostra come sia possibile innescare un attacco DDoS nei processi di risoluzione e delega sfruttando un’inefficienza comune a molte tecnologie DNS.

La nuova tecnica di attacco sarebbe più devastante del tradizionale NXDomain, raggiungendo un fattore di amplificazione di oltre 1620x e portando alla saturazione anche della memoria cache dei Resolver.

Confronto tra l’attacco NXDomain di Mirai e le tre varianti di attacco simulato NXNSAttack. I dati Mirai sono stati estrapolati dall’articolo accademico “Understanding the Mirai botnet” presentato all’USENIX Security Symposium 2017.

Come funziona il servizio DNS

Quando si digita l’indirizzo di un sito Internet nella barra degli indirizzi del proprio browser, tale indirizzo viene tradotto dal servizio DNS in un indirizzo IP numerico, secondo un determinato processo di risoluzione.

Dapprima viene interrogato il DNS locale sul computer e solo se le informazioni necessarie non risiedono localmente, il computer allora interrogherà il DNS dell’Internet Service Provider (ISP) e così via coinvolgendo diversi Name Server, secondo uno schema gerarchico, fino alla consegna finale al client dell’indirizzo di dominio richiesto.

Definito il seguente ordine gerarchico crescente:

1. Resolver (l’intermediario diretto tra il client e il server dei Nomi DNS);
2. Root Name Server;
3. TLD Name Server (Top Level Domain);
4. Name Server autorevole;

il funzionamento del processo di risoluzione degli indirizzi può essere così semplicemente schematizzato:

• il client Web invia una richiesta al Resolver DNS (qual è l’IP di www.google.com?);
• il Resolver DNS risponde con i dati memorizzati in cache, altrimenti:

1. invia una richiesta a un Name Server Root DNS che lo indirizza verso un Name Server TLD in base all’estensione del dominio richiesto (.com);
2. segue l’invio di una richiesta al Name Server TLD indicato al punto 1, che a sua volta indirizza il Resolver DNS verso un DNS autorevole sulla base del nome di dominio (google.);
3. segue un’ultima richiesta, da parte del Resolver, al DNS Name Server autorevole indicato al punto 2;
4. solo dopo aver ricevuto una risposta dal Name Server autorevole contenente l’indirizzo IP richiesto, il Resolver DNS invia la risposta definitiva al client Web (l’IP di www.google.com è 216.58.206.36). Qualora neanche il Name Server autorevole dovesse possedere la risposta, questo restituirà un messaggio delega con gli indirizzi dei server autorevoli successivi a cui il Resolver DNS potrà riformulare la query. È proprio quest’ultimo passaggio, tra il Name Server autorevole e il Resolver, il punto debole sfruttato dal NXNSAttack.

NXNSAttack: lo scenario d’attacco

L’attacco ha inizio inviando da un client controllato dall’aggressore una richiesta (sd1.attacker.com) a un Resolver DNS vulnerabile. Ognuna di queste richieste è realizzata in modo che i dati per la risposta non siano presenti sulla cache del Resolver, costringendolo così a comunicare con un Name Server autorevole anch’esso controllato dall’aggressore (“attacker.com” nell’esempio).

Invece di restituire gli indirizzi ai server autorevoli effettivi, il Name Server autorevole “attacker.com” risponde alla query DNS con un elenco di nomi delega di n sottodomini falsi (fake-n.victim.com), controllati sempre dallo stesso attaccante, senza però fornire i rispettivi indirizzi IP (Glue Records).

In tal modo il Resolver viene indotto ad inoltrare le richieste verso il server DNS autorevole vittima (“victim.com” nell’esempio).

Il Name Server autorevole controllato è programmato a rispondere sempre con n indirizzi delega diversi per ogni richiesta del Resolver. Sotto tali condizioni in breve tempo il Resolver e il corrispondente Server autorevole vittima vengono investiti da un attacco DDoS con un importante fattore di amplificazione.

Per ogni n sottodomini senza un indirizzo IP associato, si calcola che un Resolver (implementato con un algoritmo BIND) avvia un numero F di nuove risoluzioni nell’intervallo 74≤F≤2n, dove 2n rappresenta il numero di richieste generate.

A tal proposito si può pensare a tre strategie di attacco interscambiabili e/o simultanee, interessando opportunamente diversi livelli della gerarchia DNS, con conseguenze ancor più deleterie.

Potrebbero essere controllati più client con più Resolver per colpire un determinato server autorevole oppure più server autorevoli per colpire un determinato Resolver ed estendere l’attacco ricorsivo con una doppia amplificazione scatenata da auto-deleghe prodotte dallo stesso server autorevole controllato dall’attaccante.

Conclusioni

Nel tentativo di mitigarne l’impatto, i ricercatori hanno implementato una miglioria (Max1Fetch) sull’algoritmo BIND 9.12.3 comunemente usato dai Resolver ricorsivi e server autorevoli, dimostrandone l’efficienza di risposta.

Risposta a una simulazione di attacco NXNSAttack di un Server autorevole rispettivamente con un algoritmo BIND (linea rossa) e un algoritmo Max1Fetch (linea blu).

Come rimarcato dagli stessi ricercatori, l’NXNSAttack rappresenta una seria e reale minaccia soprattutto per:

• la relativa facilità con cui è possibile allestire Name Server autorevoli falsi e acquistare a prezzi economici nomi di dominio;
• il meccanismo ridondante previsto dagli algoritmi DNS per tollerare guasti e migliorare i tempi di risposta. Un rimedio legittimo che può essere sfruttato malevolmente da abili attaccanti.

La pubblicazione della ricerca è stata preceduta da una procedura di divulgazione responsabile, contattando privatamente i principali fornitori di servizi DNS, molti dei quali sono intervenuti aggiornando i loro servizi anche secondo l’approccio MaxFetch suggerito.