Il possibile ritorno degli attacchi DNS cache poisoning

Più di 10 anni fa vi avevamo parlato degli attacchi DNS cache poisoning: Sui principali server DNS inizia il passaggio a DNSSEC.
Si tratta di una metodologia di aggressione che mira a modificare (“avvelenare“) la cache dei server DNS abbinando l’indirizzo IP di un server web che eroga servizi assolutamente legittimi (spesso associato a siti molto famosi) con un IP utilizzato da sistemi gestiti da gruppi di criminali informatici. Con la tecnica del cache poisoning si possono ingannare i server DNS vulnerabili facendo ritenere loro di ricevere delle informazioni autentiche quando in realtà si tratta di dati generati ad arte per modificarne il comportamento e intervenire sui record che memorizzano (ovvero sulla corrispondenza tra indirizzi mnemonici del tipo www.google.it e IP).

Nell’articolo DNS Google, ecco come funzionano e perché sono utili abbiamo visto cosa sono e come operano i server DNS per la risoluzione dei nomi a dominio.

Sembrava un problema di sicurezza ormai messo definitivamente da parte ma i ricercatori dell’Università Tsinghua e dell’Università della California hanno individuato un nuovo metodo che può essere sfruttato per lanciare attacchi del tipo DNS cache poisoning.
La vulnerabilità “aggiornata al 2020” è stata battezzata SAD DNS (Side-channel AttackeD DNS) e le è stato assegnato l’identificativo CVE-2020-25705.

Fonte: BlueCat Networks.

Per superare il problema scoperto nel 2008 da Dan Kaminsky e legato alla risoluzione dei nomi a dominio fu introdotto un meccanismo di randomizzazione delle porte. Anziché utilizzare sempre la porta 53, i transaction ID – ovvero le stringhe di conferma che attestano la veridicità di una risposta pervenuta da altri DNS – vengono fatti transitare su porte diverse. In questo modo, anche se un aggressore riuscisse a generare tutti i transaction ID possibili (le combinazioni possibili sono soltanto 65.536), questi non saprebbe dove inviare il messaggio non conoscendo la porta corretta da utilizzare.

Il team di ricercatori accademici ha tuttavia scoperto un modo per dedurre la porta di comunicazione utilizzata dal server DNS di origine, sulla quale è attesa la risposta da parte dell’altro server.

Gli studiosi spiegano che gli attacchi DNS cache poisoning potrebbero tornare in forza dell’approccio usato in Linux per la gestione dei pacchetti ICMP, usati quando di lanciano i comandi ping e tracert.
Per risparmiare banda Linux regola il numero di richieste in entrata a 1.000 al secondo e utilizza un contatore per tenerne traccia.
Inondando un server Linux con 1.000 pacchetti al secondo destinati a diverse porte scelte in modo casuale, un aggressore può risalire alle porte aperte sul resolver DNS e, in pochi secondi, provare l’attacco cache poisoning.

Il kernel Linux è già stato aggiornato in queste settimane per ottimizzare la gestione dei pacchetti ICMP rendendo decisamente più difficoltose attività come quelle illustrati dagli universitari cinesi e statunitensi: ci vorrà però un po’ di tempo prima che il fix sia distribuito a tutti.