MITM versus HSTS: la tua password è al sicuro?

Nota: questo post è un proof of concept. Non mi assumo alcuna responsabilità riguardo all’uso che ne farete.

Il man in the middle (abbreviato MITM) è uno degli attacchi informatici più subdoli e pericolosi all’interno di una rete LAN. Come dice il nome stesso, l’hacker si pone al centro di una comunicazione tra la vittima e il server riuscendo a impersonificare ciascuno dei nodi coinvolti. In questo articolo non descriverò genericamente come viene fatto un attacco di tipo MITM, ma mi soffermerò su uno scenario preciso in cui tutti noi ci troviamo quando eseguiamo il login su un sito https, ad esempio la nostra banca. 

È credenza comune pensare che le informazioni trasmesse sul web tramite protocollo crittografato siano al sicuro e non decifrabili da utenti malintenzionati. Questo perché i siti che applicano uno strato ssl al normale traffico (in chiaro) http, fanno affidamento su un certificato rilasciato da un organo terzo, le cosiddette CA (Certification Authorities), le quali garantiscono la sicurezza e la privacy delle comunicazioni. In sostanza, quando il browser interpella un web server protetto da protocollo https, fra i due host viene negoziato un complesso algoritmo di cifratura a partire dalla chiave pubblica del certificato. Da qui il nome Public Key Infrastructure (PKI), che designa tutti quei soggetti e quelle fasi che concorrono a stabilire lo scambio sicuro dei dati. 

Tuttavia, com’è stato dimostrato negli ultimi anni, il sistema basato sulla combinazione di http con la tecnologia ssl, non è esente da vulnerabilità. Nel 2009, il brillante hacker conosciuto come Moxie Marlinspike, presentò al Black Hat DC una tecnica chiamata SSLStrip, capace di aggirare il tunnel crittografico creato da ssl dirottando tutto il traffico su una connessione non sicura. Ma in che modo ci riesce? Vediamolo nel dettaglio. 

In realtà, SSLStrip non è altro che un proxy che a sua volta agisce come man in the middle. L’attacker intercetta i reindirizzamenti https inviati dal server tramite una reply http, stabilendo con esso una connessione protetta, ma continuando a mantenere con la vittima una connessione non protetta. Successivamente, l’aggressore modifica i redirects da https a http, e una volta effettuato il downgrade della pagina, invia la risposta alla vittima, la quale non sospetterà affatto che tutto il suo traffico, compresi username e password, è stato intercettato e letto. 

Il principale punto di forza di SSLStrip risiede nella “propensione” dei vari browser a comunicare tramite protocollo (non sicuro) http piuttosto che https. In parole povere, se l’utente digita nella barra URL “miabancaonline.com”, il browser inizierà una comunicazione in chiaro, nonostante il traffico verrà subito reindirizzato su https. Per ovviare a questo problema, alcuni esperti di sicurezza si sono dati da fare ideando lo standard HSTS, tutt’oggi implementato dalla maggior parte dei browser e web server, grazie al quale questi ultimi “obbligano” i vari Google Chrome, Firefox e di recente (pare) anche Internet Explorer, a stabilire in futuro una connessione protetta col sito. 

Sebbene tale meccanismo abbia risolto in larga parte lo stripping di ssl, più avanti dimostrerò come un utente che effettua una request al server “pippo.com” per la prima volta, risulti potenzialmente esposto ad attacchi MITM. Per capirne il motivo, bisogna considerare il funzionamento di HSTS: dopo aver interpellato “pippo.com”, il nostro client riceverà una risposta http contenente un particolare header chiamato Strict Transport Security, con cui si avvisa il browser che le sessioni successive dovranno avvenire solo in maniera protetta, cioè utilizzando https. Diamo un rapido sguardo alla sintassi (in questo caso, ho scelto come esempio la pagina di login di libero.it):

La funzione Strict-Transport-Security prende due parametri: max-age e includeSubDomains. Il primo comunica all’user-agent (browser) il tempo, espresso in secondi, in cui il sito dev’essere accessibile solo tramite https, mentre includeSubDomains (opzionale) specifica che la protezione si applica a tutti i sottodomini della pagina, il che aumenta notevolmente il livello di sicurezza. 

Fatto questo doveroso e generalissimo excursus, direi che è arrivato il momento di passare alla pratica. Come attacker userò una macchina virtuale VMware su cui è installato Kali Linux 2.0 (ma vanno bene anche Parrot OS, BackBox o la distro che più vi piace). Per effettuare lo sniffing dei pacchetti, avremo bisogno di un tool apposito. Io ho scelto il validissimo Bettercap, un vero e proprio MITM framework che implementa il supporto a SSLStrip+ (o SSLStrip2) di LeonardoNve. La vittima verrà reindirizzata a un sottodominio wwww e tramite un DNS spoofing tale sottodominio verrà risolto. Questa tecnica è necessaria per poter aggirare, in determinate circostanze, la policy HSTS. 

Ma bando alle ciance e passiamo all’azione.  :D

Dopo esserci autenticati come utenti root, diamo il comando netdiscover per trovare l’ip del nostro bersaglio. L’output che ci viene restituito è una serie di host connessi alla rete. Il primo indirizzo identifica il gateway. 

A questo punto, lanciamo Bettercap in modalità SSLStrip con il comando:

 bettercap -X -T [ip-target] --proxy -P POST

È importante tenere a mente che di default l’interfaccia di rete è impostata su eth0. Se state operando su un’interfaccia diversa, ad esempio wlan, potete cambiarla aggiungendo l’opzione:

 -i [your-network-interface]  

Per essere certi di quale sia la nostra interfaccia, lanciamo da terminale il comando ifconfig: 

Ora dobbiamo attendere che la nostra vittima inserisca username e password in un form. Nel frattempo, Bettercap intercetterà tutte le connessioni restituendoci i log. :)

Come si vede dall'immagine, l’attacco è andato a buon fine e le credenziali sono state strippate. Ricordo che questo metodo non funziona sui siti che rientrano nella lista HSTS precaricata nel browser, ma in seguito esploreremo altre tecniche con cui proveremo ad assumere il controllo di un sistema remoto. 

Nb: Bettercap è scritto in Ruby. Per installarlo correttamente, è necessario che tutte le dipendenze siano soddisfatte (build-essential, ruby-dev, libpcap-dev).