Intercettazione traffico HTTPS e recupero dati sensibili

E’ possibile recuperare username e password trasmesse in HTTPS? In alcuni casi si. In pratica si tratta del recupero dei dati sensibili trasmessi da altri client della rete locale (credenziali di login tipo facebook, gmail, home banking e chi più ne ha più ne metta). Il trucchetto è abbastanza vecchio e collaudato; oltre a mostrare come eseguirlo correttamente vedremo  le contromisure (e qui ci tengo particolarmente) che finalmente sono state adottate dalla maggior parte dei web server: purtroppo non tutti sono stati aggiornati e moltissimi soffrono ancora di questo tipo di exploit  (siamo nel 2014!).

HTTPS da solo non basta, serve anche la testa! 🙂

Come funziona

L’attacco si definisce propriamente come un MITM (Man in the Middle) nel quale andremo ad utilizzare alcuni specifici tool:

  • SSLStrip
  • Arpspoof (parte integrante del pacchetto dSniff)
  • distro Linux KALI (il nuovo nome della vecchia BackTrack)

http://www.thoughtcrime.org/software/sslstrip/

http://en.wikipedia.org/wiki/DSniff

Durante l’attacco viene temporaneamente rimossa la protezione SSL impostando in modo trasparente l’intero traffico del client vittima in normali sessioni HTTP (invece di HTTPS). Questo permette la cattura e lettura dei dati trasmessi dalla macchina target al server e viceversa.  L’attacco funziona perche’ l’attuale infrastruttura PKI di protezione del web non impone l’uso dell’ HTTPS per tutta la sessione di navigazione dell’utente: si può tranquillamente richiedere HTTP per alcuni elementi delle pagine web visitate (immagini ad esempio…), poi passare ad HTTPS per altri elementi (form di login…), poi di nuovo ripassare ad HTTP e cosi’ via.

https2

Utilizzando il tool SSLStrip e’ possibile forzare le parti in comunicazione (server e client target) ad utilizzare sempre ed esclusivamente HTTP invece della versione sicura HTTPS. Facendo passare questo traffico attraverso la nostra macchina (da qui il man in the middle) possiamo collezionare e leggere lo stream di dati trasmessi (in chiaro!).

https

Un po’ di background…

HTTPS e’ il protocollo standard di protezione del traffico in internet. Viene utilizzato per garantire  trasferimenti riservati di dati nel web. Funziona aggiungendo un livello di crittografia (SSL, Secure Socket Layer) al normale traffico HTTP.

Normalmente il traffico HTTPS puo’ essere intercettato ma non decodificato perche’ cifrato. Il traffico HTTP invece puo’ essere sia intercettato che letto e decodificato (essendo ovviamente in chiaro).

I siti web utilizzano HTTPS quando l’utente deve fornire le proprie credenziali di accesso al sito stesso oppure inviare altri dati sensibili ma possono anche utilizzarlo per tutta la durata della navigazione (come fa GMail, servizi di posta in genere, quasi tutte le online banking e molti altri…).

Questi servizi web non impongono HTTPS e il browser è libero di collegarsi in semplice HTTP.

Esecuzione dell’exploit

La prima fase consiste nel “mettersi in mezzo”, ossia modificare il routing di rete affichè tutto il traffico della nostra vittima passi non direttamente al gateway ma venga redirezionato a noi. In soldoni ci impersonifichiamo come gateway della rete wifi (o cablata), prendiamo tutto il traffico generato dal client vittima e lo passiamo al vero gateway; facciamo anche il contrario: tutto il traffico del gateway verso di noi lo passiamo al client vittma. Ci mettiamo letteralmente in mezzo al canale di comunicazione tra client vittima e gateway.

Per far questo prendiamo la nostra distro KALI Linux (io ho utilizzato una macchina virtuale, va bene lo stesso), ci colleghiamo alla rete, otteniamo l’indirizzo IP ed abilitamo l’IP forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward"

ipforward_enable

L’IP forwarding va abilitato affinchè i pacchetti possano passare attraverso la nostra macchina in modo trasparente.

A questo punto aggiungiamo una regola al firewall iptables che ci permetterà di acquisire il traffico del client vittima verso di noi:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 12345

iptbles_rule

Il client vittima naviga in rete normalmente e questa regola del firewall ci permetterà di acquisire tutto il suo traffico su porta 80 e redirigerlo localmente sulla porta 12345. In ascolto sulla 12345 metteremo SSLStrip che provvederà a modificare le richieste originali di connessione HTTPS prodotte dal client vittima in semplici richieste HTTP.

Occorre ora convincere il client vittima che siamo noi il vero access point e non quello col quale sta comunicando. Per far questo andremo ad alterare le tabelle di routing ARP della rete wifi, in gergo faremo un ARP poisoning (o ARP spoofing) che potremmo tradurre in “avvelenamento della cache ARP” 🙂 .

In pratica iniziamo ad iniettare una gran quantità di pacchetti ARP nella rete; questi pacchetti comunicano agli altri client della rete che il nostro indirizzo MAC è quello del gateway. In questo modo costringiamo il client vittima a passare da noi prima di uscire su internet. Questa informazione errata può essere inviata ad un singolo client di rete (la vittima designata) oppure mandata in broadcast a tutti i partecipanti.

L’arpspoofing è possibile in quanto il protocollo ARP non prevede autenticazione: è possibile comunicare la verità (“io non sono il gateway”) o semplicemente iniettare informazione errata (“io sono il gateway”).

Apriamo una nuova console ed avviamo arpspoof:

arpspoof -i eth0 10.0.0.101 10.0.0.1

10.0.0.101 è il client vittima (il mio pc 🙂 ), 10.0.0.1 il gateway ufficiale (spesso l’AP della rete wifi)

arpspoof_in_action

fatto ciò mettiamo in ascolto SSLStrip sulla porta 12345 e lasciamo che logghi tutto il traffico cifrato del client vittima verso l’esterno.
Con Arpspoof che lavora in background, apriamo una nuova console ed avviamo SSLStrip:

sslstrip -l 12345

di default SSLStrip catturerà solo il traffico SSL POST (quindi solo richieste POST sotto HTTPS) ma possiamo anche configurarlo per ricevere anche tutto il traffico SSL o tutto il traffico HTTP/HTTPS.

sslstrip_runningA questo punto non ci resta che passare al client vittima, navigare in un sito “protetto” da HTTPS e provare ad esempio ad accedere al sito con le nostre credenziali.

Allo scopo mostrerò come recuperare le credenziali in HTTPS da un noto sito italiano. Questo sito non è stato ancora messo completamente in sicurezza e l’exploit è ancora valido. Speriamo ovviamente che venga sistemato il prima possibile.

Andiamo alla login del sito:

poste_loginColleghiamoci con le nostre credenziali. La richiesta arriverà prima ad SSLStrip (siamo in una configurazione MITM, quindi tutte le richiste passano dalla distro Kali Linux) che provvederà a trasformare la richiesta di connessione HTTPS in una HTTP normale. SSLStrip logga su file di testo tutta la transazione, compresi i dati di login.

A questo punto ritorniamo sulla distro ed apriamo il file di log di SSLStrip (ssltrip.log). Troveremo la richiesta POST che il client ha effettuato verso il sito. Le credenziali sono leggibili in chiaro:

password_highlight

Fortunatamente l’exploit non funziona su una WAN, occorre che il client target sia nella propria rete locale.

E quindi?

E’ stato da poco introdotto (da poco per modo di dire,  nel 2012) l’HTTP Strict Transport Security o HTST

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Questo meccanismo impone l’uso di HTTPS per tutta la durata di navigazione del sito. Il browser semplicemente si rifiuta di connettersi al sito tramite il semplice HTTP. La policy, per poter funzionare correttamente, deve essere condivisa ed accettata sia dal server remoto che dal browser. Qui una rapida descrizione:

https://scotthelme.co.uk/hsts-the-missing-link-in-tls/

https://www.eff.org/deeplinks/2014/02/websites-hsts

Ad oggi molti siti internet si sono adeguati tra i quali GMail, Paypal e Twitter. Molti altri, come ad esempio Facebook stentano ad implementarla (la versione mobile è scoperta) e sono quindi ancora vulnerabili. Come dicevo anche i browser devono essere compatibili con HTST, non tutti lo sono e alcuni solo in parte come ad esempio Internet Explorer di Microsoft.

Alcune soluzioni per prevenire l’exploit:

https://serverfault.com/questions/417173/enable-http-strict-transport-security-hsts-in-iis-7

http://www.debian-administration.org/article/662/Enabling_HTTP_Strict_Transport_Security_on_debian_servers

Leave a Reply

avatar
Riccardo

Ciao Gianluca,
ho Kali Linux su VirtualBox e sto provando qualche trucchetto dal terminale, in particolare per la gestione della rete. Ho trovato questa tua guida e ho provato ad applicarla ma il risultato è…un po’ diverso… Ti spiego: ho eseguito da un terminale i comandi echo 1 > /proc/… e iptables… dopodiché ho individuato l’indirizzo IP del mio PC all’interno della rete e dopo aver aperto un altro terminale ho avviato arpspoof -i eth0 -t 192.168.1.3 192.168.1.1 (dove il primo IP è appunto quello del mio PC). Tutto funzionerebbe apparentemente ma…quello che ottengo è un blocco della connessione internet per quell’indirizzo IP! Ho ripetuto la procedura inserendo l’IP del mio cellulare ed effettivamente viene bloccata anche quella…
Cosa può esserci che non va?
Ti ringrazio. Ciao!

Vale

C’è un modo per aggirare il problema dell’HSTS utilizzato dai browser che mi bloccano la navigazione in rete( dato che non permettono la navigazione in http) ?

vins

Questo metodo funziona solo su protocollo HTTP , ma con i nuovi aggiornamenti e le nuove sicurezze come : protezione SSL , non riuscirai mai a intercettare le password . Questo perche’ non avviene il reindirizzamento dalla pagina da HTTP a HTTPS , ovvero la pagina fake . Questo metodo va benissimo ad esempio se siete collegati in una rete lan , li dove sono connesse telecamere di videosorveglianza , a quel punto una volta avviato “attacco” , bastera’ aspettare il primo client che si connette e il gioco è fatto…….

Nick

Ciao, il log sslstrip non mi restituisce niente…hai suggerimenti?
Grazie

Michele

Non riesco a capire come mai per intercettare il traffico SSL, tipicamente su porta 443, faccio un PREROUTING sulla porta 80, tipicamente dedicata al traffico non cifrato. Ho paura che sia un errore, ripetuto su più tutorials…

wpDiscuz