A cura di: Fernando L. Curzi (Team Hackerhood)
Siamo abituati a percepire il Phishing come l’insieme di tecniche appartenenti ad un mondo subdolo, quello del social engineering in cui si fa’ uso massiccio di link che puntano a site web fake, per truffare le persone in internet. Nelle campagne di Spear Phishing, spesso i truffatori si rivelano con scarse capacità informatiche che sono riscontrate da un evidente utilizzo di tool automatizzati o dalla generazione di domini fittizi che all’occhio anche di non esperti sono immediatamente identificati. Altre campagne di phishing riguardano invece l’invio massivo di mail gestite da organizzazioni criminali e botnet, ma sono anch’esse tecniche riscontrabili dalla vittima perché ciò che le accomuna tutte è semplicemente l’interazione della vittima nello scenario di attacco.
A volte sento in giro e leggo ancora post sui social del tipo: “Quei dati viaggiano in https non si può leggerne il contenuto perché è un protocollo con certificato TLS, è cifrato! come lo filtri? Poi devi considerare HSTS che ne migliora le prestazioni, è impossibile! Devi trovare la chiave prima.. ecc
Poiché sta diventando pesante ascoltare tutte queste dicerie, ho preferito scrivere questo tutorial in modo da mostrare prima di tutto quanto siano pericolose queste tecniche in ambito di reti locali, sfatando un po’ di leggende metropolitane sull’ https e l’HSTS e nel contempo permettere anche di intervenire sull’hardening delle policy HSTS che come vedremo alla fine dell’articolo, sono fortemente raggirabili.
Cosa succede quando in una rete locale utilizzando tecniche più sofisticate, senza che la vittima venga indotta a cliccare nessun link o a prendere delle decisioni piuttosto che altre, l’attaccante prepari un attacco mirato al filtraggio di dati sensibili da un sito di e-banking, da un marketplace, un gestionale o qualsiasi altro applicativo?
Ho preparato un semplice laboratorio con tre macchine su Vmware che ve lo spiega:
-1 Windows server 2016 che fungerà da server Dhcp
-1 Macchina Kali Linux attaccante
-1 Macchina Windows 10 vittima
Per prima cosa ho configurato il server DHCP sulla macchina Windows Server 2016 con un pool di indirizzi settato a 10 lease per IP (10.10.30.43 a 10.10.30.53), questo significa che ogni volta che un host si connetterà alla rete il server DHCP rilascerà un indirizzo IP incluso in questo intervallo.
Sulla mia macchina attaccante Kali Linux vediamo che è stato già assegnato un indirizzo IP dal server DHCP, questo ci informa che il settaggio è avvenuto in maniera corretta, abbiamo ricevuto l’indirizzo IP 10.10.30.43.
Procediamo con una tecnica semplice chiamata Mac spoofing, utilizziamo il tool Macchanger e generiamo un nuovo indirizzo MAC che si sostituirà a quello reale della scheda di rete della macchina Kali.
Cosa è successo?
Il nostro server DHCP ci informa che è stato regolarmente assegnato un nuovo ip alla macchina Kali Linux sul nuovo MAC address generato, quindi tutto funziona correttamente, o meglio… per essere più precisi se accadesse su un sistema reale e non in quello di laboratorio non sarebbe un meccanismo sicuro in quanto lo switch probabilmente non disporrebbe di adeguate misure di sicurezza come l’anti-DHCP snooping, l’assenza di questi meccanismi di sicurezza permetterebbe a malintenzionati interni alla rete di rubare indirizzi IP o svolgere attacchi DOS al dhcp semplicemente con la generazione casuale di mac address fittizi.
L’Anti DHCP snooping come anche l’Anti Arp sono meccanismi di sicurezza che permettono agli switch di rilevare e bloccare il furto di indirizzi ip su una specifica porta dello switch o bloccare attacchi di poisoning alle Arp table, essenziali per svolgere dopo una vasta categoria di attacchi della classe MITM (Man in the Middle).
MAC Flodding e Rogue DHCP Server
Procederemo prima con la tecnica di MAC Flodding sul DHCP Server, ma prima di questo prepariamo un DHCP Server Fake che si andrà a sostituire a quello reale, questa è una situazione che si genera a causa dalle vulnerabilità intrinseche delle architetture locali, quando un server DHCP o DNS si rende indisponibile per altre cause, gli host nella rete si collegheranno al primo server utile che troveranno disponibile.
Per lo scopo utilizzerò un modulo ausiliario di msfconsole con il quale mi metterò in ascolto per servire un DHCP server da me gestito. La seguente è una configurazione di un attacco Rogue DHCP Server su Kali Linux, il server DHCP fake andrà a sostituirsi a quello reale che gira sulla macchina Windows Server 2016
per permettere questo ‘switch’ tra server reale al server fake, l’attaccante dovrà saturare prima il lease di indirizzi IP attraverso un attacco “Denial of Service” che prende il nome di Mac Flodding, per farlo procederemo con uno strumento scritto in python chiamato dhcpig.py, il comando è:
$dhcpig eth0
questo semplice comando permette di saturare il lease di intervalli rendendo praticamente il server dhcp fuori uso, una conseguenza della saturazione degli indirizzi ip assegnabili, fissati in precedenza a 10.
ed è proprio in questo momento che interviene il nostro server dhcp fake che assegna un indirizzo ip ad una nuova macchina windows 10 di una probabile vittima che si sta collegando in rete,
l’indirizzo ip assegnato a windows 10 è 10.10.30.201 che fa parte dell’intervallo settato nel modulo dhcp di msfconsole, possiamo quindi controllare ora il DNS server della vittima.
Local Phishing – SSL-Strip e HSTS Hijacking
Dopo che un attaccante abbia svolto queste operazioni, potrebbe dirottare le richieste web su un dns server in sua gestione in cui modificherà i record al fine di veicolare una pagina ufficiale come facebook.com, gmail.com o poste.it, su un indirizzo ip che ospiterà una pagina web fasulla ma con le stesse caratteristiche dell’originale, questo senza che la vittima (anche di un livello più avanzato) si accorga di nulla poiché l’url digitato sul browser sarà quello reale che sta digitando in quel momento l’utente.
Quindi niente redirect, certificati SSL-TLS non funzionanti o caratteri cirillici sostitutivi nel dominio che potrebbero far trapelare la non autenticità della pagina, niente di tutto ciò.
La dimostrazione sara’ suddivisa in tre step. Il primo lo svolgeremo utilizzando un browser che per la prima volta richiederà la pagina ufficiale di un sito web (es. un browser di un pc formattato), in modo da mostrare come una gran parte degli applicativi web non implementino lato server misure efficaci contro questa prima debolezza di hsts, nel secondo e terzo step vedremo delle tecniche più avanzate di SSL stripping e i bypass HSTS ( Strict Transport Security).
Step 1 – Local Phishing
Procediamo con DNSchef un tool preinstallato su Kali Linux che ci permetterà di registrare record fittizi e quindi creare un dns server gestito dall’attaccante, ricordandosi nel contempo di settare (come abbiamo già fatto su msf) la voce DNS server con il nostro indirizzo ip che dovrà rimanere in ascolto.
intanto con Setoolkit un’altro tool di Kali Linux utilizzato per gli attacchi di social engineering, preparo il clone del sito delle poste e lo metto in ascolto in locahost.
dalla macchina vittima windows 10 proviamo ad accedere con il browser di Firefox a poste.it
Saremo reindirizzati sul mio server in cui ho esposto il clone del sito, questo accadra’ perché il server di poste non implementa politiche di hsts ma solo di inefficienti meccanismi di redirect a https che come abbiamo appena visto sono stati bypassati.
La politica HSTS viene definita nelle Request Header sotto la voce “Strict-Transport-Security”, come possiamo vedere nell’header di una richiesta a Linkedin, vedremo tra qualche minuto perché ho scelto questo dominio
Nella realtà scenari di questo genere non accadranno quasi mai, ovvero in circostanze di un pc che richiede per la prima volta una pagina web durante un attacco man in the middle e ci sarebbero non poche limitazioni per filtrare dati sensibili con tool simili a setoolkit in questo modo. Quello che faremo ora è bypassare questi meccanismi sul redirect http e HSTS.
Da non dimenticare che un paio d’anni fa’ , prima dell’introduzione di hsts, esisteva una tecnica chiamata SSL stripping, questa permetteva ad un malintenzionato di dirottare le connessioni su protocolli non cifrati (http) creando dei malfunzionamenti indotti su quelli cifrati (https) permettendo di declinare i certificati e permettere a malintenzionati di filtrare tutti i dati trasportati dal protocollo, oggi queste tecniche funzionano solo su applicativi in cui non sono impostate le misure HSTS, di seguito vedremo comunque entrambi i bypass.
Step 2 – SSL Stripping
Bettercap è uno strumento di pentesting tutto italiano sviluppato da EvilSocket e nel nostro team “Hackerhood” collabora uno dei suoi sviluppatori!, è il coltellino svizzero per eccellenza negli attacchi man in the middle e di seguito vedremo due modalità di utilizzo per sfruttare tutta la sua potenza nell’ SSL stripping e Hijacking HSTS.
Bettercap può essere avviato da interfaccia grafica o da riga di comando
Procediamo con l’SSL stripping: avviamo bettercap sull’interfaccia di rete e scarichiamo i caplets, attiviamo lo sniffing e l’arp spoofing per permettere a bettercap di intercettare le richieste.
È possibile raffinare ulterioriormente l’arp spoofing con il comando: >help arp.spoof
Appariranno tutte le opzioni disponibili, tra le quali arp.spoof.fullduplex che consente l’arp spoofing sia sul target che sul gateway, ma se il router dispone di protezioni di ARP spoofing già citate all’inizio del tutorial la configurazione fallirà, è consigliabile comunque attivarla sempre, quindi i comandi sono:
>set arp.spoof.targets 10.10.30.201
>arp.spoof.fullduplex true
>arp.spoof on
Diamo ora un occhiata alle funzioni che abbiamo attivato con il comando >help:
Verifichiamo i caplets installabili con il comando >caplets.show
I caplets sono script aggiuntivi che permettono a bettercap di estendere le proprie funzioni e sono personalizzabili, quello che a noi serve è il modulo hstshijacking/hstshijacking, attiviamolo con il comando >hstshijacking/hstshijacking:
lo sniffing è già attivo possiamo partire.
Sulla macchina vittima richiediamo qualche dominio, ne ho presi diversi italiani.
Da quanto ho potuto constatare nessuno dei campioni di dominio testati adotta come misura di sicurezza l’HSTS sul server, questa è una miss configuration molto grave che potrebbe causare un filtraggio in chiaro di dati sensibili degli utenti che accedono in aree riservate del dominio, i certificati TLS o altri redirect con bettercap configurato in questo modo non manterranno, lo possiamo vedere di seguito:
il primo dominio è https://poste.it, come vediamo dall’header non adotta hsts
lo stripping funziona, stiamo filtrando dati dall’area riservata e questa non è la pagina fake vista prima clonata con setoolkit!
Procediamo con altri domini, ne ho presi alcuni ma vi comunico in anticipo che la lista italiana è abbastanza lunga:
Step 2 – HSTS Hijacking
HSTS è una policy di sicurezza che dovrebbe essere implementata sui server che espongono acceso ad aree riservate dei siti web, ha lo scopo di bloccare attacchi al funzionamento dei certificati SSL-TLS e proteggerli dal dirottamento DNS e sniffing passivo e attivo, grazie all’utilizzo dei cookie il web server comunica con i browser e dopo aver ricevuto una prima richiesta da un preciso client (l’esempio di un browser di pc formattato o che non ha mai richiesto quel sito), obbliga quel client dalla seconda richiesta in poi fino alla scadenza dei cookie a comunicare con esso esclusivamente utilizzando https quindi con una crittografia end-to-end, non potremmo quindi utilizzare Bettercap configurato senza i caplets hsts per sferrare un attacco alla crittografia.
Sappiate però che bettercap può essere avviato anche direttamente con i caplets, in questo modo:
$git clone https://github.com/bettercap/caplets.git
$sudo bettercap -caplets hijacking/hijacking
Il caplets hstshijacking permettono di effettuare un attacco hsts hijack e aggirare questa protezione, si basa sostanzialmente sul dns spoofing e sul dirottamento della vittima sotto il nostro controllo, per catturare successivamente i dati sensibili che transitano tra client e server abbattendo la crittografia.
Ho accertato che l’attacco funziona solo su alcuni domini che implementano HSTS, ma su quelli più importanti come Facebook, Linkedin, Twitter ecc non funge, probabilmente adottano misure di sicurezza ancora più severe riguardo i server.
Per caso ho scoperto un bypass anche per quest’ultimi, in effetti seppur l’attacco fallisce su questi domini nella modalità di richiesta diretta in quanto hsts svolge bene il suo lavoro, procedendo con l’indirizzamento da un sito web che fa da referral l’attacco si conclude:
Notiamo che Linkedin dispone di HSTS
Proviamo a far pervenire la richiesta tramite click su alcune icone social che reindirizzano a Linkedin da un’altro dominio che non implementa hsts:
l’attacco si conclude in maniera positiva in quanto sul dominio target anche se vi è attivo hsts, viene bypassata e bettercap riuscirà tranquillamente a filtrarne i dati dagli input delle sue pagine.
Conclusione
Abbiamo visto come un attacco ai DNS server in rete locale può minacciare la sicurezza delle pagine web visitate da un utente e come e’ possibile filtrare dati sensibili da esse, ma ancor peggio è il fatto che alcune importanti misure di sicurezza che vengono dichiarate ad oggi performanti in realtà non lo sono. Attraverso questa lunga panoramica ho voluto porre l’attenzione su queste problematiche per permettere ai progettisti e sistemisti di approfondire e cercare misure più adeguate per mitigare questo genere di bypass.
E’ stata inoltre fatta richiesta dell’assegnazione di una CVE per questa particolare vulnerabilità sull’HSTS proveniente dai referral di Linkedin, intanto Hackerhood rimarrà in attesa di qualsiasi decisione del Mitre.
Comments are closed