DNS spoofing e cache poisoning: una panoramica pratica

Il DNS è nato senza alcun modo per verificare che una risposta provenisse davvero dal nameserver da cui diceva di provenire. Questa lacuna rende possibile lo spoofing: un attaccante in grado di intercettare una query DNS, o di batterla sul tempo, può restituire una risposta falsificata che indirizza la vittima verso un indirizzo scelto da lui, spesso per dirottare il traffico verso un server malevolo che si spaccia per un sito legittimo.

Cache poisoning: la stessa idea, su larga scala

Il cache poisoning riprende la stessa idea della risposta falsificata, ma prende di mira un resolver condiviso invece di una singola vittima. Se un attaccante riesce a infilare una risposta falsa nella cache di un resolver ricorsivo molto usato, ogni utente successivo di quel resolver riceve la risposta avvelenata finché non scade: un singolo inganno riuscito diventa così un attacco contro chiunque condivida quel resolver, senza bisogno di intercettare le query di ciascuno.

Come si difende il DNS moderno

Nessuna di queste difese è diffusa ovunque, e l'adozione di DNSSEC in particolare resta parziale tra i domini che compongono Internet. Usare un resolver pubblico ben gestito e attento alla sicurezza, e considerare un risultato di risoluzione inatteso o sospetto come un motivo per ricontrollare da un secondo resolver indipendente, resta una precauzione pratica ragionevole anche dove DNSSEC non è in gioco.

Il bug che ha cambiato la serietà con cui si affronta il problema

Il cache poisoning ha smesso di essere una preoccupazione teorica nel 2008, quando il ricercatore di sicurezza Dan Kaminsky rese nota una falla fondamentale che riguardava quasi tutti i resolver DNS in uso all'epoca: lo spazio dei possibili ID di transazione e porte sorgente che un attaccante doveva indovinare era abbastanza piccolo da poter essere forzato in pochi secondi con una connessione veloce, permettendo di avvelenare la cache di un resolver per un intero dominio e non solo per un singolo record. La divulgazione portò a un rilascio di patch insolitamente coordinato e simultaneo da parte di tutti i principali produttori di software DNS (la randomizzazione della porta sorgente diventò uno standard quasi dall'oggi al domani) ed è in gran parte il motivo per cui le difese elencate sopra esistono nella forma attuale.

Perché DNSSEC fatica a diffondersi nonostante la correzione risalga a vent'anni fa

DNSSEC risolve il problema di fiducia di fondo in modo molto più completo della sola randomizzazione delle porte: è una prova crittografica, non soltanto un gioco di indovinelli più difficile. La sua lenta diffusione ha più a che fare con la complessità operativa che con dubbi sul suo valore: firmare correttamente una zona, ruotare le chiavi nei tempi previsti senza rompere la validazione e mantenere intatta l'intera catena di fiducia dalla radice fino a un dominio specifico è decisamente più difficile che aggiungere un record A non firmato. Un singolo errore in quel processo produce proprio la modalità di guasto SERVFAIL trattata altrove in questa serie, che di per sé è un deterrente per i piccoli gestori di domini privi di competenze DNS dedicate in organico. Il divario tra «risolto in teoria» e «diffuso ovunque in pratica» è comune nell'infrastruttura di sicurezza, e DNSSEC ne è un chiaro esempio.