Mastodon

Il problema dei DNS (e la soluzione)


Probabilmente avrete sentito parlare di una falla di sicurezza dei DNS che è stata scoperta all’inizio dell’anno e tenuta segreta fino a pochi giorni fa (in teoria non sarebbe dovuta scappare fino all’inizio di agosto, ma si sa come vanno queste cose), dopo che tutte le maggiori entità interessate hanno rilasciato degli aggiornamenti.

Prima un preambolo introduttivo, chi conosce già come funzionano i DNS può saltare i due capoversi che seguono.

Ogni macchina su Internet è identificata da un indirizzo numerico (per ora nella forma a.b.c.d dove le lettere rappresentano dei numeri da 0 a 255 decimale), ma sono difficili da ricordare; è stato quindi creato un sistema che associa delle sequenze più facili da ricordare ad un indirizzo numerico: è più facile ricordare www.fantascienza.com piuttosto che 83.103.96.96. Il sistema per passare dal nome usato dagli umani all’indirizzo numerico utilizzato dalle macchine è detto risoluzione del nome. Il sistema attraverso cui si risolvono i nomi è il DNS.

Quando voglio risolvere www.fantascienza.com, il mio computer genera un numero di sicurezza a caso tra 0 e 65.535 e lo scrive in una richiesta che invia al server DNS di riferimento (quello definito nelle impostazioni del TCP/IP del computer). Il server DNS, elabora la richiesta e risponde allegando quel numero nella risposta per fare in modo che io abbia la (relativa) sicurezza che mi ha risposto il server legittimo e non un malintenzionato. Prima del 1995 i numeri erano scelti in sequenza e, quindi, facilmente indovinabili; ora tutti i computer li scelgono a caso, ma la bontà della casualità della scelta dipende dalla piattaforma che la esegue e, quindi, potrebbe essere facilmente indovinabile.

Ma cosa potrebbe fare un malintenzionato? Essenzialmente due cose: (1) rispondere che l’IP di www.fantascienza.com è 66.6.0.66 e farmi andare su un server trappola oppure (2) rispondermi che la fonte che ha autorità per risolvere i nomi di fantascienza.com non è quella vera (register.it) bensì un server trappola che, a questo punto, è in grado di falsificare tutti gli indirizzi di fantascienza.com.

A peggiorare le cose c’è una caratteristica del DNS tale per cui ogni informazione acquisita ha una scadenza prima della quale non bisognerebbe richiedere in rete la medesima informazione. Nell’esempio di cui sopra, quando chiedo a register.it l’indirizzo di www.fantascienza.com, mi viene risposto che quell’informazione vale per i prossimi 900 secondi. Un attaccante può quindi falsificare le informazioni per il tempo che lui stesso imposta: anche dopo la conclusione dell’attacco, le informazioni rimarranno nella memoria del computer finché non si riavvia il sistema o non scade la validità dell’informazione.

Il problema di sicurezza di cui si parla ultimamente si basa su tutte le vulnerabilità descritte sopra utilizzate contemporaneamente (la novità sta proprio nell’uso contemporaneo delle vulnerabilità): se i server erano protetti contro gli attacchi portati singolarmente, fino a pochi giorni fa non lo erano per un attacco che tento di descrivere con parole semplici:

  1. Un malintenzionato bombarda il server DNS a cui voi fate riferimento (immaginiamo quello del vostro provider) con richieste che si sa a priori che hanno come risposta “nessun indirizzo associato a quel nome”; le richieste possono essere la risoluzione di nomi tipo aaa123.fantascienza.com, aaa124.fantascienza.com, aaa125.fantascienza.com, aaa126.fantascienza.com e così via.
  2. Ovviamente a ciascuna di queste richieste il server DNS del provider continua a rispondere “nessun indirizzo associato a quel nome”. Ma l’attaccante prosegue imperterrito.
  3. Per come funziona il sistema, ogni volta il DNS server del provider deve contattare register.it per verificare se effettivamente esista o no il nome richiesto ed attendere una risposta; ogni richiesta conterrà un numero casuale tra 0 e 65.535 come spiegato sopra.
  4. L’attaccante tenta di intromettersi e falsificare la risposta di register.it tentando di indovinare il numero casuale. Data la velocità delle connessioni attuali (qui sta un altra novità), il numero di tentativi che si possono fare è veramente elevato e le probabilità di indovinare il numero giusto sono più alte di quello che si pensa.
  5. Dopo un po’, ipotizziamo quando ha inviato la richiesta di risolvere lr47666.fantascienza.com, l’attaccante riesce nel suo intento: il provider riceve una risposta dall’attaccante che riconosce come valida e, per come è strutturato il pacchetto di risposta, l’attaccante non solo fa credere al server che lr47666.fantascienza.com esista davvero ma anche che www.fantascienza.com abbia come indirizzo 66.6.0.66; ovviamente la risposta contiene una scadenza relativamente alta, in modo tale che la contaminazione di www.fantascienza.com duri il più a lungo possibile. Il gioco è fatto e S* non può farci nulla perché il problema non dipende da lui, ma da voi (o dal vostro provider).

La soluzione a questo problema? Due: aggiornare le proprie piattaforme con le ultime patch disponibili e fare una doppia verifica sul DNS che si sta utilizzando per vedere se è quello effettivamente consigliato dal proprio provider. La cosa migliore sarebbe avere un DNS server proprio per non dipendere da terzi, ma bisogna anche essere in grado di mantenerlo in salute, cosa non semplice.

Su questa pagina di beezari trovate una spiegazione più tecnica del problema e dello schema di attacco.

Aggiornamento: ho notato che alcuni provider stanno disabilitando al pubblico alcuni DNS. Se non avete un DNS in house o se il vostro DNS inoltra tutte le richieste al server del provider, consiglio di verificare sul sito del provider (o da fonte similare) che stiate utilizzando i DNS giusti.


3 responses to “Il problema dei DNS (e la soluzione)”

  1. Grazie Espressione Regolare.

    Forse S* non e’ contento perche’ gli ho hackerato il DNS (anche se in un esempio), ma qualcuno doveva essere sacrificato! 🙂

Leave a Reply to Siamo geek » DNS poisoning Cancel reply

Your email address will not be published. Required fields are marked *