Nel nostro terzo appuntamento (scriverò regolarmente ogni fine settimana) con la Sicurezza Informatica avrei dovuto parlarvi del DNS Spoofing ma avrei anche dovuto dare per scontati alcuni concetti molto importanti ed interessanti – di cui parleremo oggi – e molti di voi si sarebbero trovati col fare copia e incolla di qualche comando senza sapere cosa ci sia dietro. Parlerò quindi dell’ARP Spoofing, detto anche ARP Poisoning, la cui traduzione letterale è ‘avvelenamento dell’ARP’.

 Cos’è l’ARP?

L’ARP, abbreviazione di Address Resolution Protocol, è appunto un protocollo standard per la risoluzione degli indirizzi. Quando dobbiamo comunicare con un dispositivo e siamo in possesso del suo indirizzo IP abbiamo ancora bisogno del suo indirizzo MAC, ovvero il suo indirizzo fisico, per poter cominciare la comunicazione. Come facciamo ad ottenerlo? Inviamo a tutti i dispositivi nella rete (locale) un pacchetto di ARP Request contenente il nostro indirizzo MAC e l’indirizzo IP del dispositivo che vogliamo contattare, quando questo riceverà il pacchetto e riconoscerà il proprio indirizzo IP manderà una ARP Reply contenente il suo indirizzo MAC (ovviamente lo manderà solo a noi che abbiamo mandato la richiesta, avendogli dato il nostro indirizzo MAC con la richiesta stessa).

 Avveleniamo l’ARP…

Mettiamoci nelle vesti di un attaccante che abbia ottenuto accesso alla nostra rete locale (magari attaccando il WPS del nostro router) e vediamo come possiamo giocare con l’ARP. Il nostro obiettivo, in via del tutto generica, è quello di lanciare un attacco per ottenere delle informazioni su un altro utente connesso alla rete. Dobbiamo riuscire a leggere i messaggi che questo utente scambia col proprio router… Ma come fare? Avvelenando l’ARP!

PC02 vedra l’indirizzo IP del suo router 192.168.0.1 associato all’indirizzo MAC del computer attaccante PC03, 03-03-03-03-03-03. Stessa cosa per il router.

Quello che faremo è dire alla nostra vittima, tramite continue risposte ARP, che l’indirizzo MAC del router è il nostro e viceversa diremo al router che l’indirizzo MAC della vittima è il nostro. Semplice no? Il tutto è reso possibile in quanto il protocollo ARP non è dotato di un meccanismo di autenticazione. Per capire meglio guardate questa immagine che spiega il nostro ARP Poisoning:

Potremo quindi leggere tutte le comunicazioni tra il router e la nostra vittima in quanto passeranno attraverso noi.

All’avvelenamento!poison

Avrete bisogno di un paio di cose prima di cominciare: una macchina virtuale o un computer connessi alla vostra rete locale (non ho mai provato con il mio cellulare, potreste provare voi!), uno sniffer come ettercap (permette anche di effettuare l’ARP Poisoning) o wireshark (molto più istruttivo ma più complesso) e, per effettuare l’ARP Spoofing, arpspoof o quello che preferite voi. Tutti i tools sono installati di default sulla backtrack. Noi oggi scegliamo la strada più comoda ed useremo arpspoof per effettuare l’attacco MITM (Man In The Middle) ed ettercap per leggere il traffico che passa attraverso noi filtrando eventuali credenziali 🙂

Una piccola aggiunta: ad oggi quasi tutti i servizi usano connessioni sicure per passare i dati, sarebbe quindi difficile riuscire a decriptarli, useremo quindi un tool chiamato sslstrip per ‘forzare’ i servizi a non usare queste connessioni sicure (descriveremo il programma in futuro, per ora accontentatevi di usarlo e di questa non proprio veritiera descrizione).

Per prima cosa, dopo aver acceso la macchina virtuale (o fisica) e connessa alla nostra rete locale, dobbiamo abilitare l’IP Forwarding sulla nostra macchina (io uso una backtrack) in modo da poter reindirizzare i pacchetti che ci arrivano verso la giusta destinazione, altrimenti rimarrebbero fermi dopo esserci arrivati:

# echo '1' > /proc/sys/net/ipv4/ip_forward

Controllate che l’IP Forwarding sia attivo con:

# cat /proc/sys/net/ipv4/ip_forward

Che dovrebbe restituire 1 ad indicare che l’IP Forwarding è abilitato.

Dobbiamo ora avvelenare le tabelle ARP del router e della vittima. Apriamo un terminale e lanciamo (uno per scheda o terminale):

# arpspoof -i  -t
# arpspoof -i  -t

L’IP del router è solitamente qualcosa come 192.168.1.1 oppure 192.168.0.1, leggete sulle istruzioni del vostro router se non conoscete l’indirizzo o usate tool come netdiscover, per conoscere quello della macchina vittima basterà lanciare ipconfig (windows) o ifconfig (linux) sulla macchina virtuale e leggere l’IP associato (o, di nuovo, usare netdiscover). La mia macchina virtuale ad esempio è in 192.168.1.3, la mia backtrack in 192.168.1.15, il mio router in 192.168.1.1, la mia scheda di rete è chiamata wlan0.

Vedrete un output che continua a ripetersi (non fermate il comando ovviamente!), leggendolo vedrete che è esattamente quello che stavamo dicendo prima, mandiamo delle risposte ARP dicendo al router che il MAC della vittima è il nostro (primo comando) e viceversa (secondo comando)!

Manca solo sslstrip. Indirizziamo il traffico HTTP verso sslstrip così che possa fare il suo lavoro ed avviamo il programma:

# iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
# python sslstrip.py

Ora che il traffico passa attraverso noi dobbiamo leggerlo in qualche modo. Possiamo usare Wireshark per avere un quadro completo ma non è quello che ci serve oggi, useremo quindi ettercap per leggere eventuali credenziali:

Aprite una nuova scheda o un nuovo terminale e lanciate ettercap:

# ettercap -Tqu -i

Lanciate ettercap -h se volete avere informazioni sulle opzioni che state passando.

Bene, passiamo ora alla nostra macchina virtuale ed andiamo su un sito da cui effettuare il login, www.facebook.com ad esempio. Provate a mettere un nome utente ed una password qualunque (anche i vostri se volete), date invio e poi date un’occhiata ad ettercap:

Esattamente i dati che avevamo inserito! Se fossero stati reali avremmo ora potuto fare l’accesso al servizio con i dati appena “sniffati” 😉 Potete provare con qualunque servizio che abbia una form di login, tutte le credenziali appariranno su ettercap!

Qualcosa non va?

Mi è stato fatto notare dal lettore fork come non per tutti i servizi ettercap mostrerà le password, in particolare per Libero mail. Il problema è tutto nel modo in cui ettercap “filtra” i contenuti che gli arrivano: la sintassi di Libero non è riconosciuta da ettercap. Ci fermiamo qui? Certo che no! Abbiamo due soluzioni:

Metodo Manuale (universale)

Installiamo Wireshark e andiamo ad analizzare manualmente cosa succede sulla rete. Avviatelo, selezionate la vostra interfaccia di rete e cliccate su start. Alla voce “filter” mettete

ip.addr ==  and http.request.method == "POST"

Filtreremo così solo le richieste POST della macchina vittima. Fate login (ad esempio su Libero) dalla macchina vittima, tornate su Wireshark e andate su “Capture -> Stop”, dovreste avere un solo risultato, cliccateci e, nel riquadro in fondo, scorrete fino alla fine e vedrete qualcosa come “LOGINID=mitm_this_mail%40libero.it&PASSWORD=ThisIsMyPassword” che sono proprio le credenziali che ho inserito io! Per uno screen andate qui: http://tinypic.com/r/2lkqqlf/6
Smanettate il più possibile con Wireshark, farò un articolo sul programma appena possibile perché credetemi, è davvero divino!

Metodo Definitivo (per Libero)

Ettercap non riconosca la coppia LOGINID/PASSWORD, dobbiamo quindi modificare i filtri. Niente di più semplice: aprite il file “/usr/local/share/ettercap/etter.fields” (per la BackTrack) e aggiungete “loginid” nella parte relativa agli “[USER]”, l’unico filtro mancante per Libero. Salvate il file, riavviate ettercap e riprovate a fare login su Libero 😉