Tecniche di Hacking DNS
Tempo di lettura: 11 minutiData pubblicazione: April 24, 2018
I server DNS (Domain Name System), sono una componente fondamentale dell’architettura del web, responsabile della traduzione di nomi facili da ricordare per l’uomo, come ad esempio google.com,in sequenze di numeri facili da processare per i computer, ovvero gli IP (Internet Protocol address). Grazie ai server DNS, infatti, non siamo costretti a ricordare l’IP di ogni sito web che vogliamo visitare, ma solo il suo nome, giacchè ci pensa il sistema DNS a rendere possibile il passaggio dall’uno, digitato nella barra degli indirizzi del nostro browser, all’altro.
Hackerare i server DNS di una specifica rete permette di impadronirsi di preziose informazioni sulla rete stessa e sui suoi utenti, quali:
- la funzione di ogni macchina all’interno della rete, informazione reperibile tramite l’attacco chiamato Zone Transfer;
- gli indirizzi web ricercati più di frequente all’interno di quella rete, informazione reperibile tramite l’attacco DNS Cache Snooping;
Risulta inoltre possibile operare attacchi ben più pericolosi, come:
- DNS Cache Poisoning, che permette di “avvelenare” (ovvero alterare) la lista dei domini contenuti nei server DNS
- DNS Server Spoofed Request Amplification DDoS, che consiste nell’usare il server DNS per operareattacchi DDoS contro domini di terze parti
Da questa breve introduzione, si capisce al volo che la sicurezza di un server DNS è materia da trattare assai seriamente, onde evitare gravi falle nella sicurezza dell’intera rete.
Funzionamento dei DNS
Occorre, prima di tutto, distinguere bene tra:il protocollo DNS, un
- protocollo attivo, solitamente, sulla porta 53;
- i server DNS, che implementano un database distribuito contenente la traduzione degli hostnames.
Qualsiasi dispositivo digitale utilizza il protocollo DNS, richiedendo l’indirizzo IP dell’ hostname google.com, ad un server DNS, contenente la “traduzione” degli hostnames in indirizzi IP. Tale server, inoltra poi la risposta nuovamente al dispositivo, che è finalmente in grado di inoltrare la propria richiesta HTTP al sito web che volevamo visitare. Quello appena descritto, è il caso più generico ed ideale ma, nella realtà, le cose sono un po’ più complicate di così.
Zone DNS
Gli hostnames sono organizzati secondo una distribuzione ad albero rovesciato, partendo dalla rootzone, o “radice”, passando per i TLD (Top Level Domains), fino ad arrivare ai nomi specifici di ogni host. Si dice che un server DNS ha autorità su una certa zona, quando conosce tutti gli hostnames relativi a quella zona. Nel mondo, esistono 13 root nameservers che hanno autorità nel restituire i referral dei TLD, e ve ne sono 10 negli USA, 2 in Europa, e uno in Giappone. I server DNS, possono dialogare con il client in modo ricorsivo o iterativo.
Una terza possibilità è quella di eseguire reverse queries che, in quest’articolo, non verranno trattate. Per capire come dialogano I server DNS della nostra rete locale, con i server radice e con i server authoritative di determinate zone, nel caso ricorsivo, basta osservare la seguente figura:
Quindi, ad esempio, se il client richiede l’indirizzo IP per google.com al server DNS locale, quest’ultimo gira la richiesta al server radice, che ha il nome del server autorizzato per il TLD “.com” che, a sua volta, inoltra la richiesta all’ authoritative server per “google”. Infine l’authoritative server si occupa di far giungere, ripercorrendo la strada all’inverso, la risposta al nostro client.
Nel caso iterativo, invece, se il server DNS locale non è in grado di ottemperare alla richiesta del client, invece di interrogare il server authoritative in prima persona, ne fornisce l’indirizzo IP al client. Sarà, dunque, quest’ultimo a inoltrare una nuova richiesta al server authoritative, e così via, finchè la richiesta del client non verrà risolta definitivamente.
Cache DNS
Per incrementare la velocità di risposta del database, si implementa un sistema di caching. Ciò significa che, ogni qual volta un server DNS non possiede un hostname che gli viene richiesto, gira la richiesta al server autoritativo per quell’hostname e, quando quest’ultimo gli fornisce la risposta, oltre a girarla al client, ne conserva una copia cache in memoria, per un certo intervallo di tempo.
Talvolta, le funzioni di caching e storing sono ben separate, ovvero ogni server ne implementa una sola delle due, altre volte invece, lo stesso server svolge entrambe le funzioni contemporaneamente. Ciò è reso possibile dal più utilizzato dei programmi open source per l’implementazione del protocollo DNS nei server, Bind (Berkley Internet Name Domain).
Si noti, tuttavia, che Bind non è insicuro di per sè, ma soltanto se configurato in modo inappropriato, pratica, quest’ultima, purtroppo molto diffusa. Da un punto di vista di sicurezza, sarebbe meglio optare per la separazione delle funzioni, se non a livello fisico, almeno (doverosamente) a livello logico.
Time To Live
Il TTL (Time To Live), è l’arco temporale all’interno del quale, l’informazione su un certo dominio, viene conservata nella cache. Se il TTL è di lunga durata si rischia che, se il domain name associato ad un certo IP cambia, ciò non venga rilevato dal client, che verrà dunque indirizzato al dominio sbagliato. Al contrario, se il TTL è di breve durata, si rischia di sovraccaricare la rete. Il TTL, viene trasmesso in ogni richiesta, sia da client a server, sia tra un server e l’altro, così da preservare la coerenza nei tempi, in ogni nodo.
DNS Cache spoofing
“To snoop” significa, letteralmente, sbirciare. Questo tipo di pratica, permette all’attaccante di “dare un’occhiata” a quali RR (resource record) sono presenti nella cache di un dato DNS server. Il modo più semplice di farlo, è attraverso una richiesta non-ricorsiva, ovvero, attraverso una richiesta iterativa. Il motivo di quest’ultima affermazione, è molto semplice.
Come è stato spiegato in precedenza, se si esegue una richiesta ricorsiva, il server DNS dovrà risponderci per forza con una risposta definitiva, sia che abbia già nella propria cache il risultato che stavamo cercando, sia che l’abbia ottenuto da un altro server con maggiore autorità. In questo modo, sarebbe impossibile, per il client, capire se il server DNS aveva già nella propria cache la risposta, o l’abbia ricevuta da un altro server DNS. Se invece si esegue una richiesta iterativa, il primo server DNS che interroghiamo, dovrà necessariamente rispondere rivelandoci se all’interno della propria cache aveva già l’indirizzo che gli abbiamo richiesto o se, invece, dobbiamo richiederlo ad un server con maggiore autorità.
Utilizzando il comando dig, un utile tool da terminale progettato per eseguire query DNS, possiamo interrogare il server specificando che la richiesta sia iterativa. Se, nella risposta, il campo “ANSWER”è impostato su zero, e il server DNS ci istruisce sull’indirizzo del server più adatto per rispondere alla nostra richiesta, potremo dedurre che, nella sua cache, non era presente l’indirizzo da noi cercato.
Stesso discorso per il caso opposto, in cui capiremo che, invece, la cache conservava l’hostname da noi richiesto.
root@kali:~$ dig amazon.com
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> amazon.com
;; global options: +cmd
;; Got answer:
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 8 IN A 54.239.25.200
amazon.com. 8 IN A 54.239.17.7
amazon.com. 8 IN A 54.239.17.6
amazon.com. 8 IN A 54.239.25.208
amazon.com. 8 IN A 54.239.25.192
amazon.com. 8 IN A 54.239.26.128
;; Query time: 56 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Mon May 02 19:27:35 CEST 2016
;; MSG SIZE rcvd: 135
Se l’unico tipo di richiesta possibile è quella ricorsiva, ci sono ancora due possibilità di capire se il dominio da noi richiesto era già presente nella cache, o meno. Basterà osservare se:
- il TTL della richiesta è molto basso. Questo potrebbe indicare che il RR era già presente nella cache.
- il TTL è uguale al RTT (Round Trip Time) di un pacchetto inviato al server. Ciò indica, quasi sicuramente, che il RR era già presente nella cache.
DNS Cache Poisoning
Se è possibile fare richieste ricorsive per hostnames di terze parti, ad un name server di una certa sottorete, mentre ci si trova fuori da quest’ultima, ciò potrebbe portare alla possibilità, da parte dell’attaccante, di “avvelenare” la cache della propria vittima.
Ciò significa che, l’attaccante, sostituirà i domini assegnati a determinati IP, con altri a suo piacimento. In questo modo, l’attaccante potrà operare il reindirizzamento di mail, o dirottare i client ignari su un proprio sito malevolo, in modo da rubare loro credenziali, installare malware sui loro pc, e così via. Per evitare che questo accada, bisogna restringere il dominio degli IP abilitati a tale tipo di richieste, solo ai computer autorizzati, interni alla rete.
DNS Server Spoofed Request Amplification DDoS
Se il name server risponde a qualunque richiesta, lo si può interrogare per la root zone, facendo sì che risponda con una risposta molto più grande di quanto non sia la richiesta. Eseguendo lo spoofing dell’IP sorgente, si può usare questo comportamento per lanciare degli attacchi DDoS contro domini di terze parti usando, come zombie, i DNS server vittima.
Conclusioni
Come possiamo notare i DNS sono un servizio essenziale ed è doveroso doverlo controllare e proteggere da attacchi, esterni ed interni. Una dellw vulnerabilità più famose è stata identificata da Kaminsky nel (lontano) 2008, mentre per conprendere a fondo i segreti del DNS consiglio il talk Secret of DNS, tenuto nel 2014 al DerbyCon.
