In questo post abbiamo visto qual è la logica su cui si basa un attacco molto diffuso nell’ambito dell’hijacking (dirottamento), ovvero il DNS poisoning, conosciuto anche come pharming. Ora, invece, adremo a vedere come ottenere informazioni preziose durante la fase di footprinting (ovvero di preparazione di un attacco informatico) semplicemente forzando un trasferimento di zona su uno dei server DNS appartenenti al dominio di nostro interesse.

Sostanzialmente, una zona è costituita da un dominio e/o da uno o più sottodomini. Ad esempio, per il dominio .it ci sarà una zona dedicata a ciao.it e nell’ambito di ciao.it ci saranno altre zone dedicate a hello.ciao.it, hola.ciao.it e così via. Inoltre, i server DNS di livello top (nel nostro caso .it) delegheranno ai nameserver di zona (nella fattispecie di ciao.it) la gestione della risoluzione dei nomi, facendo in modo che i server DNS delegati divengano autoritativi per quella determinata zona. Allo stesso modo, i nameserver di ciao.it potranno delegare ai server DNS di hello.ciao.it e di hola.ciao.it la gestione delle accoppiate IP-dominio.

E’ abbastanza diffusa, soprattutto per i domini di grande dimensioni, la pratica di utilizzare più server DNS contemporaneamente, in particolare un master (primario) ed uno o più slave (secondari), in modo tale da garantire la disponibilità del servizio anche nel caso in cui si verifichi un guasto ai nameserver. A tal proposito, appare abbastanza scontata la necessità di mantenere allineate le informazioni possedute da ciascun server DNS, per fare in modo che ognuno di essi possa svolgere correttamente la propria funzione.

Ma come avviene lo scambio dei record tra i server DNS appartenenti ad una determinata zona? La risposta è molto semplice. Partendo dal presupposto che il master viene utilizzato costantemente come punto di riferimento, ogni qual volta che si verifica un cambiamento relativo al database dei record in esso contenuto, il numero di serie associato alla zona di interesse subisce un incremento. Per evitare quindi che un server slave richieda uno zone transfer senza che ve ne sia la necessità, esso procederà dapprima con la richiesta del numero di serie associato dal server primario alla specifica zona (mediante un’interrogazione di tipo SOA) e successivamente lo confronterà con il numero di serie di cui è a conoscenza. Se quest’ultimo è inferiore allorà si procederà con lo zone transfer.

Occorre notare, inoltre, che i trasferimenti di zona possono essere totali (ovvero vengono copiati tutti i record DNS dal master allo slave – AXFR) oppure incrementali (vengono copiati solo i record di cui lo slave non è ancora a conoscenza – IXFR).

Ogni trasferimento di zona crea una sorta di collegamento client-server tra la macchina che effettua l’interrogazione *XFR e la macchina che dovrà rispondere a tale query. In realtà, però, le cose non stanno propriamente così, infatti le interrogazioni *XFR sono sempre precedute dalle interragazioni di tipo SOA. E’ bene notare, inoltre, che le richieste *XFR possono essere effettuate, in base alle necessità ed alla disponibilità del server, mediante protocollo TCP oppure mediante protocollo UDP.

Quindi il trasferimento di zona per la gestione dei record è la scelta più adeguata? Assolutamente no. Infatti esso non prevede la cifratura dei dati durante la loro trasmissione, sfrutta un pessimo meccanismo per la compressione delle informazioni e soprattutto garantisce un livello di sicurezza del tutto insufficiente. E proprio grazie alle query AXFR un utente malevolo può ottenere informazioni preziosissime riguardanti la rete target.

Bando alle ciance e passiamo subito ad un esempio pratico:

nightfly@nightbox:~$ dig unirc.it NS

; <<>> DiG 9.5.1-P2 <<>> unirc.it NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12144
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;unirc.it.                      IN      NS

;; ANSWER SECTION:
unirc.it.               3600    IN      NS      ns1.garr.net.
unirc.it.               3600    IN      NS      (nameserver omesso).

;; Query time: 211 msec
;; SERVER: 151.99.125.2#53(151.99.125.2)
;; WHEN: Wed Sep 30 18:26:09 2009
;; MSG SIZE  rcvd: 73

In questo modo abbiamo individuato i server autoritativi per il dominio unirc.it. Adiamo subito a testare la robustezza di uno dei nameserver sopra elencati:

nightfly@nightbox:~$ dig @(nameserver omesso) unirc.it axfr

; <<>> DiG 9.5.1-P2 <<>> @(nameserver omesso) unirc.it axfr
; (1 server found)
;; global options:  printcmd
unirc.it.               3600    IN      SOA     (nameserver omesso). root.*.unirc.it. 2009072401 7200 7200 604800 86400
unirc.it.               3600    IN      MX      10 msgbox2.unirc.it.
unirc.it.               3600    IN      MX      30 msgbox.unirc.it.
unirc.it.               3600    IN      NS      ns1.garr.net.
unirc.it.               3600    IN      NS      (nameserver omesso).
www.*.unirc.it. 3600 IN     A       193.*.*.130
www.*.unirc.it.      3600    IN      A       192.*.*.100
www.*.unirc.it.       3600    IN      A       193.*.*.130
www.*.unirc.it.      3600    IN      A       193.*.*.130
*.unirc.it.       3600    IN      NS      (nameserver omesso).
www.*.unirc.it. 3600  IN      A       192.*.*.100
www.*.unirc.it.        3600    IN      A       193.*.*.130
www.*.unirc.it.    3600    IN      A       193.*.*.130
www.*.unirc.it. 3600 IN  A       193.*.*.130
*.unirc.it.  3600    IN      NS      (nameserver omesso).
www.*.unirc.it.     3600    IN      A       192.*.*.100
www.*.unirc.it.      3600    IN      A       193.*.*.130

ecc. (una parte dell’output è stata volontariamente omessa).

In questo modo abbiamo formulato una query AXFR al nameserver, chiedendo informazioni sul dominio unirc.it. Quello che abbiamo ottenuto è tutta una serie di record A (address, ovvero gli indirizzi IP associati ai nomi di dominio), MX (Mail Exchange, ovvero i server di posta), ed NS (ovvero Name Server), i DNS autoritativi per quel determinato dominio.

Se andiamo ad eseminare meglio i record precedentemente elencati, noteremo la presenza di indirizzi privati di classe C (192.168.*.*), i quali rappresentano un’informazione preziosissima per ogni attacker, senza considerare alcuni nomi deltutto esplicativi, vedi CISCO*.unirc.it oppure CISCO-LWAPP*.unirc.it.

Come correre ai ripari? Per prima cosa si dovrebbe utilizzare un metodo alternativo agli zone transfer mediante AXFR, utilizzando, ad esempio, SSH + rsynch per il trasferimento incrementale dei record.

Si dovrebbe, inoltre, effettuare una netta separazione tra i record appartenenti agli host di rete interna da quelli relativi alla rete esterna (magari gestendoli mediante server DNS differenti).

Infine si dovrebbe impedire che un utente qualsiasi riesca a forzare uno zone transfer, consentendo tale operazione solo a client autorizzati (magari implementando l’autenticazione ed utilizzando la direttiva allow-transfer nel file di configurazione di bind in cui vengono definite le varie zone, ovvero named.conf.local).

NB: è buona pratica cercare di limitare l’uso di record TXT ed HINFO, in quanto potrebbero fornire informazioni utilissime ad un eventuale attaccante.

Attacchi DDoS

Da notare che converrebbe sempre disabilitare la ricorsione, in quanto il DNS potrebbe essere vittima di attacchi distribuited denial of service (DDoS), basati sostanzialmente su migliaia di query provenienti da host differenti (botnet). Poichè, per ogni query, il DNS si prende in carico la richiesta ed interroga ricorsivamente i vari server DNS autoritativi per le zone interessate, il carico di lavoro dello stesso potrebbe essere eccessivo, portandolo a crashare o rendendolo irraggiungibile anche per gli utenti legittimi.

Statistiche

Un server DNS che consente interrogazioni anche da parte di utenti non autorizzati può fornire informazioni di estrema utilità, soprattutto per i cybercriminali. Infatti, possono essere stilate delle statistiche in cui vengono identificati gli errori più frequenti che commettono i vari user legittimi quando effettuano le interrogazioni al server DNS (ad esempio digitando www.postre.it anzichè www.poste.it). Basta quindi creare un clone del sito legittimo (www.poste.it), metterlo sul dominio www.postre.it ed ecco che l’esca è pronta (leggasi phishing).

Morale della favola… fate molta attenzione durante la fase di configurazione dei server DNS.

A presto.