La crescita degli attacchi politicamente e ideologicamente motivati
17 Febbraio 2016
Nasce il CyberPARCO, primo centro di eccellenza italiano multidisciplinare sulla Cyber Security
18 Febbraio 2016

LAN DNS Spoofing

Il DNS è uno dei servizi alla base di Internet. Esso risolve i nomi di dominio, associandoli a un dato indirizzo IP e rende la circolazione dei pacchetti IP possibile, dunque fornisce la possibilità a client e browser di connettersi ai server usando tutta una serie di protocolli.

Connettendosi all’IP restituito dal DNS server quando si effettua la richiesta di un dato nome di dominio (l’indirizzo classico nella notazione letterale che conosciamo), l’utente ripone molta fiducia nel server DNS, perchè di default, le risposte di questo tipo di server non sono validate o verificate. Talvolta inoltre, data la complessità dei protocolli e delle infrastrutture di rete, possiamo anche non conoscere quale sia il nostro server DNS.

Si mostra di seguito quanto sia facile configurare un server DNS in una rete, per bloccare richieste verso domini specifici o per fingerci un determinato sito web. Questo scenario è più comunemente conosciuto col nome di DNS Forgery o DNS spoofing.

PERCHÈ ALTERARE I RECORD DNS?

Il DNS è il responsabile che gestisce i nomi dei domini internet, traducendoli in indirizzi IP. Anche se questo suona come un semplice task in realtà questa traduzione porta con se una grande responsabilità, in quanto step fondamentale per mettere in comunicazione due macchine. Prima che una macchina possa mettersi in comunicazione con un’altra macchina e iniziare la comunicazione, è necessario che una richiesta DNS risolva il nome della macchina destinataria. In pratica, se ci si vuole connettere a ‘google.it’ è necessario prima conoscere l’indirizzo IP delle macchine su cui risiede.

Ci sono molte motivazioni sul perché si voglia ridirigere il traffico alterando un record DNS. Le due principali sono:

  • Bloccare un sito: Specialmente negli ultimi anni, molti governi hanno usato il DNS Spoofing per bloccare l’accesso a siti web che presentavano contenuto a rischio (social network, siti politici/religiosi, pornografia, siti pirata).
  • Origliare le conversazioni (Man in The Middle – MITM): Redirigere tutti i pacchetti IP verso una macchina terza rende possibile un attacco conosciuto col nome di ‘Man in The Middle attack’, al fine di ascoltare il flusso di pacchetti fra le due macchine bersaglio. Molti tool sono nati esclusivamente per questo scopo: Wireshark, mitmproxy, e tanti altri.

ESEMPIO: ALTERIAMO I RECORD DNS CON DNSMASQ

Lo scenario che andremo a descrivere, fa uso di un server DNS molto piccolo, chiamato Dnsmasq, per alterare i record DNS. Quel che si farà è configurare Dnsmasq per inoltrare tutte le richieste DNS verso i server DNS di Google, tranne quelle che vogliamo alterare.

Una volta che il Dnsmasq è installato e funzionante, i client devono in un certo senso essere ‘avvisati’ di usare questo nuovo server DNS; questo può essere fatto cambiando le configurazioni del router o le impostazioni di rete nel sistema operativo in uso. Molto semplicemente, se immaginiamo di essere in una LAN, non dev’essere difficile poter accedere al pannello di configurazione del Router e dunque agire senza che i clients connessi ne siano necessariamente al corrente.

DOVE FAR GIRARE IL SERVER DNS?

Nello scenario attuale, il posto migliore dove far girare un server DNS è un sistema che rimanga acceso il tempo necessario a portare a compimento ciò per cui è stato pensato.  Talvolta possono volerci giorni prima di ottenere ciò a cui si sta realmente puntando. Quindi l’ideale è avere un computer perennemente connesso e facilmente occultabile in LAN.

Un dispositivo che fa al caso nostro? Raspberry Pi.
Il RPi è un computer a tutti gli effetti, che ci dà la possibilità di farci girare su Linux; offre inoltre le interfacce di rete necessarie per stabilire il collegamento con la periferica di rete (nel nostro scenario, il semplice router). Installare Dnsmasq su RPi è facile, da terminale è sufficiente digitare il seguente comando:

> apt-get install dnsmasq-base

Dnsmasq gira inizialmente con la configurazione di default, per crearne una è necessario creare il file /etc/dnsmasq.conf e inserirvi dentro:

no-dhcp-interface=
server=8.8.8.8
no-hosts
addn-hosts=/etc/dnsmasq.hosts

Queste 4 linee di configurazione dicono a Dnsmasq di usare il server DNS di Google (8.8.8.8) come server di ripiego se la richiesta non può essere risolta dal file di hosts: /etc/dnsmasq.hosts (che va a sostituire il file di hosts di default: /etc/hosts).

ALTERARE I RECORD DNS

Il file di configurazione sopra dice a Dnsmasq di guardare in /etc/dnsmasq.hosts per risolvere le richieste DNS. Di default questo file non esiste, dunque va creato e popolato in questo modo ad esempio:

192.168.1.78 www.facebook.com facebook.com
192.168.1.79 www.microsoft.com
192.168.1.80 www.pippo.pluto pippo.pluto

Ogni linea del file contiene un indirizzo ip ed uno o più nomi (domini) che verranno risolti a indirizzati verso quel dato indirizzo IP. Ad esempio, ogni richiesta verso ‘www.pippo.pluto’ oppure verso ‘pippo.pluto’ verrà reindirizzata verso l’ip ‘192.168.1.80’

TESTIAMO ED ESEGUIAMO IL SERVER

Per testare che il tutto funzioni, è consigliabile, riavviare il processo di Dnsmasq oppure riavviare semplicemente il Raspberry Pi e poi avviare nuovamente il server DNS, con i due comandi sotto mostrati:

> sudo shutdown -r now
> dnsmasq -no-daemon -log-queries

Per testare localmente, sullo stesso RPi, che la risoluzione di alcuni domini sia compromessa, è sufficiente lanciare da terminale:

> dig @192.168.1.111 +short www.facebook.com

Dove ‘192.168.1.111’ è l’indirizzo IP dove gira il server Dnsmasq (nello scenario attuale, è l’ip dello stesso RPi dunque). Il risultato che ci aspettiamo è ‘192.168.1.78’, proprio come definito nel file /etc/dnsmasq.hosts, che è ben differente dall’indirizzo ufficiale dei server facebook.

Mentre per un comando del genere:

> dig @192.168.1.111 +short www.google. it

Non avendo definito quel dominio nel file hosts, Dnsmasq reindirizza la richiesta direttamente al server DNS di google (8.8.8.8), restituendo un risultato del tipo:

173.194.70.99
173.194.70.105
173.194.70.147
173.194.70.106
173.194.70.103

Una volta che abbiamo appurato il funzionamento del server DNS su RPi, è possibile lanciarlo senza parametri secondari (utili solamente in caso di debug), ovvero:

> dnsmasq

Il server Dnsmasq non farà altro che girare in background, rispondendo alle richieste DNS che gli vengono poste.

CAMBIARE IL SERVER DNS NEL ROUTER

Come precedentemente anticipato, dobbiamo trovare un modo per poter ‘avvisare’ i client ‘vittima’ di usare un server DNS differente da quello a cui erano abituati.

E’ possibile farlo agendo direttamente sulle configurazioni di rete sull’OS del client in questione, oppure, in modo meno ‘invasivo’ per i client, effettuare questa modifica direttamente sul Router.

Questa procedura, cambia a seconda del modello di Router che si ha. Ma e’ abbastanza banale entrare nel pannello d’amministrazione del router, dunque trovare il giusto riquadro per poter inserire un nuovo indirizzo per il server DNS e salvare la nuova configurazione.

Ad operazione completata avremo che ogni client connesso a quel router, effettuerà le richieste DNS per risolvere i nomi di dominio, al nuovo server Dnsmasq che gira su RPi, dunque si avrà modo di reindirizzare la richiesta a nostro piacimento.

Inutile sottolineare quanto questo sia estremamente efficace e tutt’oggi usato per portare avanti devastanti attacchi di Phishing. Il browser non avà modo di ‘conoscere’ la differenza fra il sito reale e quello attualmente consegnato dal web server (su HTTP e non HTTPS).

HTTP VS HTTPS

Questo scenario ovviamente funziona solo su protocollo HTTP e assume l’utilizzo di un server DNS con i record alterati.

Per le richieste su protocollo HTTPS o qualunque altro protocollo basato su SSL, questo metodo non funzionerà, perchè il web server non può consegnare un certificato valido firmato da un’autorità di certificazione (Certificate Authority) al client. E questo porterà ad un errore di certificazione nel Browser.

A cura di hackerstribe.com

Articolo pubblicato sulla rivista ICT Security – Novembre/Dicembre 2015

Condividi sui Social Network:

ISCRIVITI ALLA NEWSLETTER DI ICT SECURITY MAGAZINE

Una volta al mese riceverai gratuitamente la rassegna dei migliori articoli di ICT Security Magazine

Rispettiamo totalmente la tua privacy, non cederemo i tuoi dati a nessuno e, soprattutto, non ti invieremo spam o continue offerte, ma solo email di aggiornamento.
Privacy Policy