DNS spoofing: differenze tra le versioni

Versione delle 10:10, 22 lug 2010

Versione delle 10:57, 22 lug 2010

Riga 6:

Gli attacchi di tipo [[man in the middle]] consistono nel deviare i pacchetti in una comunicazione tra due host verso un attaccante, che fingerà di essere il mittente o destinatario vero.

La struttura è la seguente: una comunicazione a due dove l'attaccante s’interpone tra i due hostpost vittime A e B.

La struttura è la seguente: una comunicazione a due dove l'attaccante s’interpone tra i due host vittime A e B.

[[File:Mansthemiddle.PNG|center|thumb|]]

L'attaccante riceverà pacchetti contenenti richieste da ambo due le parti. Il suo ruolo è quello d'inviare i pacchetti che riceve verso la giusta destinazione. In questo modo i due host attaccati non si accorgeranno che la comunicazione è stata alterata. In base alle abilità dell'attaccante di alterare la connessione l'attacco prende il nome di [[man in the middle]] half duplex o [[man in the middle]] [[full duplex]].

In base alle abilità dell'attaccante di alterare la connessione l'attacco prende il nome di [[man in the middle]] half duplex o [[man in the middle]] [[full duplex]].

[[File:Half&full.jpg‎|center|thumb|nome]]

Un possibile scopo di queste tipologie d'attacchi può essere quello di rubare delle informazioni personali oppure monitorare e alterare la comunicazione tra due utenti.

Riga 40 ⟶ 37:

#Route mangling

Per comprendere queste tipologie d’attacchi è necessario avere un ideaun’idea di come funzioni lo scambio di record DNS tra server DNS.

==DNS-Query==

Il protocollo DNS ha il compito di trasformare l'indirizzo simbolico (ad esempio www.prova.org) in indirizzo numerico o IP (ad esempio 202.159.XXX.XXX). I server DNS sono organizzati secondo una struttura ad albero gerarchica, in cui ogni nodo corrisponde ad un dominio. I server DNS scambiamo record DNS mediante tre tipi di messaggi: query, responce e update. Supponiamo ad esempio di voler contattare tramite un browser il sito www.prova.org. Quest’operazione consiste in una serie di DNS query. Il server DNS dopo aver trovato l'indirizzo ip tramite varie chiamate ad altri server DNS lo comunica alla macchina richiedente con un DNS responce che deve contenere l’IP giusto (di fatto, se al posto del sito scriviamo l’IP dell’esempio 202.159.XXX.XXX il sito sarebbe lo stesso raggiungibile).

Supponiamo ad esempio di voler contattare tramite un browser il sito www.prova.org. Quest’operazione consiste in una serie di DNS query.

Il server DNS dopo aver trovato l'indirizzo ip tramite varie chiamate ad altri server DNS lo comunica alla macchina richiedente con un DNS responce che deve contenere l’IP giusto (di fatto, se al posto del sito scriviamo l’IP dell’esempio 202.159.XXX.XXX il sito sarebbe comunque raggiungibile).

[[File:Dnsgerarchy.JPG|center|thumb|]]

La struttura reale di una query è molto più complessa ed articolata ma semplifichiamo il tutto ed utilizziamo solo ciò che serve ai fini dell’attacco.

==DNS Spoofing==

Riga 57 ⟶ 52:

*Manomissione fisica del DNS

I messaggi DNS viaggiano sulla rete utilizzando il protocollo UDP. La sicurezza è affidata al protocollo DNS il quale ha dei punti deboli. L’attacco sfrutta alcuni campi delle DNS query:

La sicurezza è affidata al protocollo DNS il quale ha dei punti deboli. L’attacco sfrutta alcuni campi delle DNS query:

*l’ID (evidenziato in grigio) è un campo di 16 bit che individua la transazione.Viene generato dall’host che ha originato una DNS query; le risposte devono avere il medesimo id altrimenti l’host non le accetterà.

*Il campo QUESTION (sempre in grigio) contiene il nome di dominio richiesto e il tipo di record che devono essere inviati come risposta .

Una DNS query la possiamo immaginare nel modo seguente:

[[File:Pachets dns.JPG|center|thumb|]]

L'obbiettivo dello spoofing è modificare la corrispondenza tra indirizzo ip e nome del sito contenutecontenuti nelle risposte.

===Simulazione delle risposte del DNS(in una rete locale o da locale a remoto)===

Questa tipologia d'attacco deve considerare l’ID della query. L’attaccante intercetta la richiesta di un client, memorizza l'ID contenuto all’interno del messaggio, e crea una falsa risposta con il giusto ID copiato precedentemente. Alla fine rispedisce il tutto al client che ha fatto la query. Affinché l'attacco riesca è necessario rispondere con l’ID atteso al client prima del vero server. In questo modo il client crederà che l’host attaccante sia il server. Infine è necessario anche intercettare le eventuali reverse query (quelle che traducono indirizzo ip a nome simbolico). A questo punto il client invierà tutti i pacchetti destinati a quel nome simbolico all'attaccante, il quale può:

Affinché l'attacco riesca è necessario rispondere con l’ID atteso al client prima del vero server. In questo modo il client crederà che l’host attaccante sia il server.

Infine è necessario anche intercettare le eventuali reverse query(quelle che traducono indirizzo ip a nome simbolico).

A questo punto il client invierà tutti i pacchetti destinati a quel nome simbolico all'attaccante, il quale può:

#svolgere la funzione di proxy e creare una connessione con il client e una con il server e rimandare ogni richiesta di servizio proveniente dal client al server e ogni risposta dal server al client

#non contattare il server reale e simulare i servizi offerti dal server.

Nel caso in cui non si possa intercettare una DNS query si può provare un attacco di tipo blind.

La simulazione delle risposte del DNS è facilmente intercettabile. Infatti, utilizzando un server DNS diverso si può notare la differenza delle risposte. Inoltre l'IP dell'attaccante è presente nell’intestazione dei pacchetti IP che contengono i pacchetti UDP con le risposte DNS contraffatte.

===Cache poisoning (in remoto)===

Questa tipologia d'attacco consiste nel creare record DNS fasulli ed inserirli nella cache del name server.Un name server non può contenere tutte le corrispondenze ip/nome simbolico, pertanto utilizza una cache con parti di taletali corrispondenze con TTL (Time to live, ovvero un periodo di vita dei dati nella cache). La tecnica del cache poisoning si basa sull’inserimento in cache di record falsi con un TTL molto grande. Il problema, che si pone di fronte ad un attaccante, è come illudere il DNS Server in modo che accetti i record avvelenati. Ci sono vari modi per eseguire un cache poisoning e sono i seguenti :

La tecnica del cache poisoning si basa sull’inserimento in cache di record falsi con un TTL molto grande.

Il problema, che si pone di fronte ad un attaccante, è come illudere il DNS Server in modo che accetti i record avvelenati.

Ci sono vari modi per eseguire un cache poisoning e sono i seguenti :

*Il DNS server si “avvelena” da solo

Un host fa una richiesta di un nome di dominio (ad esempio www.prova.org) al suo server DNS, se tale indirizzo non è in memoria, parte una query al DNS del dominio corrispondente. Se questo server è stato avvelenato risponderà al server DNS con una mappatura sbagliata e di conseguenza si avvelenerà anche il primo server DNS (avvelenamento temporaneo poiché i dati nella cache hanno un time to live).

[[File:Autopoison.JPG|center|thumb|]]

Riga 100 ⟶ 88:

*Il server vittima è costretto ad inviare una query al DNS fasullo della rete attaccante.net, e questa query contiene anche l’Id

*L’attaccante chiede la traduzione di un record che vuole avvelenare e spera di poter inviare lui stesso la risposta con l’Id corretto prima del DNS autoritario (race condition).

Se il server cambia gli ID nelle DNS query quest’attacco non funziona più, ma l’attaccante può fare tutte le prove che riesce ad eseguire prima che arrivi la risposta dal DNS autorevole. I possibili diversi identificativi sono 65636 (2^16), ovvero l’attaccante deve indovinare un intero in questo range.

Se l’attacco riesce, a questo punto qualsiasi utente che usufruirà di quel determinato server DNS ed eseguirà query per siti attendibili riceverà come risposte contraffatte dovute all’avvelenamento della cache. Questa tipologia d’attacco non è facilmente intercettabile. Si può essere sotto attacco per un lungo periodo senza che ci si accorga facilmente d'esserlo, tuttavia è quasi impossibile trovare name server vulnerabili a quest’attacco ormai considerato obsoleto.

Questa tipologia d’attacco non è facilmente intercettabile. Si può essere sotto attacco per un lungo periodo senza che ci si accorga facilmente d'esserlo, tuttavia è quasi impossibile trovare name server vulnerabili a quest’attacco ormai considerato obsoleto.

===Manomissione fisica del DNS===

Questa tipologia d’attacco è molto semplice, ma solo se si ha accesso a un name server e possibilità di modificare direttamente i record cambiando manualmente gli indirizzi ip di interesse per l’attaccante.

===Contromisure===

Riga 117 ⟶ 105:

*Altra soluzione è utilizzare un server che genera il campo id dei pacchetti in maniera casuale e allo stesso modo sceglie un numero di porta di comunicazione; queste contromisure aumentano in maniera esponenziale la sicurezza del DNS.

*In merito al poison cache ci limitiamo a affermare che è ormai impossibile trovare server vulnerabili a questo tipo d’attacco considerato obsoleto.

===Esempio di DNS spoofing===

L’esempio utilizza la tecnica di simulazione del DNS su una rete locale con il programma ettercap, usando come configurazione quella d’esempio contenuta nel file etter.dns (per vedere tale configurazione basta aprire il file etter.dns del programma stesso). Per eseguire l’esempio è necessario un personal computer con sistema operativo linux ed ettercap installato.

Sia:

Riga 128 ⟶ 117:

host2 = topolino con ip 192.168.1.5 la vittima

topolino vuole collegarsi al sito www.microsoft.com (utilizzeremo la configurazione di default di ettercapd’ettercap) e pippo vuole eseguire una simulazione delle risposte del DNS su topolino, per far ciò esegue il seguente comando,

pippo: ettercap -T -M arp:remote /192.168.1.9/ /192.168.1.1/ -P dns_spoof <ref name="paper mint">[http://www.blackhats.it/en/papers/Paper-mitm.pdf blackhats.it]</ref>

Con questo comando <ref name="paper mint" /> digitato da console, pippo (computer host 1) 192.168.1.9 si è finto gateway (192.168.1.1) e ha reindirizzato le richieste di topolino (host 2) 192.168.1.5 indirizzate a www.microsoft.com direttamente su www.linux.com, ovviamente per far funzionare il tutto dobbiamodeve configurare il reindirizzamento nel seguente modo (cosa già fatta come esempio all’interno del file) : pippo: nano /usr/share/ettercap/etter.dns

pippo: nano /usr/share/ettercap/etter.dns

[[File:Etter.JPG|center|thumb|]]

In questo modo vengono reindirizzate tutte le connessioni di microsoft su linux. Nel caso in cui si vuole reindirizzare un generico sito su un altro indirizzo basta aprire il file etter.dns con nano (nano /usr/share/ettercap/etter.dns) o con qualsiasi altro editor di testo, ed analizzare la prima parte del file che si presenta nel seguente modo:

[[File:Structs.JPG|center|thumb|none]]

In questa prima parte del file spiega come devono essere strutturate le query, per cuiperciò se si vogliono reindirizzare più siti basta aggiungere al file più strutture identiche a quelle dell’esempio, dove al posto di microsoft inseriamo il sito che si vuole reindirizzare e al posto dell’indirizzo ip di linux utilizamo l’indirizzo ip di dove si vuol reindirizzare la query.Va ricordato che bisogna anche cambiare la reverse query (PTR).

===Tools applicativi===

Riga 159 ⟶ 148:

*OS fingerprinting per il riconoscimento dei sistemi operativi sugli Host trovati in rete;

*Possibilità di chiudere una connessione o inserire caratteri estranei;

*Supporto di plugin vari che a loro volta presentano funzioni quali DNS spoofing, PPTP sniffing

Dsniff:

Riga 167 ⟶ 156:

Zodiac:

Zodiac è un programma che analizza il protocollo DNS. Permette di osservare il traffico su rete, infatti analizza come sono assemblati e disassemblati i pacchetti. Il software offre degli strumenti per chi non è esperto del settore per:

#vedere come funziona il protocollo DNS