Che navigare sul proprio sito di Internet banking o sulla propria casella di posta attraverso un comune network pubblico sia un’attività rischiosa per la riservatezza dei propri dati è cosa nota, quantomeno per chi possiede basi di sicurezza informatica. Ma che addirittura la semplice visita ad un qualsiasi innocuo sito Web possa portare alla compromissione dei propri cookies e delle proprie password relative a qualsiasi sito l’attaccante decida, beh, questo va oltre l’immaginazione dei più.
Eppure è proprio questo e molto altro che due ricercatori, Roi Saltzman e Adi Sharabani, del IBM Rational Application Security Group descrivono nel loro documento intitolato Active Man in the Middle Attacks pubblicato meno di due settimane fa.
Questa volta desidero addentrarmi in qualche tecnicismo più del solito, senza esagerare, per permettere al lettore, che già possiede un sufficiente background di nozioni, di capire a fondo le cause e le conseguenze di queste nuove forme di attacco. Gli altri facciano tesoro dei link di riferimento che inserisco.
Gli attacchi Man in the Middle (MITM d’ora in poi), sono un’ampia e variegata collezione di attacchi che, come si può intuire dal nome, hanno in comune la presenza di un intruso che si insinua in maniera del tutto trasparente tra i due capi di una comunicazione creando dei canali indipendenti con ciascuno dei due capi e potendo così intercettare i dati che essi si scambiano (leggendoli solo o anche modificandoli).
In ambito networking sono noti da diverso tempo alcuni attacchi MITM di tipo passivo. Due esempi su tutti sono il classicissimo poisoning della cache ARP e il più recente rogue Access Point.
Il primo attacco affligge le reti locali switchate (sniffare una rete con un hub dove il traffico viene mandato in broadcast è veramente banale) e si basa sul funzionamento del protocollo ARP che ha il compito di convertire un indirizzo di rete IP (OSI Layer 3) in un indirizzo fisico MAC (OSI Layer 2).
Se la macchina dell’attaccante, collegata alla rete locale (wired o wireless), invia in broadcast un particolare pacchetto Gratuitous ARP (ARP announcement) con IP del gateway (router) ma indirizzo MAC della sua scheda di rete, può fare in modo che gli host della rete lo vedano come il default gateway che può essere a sua volta ingannato facendo si che mandi tutto il traffico al computer dell’attaccante, che intercetterà così, in maniera trasparente, sia il traffico in uscita che quello in entrata.
Nel secondo attacco viene invece creato un access point identico come SSID e indirizzo MAC ad uno esistente nelle vicinanze (i driver di alcune schede di rete wireless, Atheros + MadWifi in primis, permettono di farlo con semplicità). In questo modo chiunque vi si connetta erroneamente sarà completamente sotto il controllo dell’attaccante.
Di diverso tipo sono gli attacchi MITM attivi, descritti dai ricercatori della IBM, in cui l’attaccante manipola una risposta in una sessione legittima in modo da far sì che il client effettui una richiesta (invisibile all’utente) che riveli dati sensibili, poi intercettati.
E’ importante notare che gli attacchi che tratterò non sono dovuti a qualche bug bensì al design stesso delle applicazioni e dei protocolli presi di mira.
Uno dei modi per effettuare un attacco attivo è inserire un IFrame, di dimensioni nulle e quindi invisibile, nella pagina HTML che un utente riceve di risposta durante una qualsiasi sessione HTTP attiva:
<HTML>
<HEAD>
<TITLE>Innocuo Quotidiano Online</TITLE>
</HEAD>
<BODY>
Contenuto del Giornale…
<IFRAME src=”http://webmail.site” WIDTH=”0″ HEIGHT=”0″></IFRAME>
</BODY>
</HTML>
Quando il browser della vittima riceverà la pagina di risposta modificata dall’attaccante, manderà una richiesta al sito specificato nel SRC insieme alle eventuali credenziali (di solito rappresentate dei cookies) che esso possiede per tale sito. A quel punto l’attaccante non dovrà fare altro che impossessarsi di quelle credenziali per impersonare l’utente vittima sul sito specificato nell’IFrame.
Questo attacco è più versatile e potente di quello che di solito effettua un malintenzionato durante un attacco MITM passivo, il quale spesso si limita a intercettare (sniffare) il canale in attesa che un utente sprovveduto si colleghi ad un sito non protetto da SSL (benché esistano attacchi ben noti anche per siti protetti con SSL!) e fornisca le sue credenziali in chiaro come token tramite cookies. Si legga il post di Robert Graham sul SideJacking.
Sandro Gauci ha descritto qualche mese fa una variante di questo attacco, nota come Surf Jacking che, invece di utilizzare gli IFrame (individuabili analizzando il sorgente della pagina), si basa sul HTTP Redirects, più difficile da scovare.
Nei mesi passati la maggior parte dei browser hanno introdotto il supporto per i cookies HttpOnly che impediscono al codice JavaScript (talvolta anche alle XMLHttpRequest) di accedervi, e quindi ad un attaccante di catturarli tramite Cross-Site Scripting (XSS). Questa protezioni si rivela però totalmente inefficace contro un attacco MITM attivo o passivo.
Va sottolineato che anche i cookies di pagine dietro connessioni VPN (o SSL) possono essere catturati nel caso in cui il sito faccia riferimento a risorse fuori dalla VPN (o connessione SSL) stessa, come uno script JS: quando il browser dell’utente vittima fa la richiesta in chiaro della risorsa esterna, tale richiesta può essere intercettata dall’attaccante e un’adeguata risposta può essere forgiata.
Negli attacchi XSS un malintenzionato sfrutta delle variabili vulnerabili di un’applicazione Web vulnerabile per far eseguire all’utente vittima, di solito, del codice JavaScript a sua scelta all’interno del contesto del sito vulnerabile. A quel punto l’attaccante può fare praticamente qualsiasi cosa sul quel sito, da rubare i relativi cookies dell’utente ad usare un keylogger JavaScript.
In maniera simile, in un attacco MITM attivo, è possibile di bypassare facilmente la Same Origin Policy per qualsiasi dominio. Quando la vittima visita un qualsivoglia sito, l’attaccante inserisce un IFrame nella risposta che farà partire una nuova richiesta dal computer della vittima verso un sito a scelta del malintenzionato, nella cui risposta verrà inserito del codice JavaScript a sua discrezione.
Un utilizzo piuttosto creativo e acuto del codice JS permette di rubare tutte le coppie username e password che il browser ha salvato in memoria. Inserendo un falso form di login, con opportuni parametri, nella pagina Web attaccata, il browser vi inserirà le credenziali che ha salvato per esso, che potranno essere catturate e inviate all’attaccante con del semplice codice JS. L’attacco può essere poi ripetuto per qualsiasi sito.
Gli effetti di un attacco MITM di solito si esauriscono con la fine dell’attacco medesimo. Tuttavia con tecniche di HTTP Cache Poisoning è possibile estenderne gli effetti ben più a lungo. Se infatti il malintenzionato inserisce del codice opportuno nei header HTTP di risposta al sito desiderato può far sì che anche in futuro venga caricata la pagina in cache col codice malevolo inserito dall’attaccante:
Expires: Fri, 12 Mar 2010 13:13:13 GMT
Cache-Control: public
Spero di essere stato abbastanza chiaro, ho cercato di sintetizzare parecchie nozioni, anche piuttosto complesse, in non troppe righe. Rimando al whitepaper originale per una trattazione più completa.
Lunedì ci occuperemo di come difendersi, come utenti o amministratori, da questo tipo di attacchi, certo il buonsenso non è sufficiente. Per oggi può bastare così.
