Man in the Middle

Linux Day Torino 2013

Mail: giulio@anche.no Jabber: giulio@anche.no

Introduzione

In questo talk si parlerà di:

  • ARP Spoofing in una lan ipv4
  • Panoramica sui rischi di siti web che usano connessioni non sicure
  • Introduzione al funzionamento di SSL ed al concetto di Authority
  • Possibili scenari di superamento di SSL
  • Ipotesi di attacco in remoto
  • Consigli per utenti e sviluppatori

"Man in The Middle"

In informatica, un MITM ("uomo in mezzo" in Italiano) consiste nel frapporsi tra la comunicazione di due host, facendo credere ad essi di essere l'interlocutore legittimo e ottenendo la possibilità di leggere ed alterare il flusso di dati.

Arp

  • Acronimo di "Address Resolution Protocol"
  • E' lo standard per mappare un IP su un MAC Address
  • E' utilizzato sia nelle reti cablate (802.3) sia che il quelle senza fili (802.11)
  • Si basa su due tipi di pacchetti, le "Request" e le "Reply"
  • La maggior parte dei sistemi operativi ha implementato una cache

Request & Reply



  • ARP Request: richiede il MAC Address di una macchina fornendo il proprio


  • ARP Reply: risponde ad una request comunicando il proprio indirizzo


Ricapitolando dunque quando un host desidera comunicare con un altro il kernel si preoccupa di mandare una richiesta per poter mappare l'indirizzo IP destinazione su un indirizzo MAC.

ARP Spoofing

E' possibile forgiare Reply e Request non veritiere, impersonando un altro host.



Esempio:
Vittima ha ip 192.168.1.2 e MAC AA:AA:AA:AA:AA
Router ha ip 192.168.1.1 e MAC BB:BB:BB:BB:BB
Attaccante ha ip 192.168.1.5 e MAC FF:FF:FF:FF:FF

Attaccante invia una ARP Reply a Router dicendo che Vittima è FF:FF:FF:FF:FF.
Attaccante invia una ARP Reply a Vittima dicendo che Router è FF:FF:FF:FF:FF.

In questo modo tutto il traffico tra Router e Vittima passerà attraverso Attaccante che potrà alterarlo.



Poichè l'attacco funzioni è inoltre necessario inoltrare il traffico da vittima a router e viceversa.



Contromisure

E' possibile utilizzare una tabella ARP→IP statica, fissando i valori dei MAC Addres. Questo tipo di approccio tuttavia è utilizzabile solo per reti che utilizzano ip fissi.



Esistono anche vari software che rilevano, ed in alcuni casi prevengono tentativi di ARP Spoofing, tra cui DefendARP, anti-arpspoof e ARPWatch



Tools

Ad oggi esistono diversi software open source che offrono ampie possibilità.

DNS Spoofing

Benchè la presentazione si concentri sul protocollo HTTP, un MITM che sfrutta l'ARP Spoofing permette di agire su qualsiasi protocollo con particolare facilità su quelli non criptati.



Un esempio, che tornerà utile in seguito è l'alterazione delle risposte DNS alle richieste della vittima, che permette di falsificare i record DNS per qualsiasi dominio

Contromisure

  • Le DNSSEC (Domain Name System Security Extensions) sono una serie di specifiche introdotte per garantire l'affibidabilità dei DNS. Tali sistemi implementano l'utilizzo di algoritmi di crittografia per la firma digitale e la verifica dell'integrità delle risposte DNS, con un principio per alcuni aspetti simile a SSL.

HTTP

Di seguito, alcuni esempi di azioni che un attaccante può effettuare sul traffico plaintext:

  • Leggere e salvare qualsiasi dato sensibile
  • Alterare le pagine, la grafica e nascondere elementi
  • Inserire codice malevolo, come un hook di BeeF o un meterpreter in java, o un exploit per un plugin

Contromisure

Benchè esistano alcuni accorgimenti, come l'hashing delle password o la criptazione di dati lato client, per esempio in JavaScript, tali misure non costituiscono una reale difesa.
Qualsiasi funzione infatti può essere facilmente eliminata dall'attaccante.

Sarebbe bene quindi, per la protezione dell'utente finale, che qualsiasi servizio utilizzasse SSL/TLS, con particolare attenzione verso quelli che richiedono l'utilizzo di informazioni sensibili, come una coppia di username/password.

SSL

  • Inventato da Netscape, ha cambiato nome in TLS (Transport Layer Security) dalla versione 3.0
  • Utilizza un algoritmo di cifratura a chiave asimmetrica per lo scambio delle chiavi
  • Utilizza un algoritmo di cifratura a chiave simmetrica per l'encryption dei dati
  • Per evitare l'impersonificazione di un server, esistono delle authority che firmano i certificati

Root CA

Gli algoritmi di cifratura forniscono sicurezza nella trasmissione dei dati, ma non sicurezza sull'identità del server. Sono quindi necessarie delle Autorità che rilascino dei certificati firmati solo ai legittimi proprietari dei domini.

I browser contengono poi una serie di "root CA", ovvero un elenco di certificati provenienti da Authority fidate, come VeriSign, GeoTrust ecc., che vengono utilizzate per controllare la validità di un certificato.

SSL a grandi linee

  • Client: Hello www.yahoo.com, vorrei aprire una connessione criptata
  • Server: Ok, ecco il mio certificato e la mia chiave pubblica
  • Client: Il certificato è valido, io supporto i seguenti algoritmi, 1, 5 e 12
  • Server: Ok, usiamo lo schema 12
  • Client: Ok, ci serve una chiave segreta che conosciamo entrambi. Usiamo "LinuxDayTorino2013"
  • Server: Ok, usiamo questa chiave

PFS a grandi linee

Esistono una serie di algoritmi che permettono di ottenere la cosiddetta "Perfect Forward Secrecy", ecco le caratteristiche importanti:

  • Le chiavi simmetriche sono sempre diverse e cambiano anche durante la stessa sessione
  • Siccome entrambe le macchine contribuiscono alla generazione delle chiavi temporanee, compromettere una delle due chiavi a lungo termine, come per esempio la Private Key del server non dà la possibilità di decrittare il traffico precedente

Citando Adi Shamir (La S in RSA):


Cryptography is typically bypassed, not penetrated




Cosa significa?

Significa che la maggior parte dei vettori di attacco non sono quasi mai contro la crittografia stessa, ma piusttosto contro la sua implementazione pratica, componenti esterni ad essa ed errori umani.

HTTPS MITM

L'utilizzo della crittografia non impedisce comunque la poissibilità di attacchi MITM.


Un attacante può ugualmente impersonare un server.


Vantaggi

  • L'attaccante ha pieno controllo sul traffico della vittima


Svantaggi

  • E' impossibile recuperare i dati da una sessione già iniziata
  • Non essendo il certificato utilizzato dall'attaccante firmato da una CA, qualsiasi browser mosterà all'utente un avvertimento.

Contromisure

In questo caso le uniche contromisure consistono in un po' di attenzione da parte dell'utente finale.

  • Non sottovalutare gli avvertimenti dei browsers
  • Non installare root CA se non di una entità davvero fidata

HTTP Session Hijacking

Alcuni provider di servizi ritengono erroneamente che sia sufficiente proteggere con SSL le pagine di login, per prevenire la lettura delle credenziali di accesso.

Ciò tuttavia non è sufficiente in nessun caso.


Vantaggi

  • L'attaccante può leggere cookie, sessioni e token di sicurezza che vengono trasmessi in chiaro
  • Utilizzando un cookie o una sessione è possibile impersonare l'utente senza lasciare tracce di login


Svantaggi

  • Non si ottengono crdenziali

Esempio

Un evidente esempio di ciò è il portale libero.it

Contromisure

In questo caso l'attacco è possibile solo grazie ad una errata configurazione del gestore. E' quindi fondamentale:

  • Utilizzare SSL per qualsiasi risorsa del proprio sito

Sfruttamento di XSS/CSRF

Le XSS e le CSRF sono tra le vulnerabilità più comuni presenti nelle applicazioni web.
(Rispettivamente la terza e la ottava secondo l'OWASP top 10 2013)


Entrambe queste vulnerabilità richiederebbero in un contesto normale interazione dell'utente.


Nel caso di un MITM l'attaccante può iniettare nel traffico di un qualsiasi sito HTTP del codice javascript per rubare un cookie ed eseguire una richiesta non voluta.


Vantaggi

  • L'attacco è silente. Se eseguito bene la vittima non ha strumenti per accorgersene


Svantaggi

  • Il sito in questione deve presentare falle di questo tipo
  • Non si ottengono dati sensibili

Contromisure

In questo caso lo sviluppatore della webapp deve:


  • Effettuare sempre i dovuti controlli su qualsiasi input inserito da un utente (che è sempre una regola fondamentale)
  • Utilizzare token per validare le richieste GET/POST, che andrebbero sempre rigenerato

sslstripping

L'SSLstripping è una tecnica ideata da Moxie Marlinspike e da lui stesso presentata al Defcon 2009.


Consiste nell'alterare tutto il traffico plaintext di un utente, sostituendo "https" davanti ai link con il semplice "http", facendo connettere in chiaro la vittima al nostro proxy, che poi utilizzerà SSL per connettersi al server di destinazione.


Vantaggi

  • Il traffico HTTPS diventa HTTP


Svantaggi

  • Facilmente notabile da un utente attento
  • Non funziona se l'utente accede ad una risorsa direttamente, digitando lui l'https o utilizzando un segnalibro

Contromisure

E' compito sia dell'amministratore del server che dell'utente vigilare su questo attacco:


  • L'utente deve sempre controllare che le risorse sensibili utilizzino https
  • L'amministratore del server deve impostare una policy HSTS (HTTP Strict Transport Security). Questo parametro comunica al browser che dal primo accesso in poi il dominio richiesto dovrà essere sempre raggiunto solo tramite SSL.

Session Hijacking Avanzato

E' possibile effettuare Session Hijacking anche su risorse interamente HTTPS.


Infatti, quando non diversamente specificato, i cookie sono condivisi tra http e https.
Ciò significa che un cookie la cui origine è https://www.gnu.org può essere richiesto anche da http://www.gnu.org .


Session Hijacking Avanzato

Esempio:


  1. Vittima visita https://example.com ed effettua un login.
  2. https://example.com assegna un SESSIONID alla vittima e su di esso registra il login
  3. Vittima, che non ha effettuato il logout, visita un qualsiasi sito non https
  4. Attaccante inizia DNS Spoofing e punta example.com su un suo webserver locale
  5. Attaccante ha sul suo webserver locale uno script che legge e scrive i cookie ottenuti in un file
  6. Attaccante inietta nel traffico HTTP di vittima un iframe nascosto, che carica http://example.com
  7. Una volta letto il cookie attaccante ripristina tutto

Vantaggi

  • L'attacco, se eseguito bene ed in condizionali ottimali è silente


Svantaggi

  • Nella maggior parte dei casi non si ottengono credenziali
  • E' necessario prendere i tempi giusti, per evitare che vittima visiti example.com mentre è in atto il DNS Spoofing

Contromisure

Lo sviluppatore deve solo ricordarsi di:


  • Aggiungere la flag "secure" quando setta un cookie sensibile. Questo forzerà il browser ad inviarlo solo attraverso https.

Session Hijacking via Fixing

L'attacco descritto nella slide precedente rimane fattibile, nonostante la flag "secure" utilizzando un approccio inverso.


Infatti, nonostante la flag "secure" blocchi l'invio del cookie ad una risorsa non https non ne blocca la sovrascrittura.


http://www.gnu.org può quindi settare un cookie valido anche per http://www.gnu.org .


Session Hijacking via Fixing

Questo ci ritorna particolarmente utile per qualsiasi sito utilizzi le sessioni per l'autenticazione o utilizzi i cookie per salvare delle informaizoni sensibili.


Il procedimento è molto simile a quello descritto precedentemente.

Session Hijacking Avanzato

Esempio:


  1. Attaccante sa che vittima visiterà https://example.com, o che lo ha già visitato
  2. https://example.com utilizza le sessioni o altri token per autenticare l'utente
  3. Quando vittima non sta utilizzando https://example.com attacker inizia DNS Spoofing e punta example.com su un webserver locale
  4. Attaccante ha sul suo webserver locale uno script che sovrascrive l'id di sessione con uno valido e conosciuto (Preso precedentemente dal example.com)

Session Hijacking Avanzato

  1. Attaccante include nel traffico http un iframe nascosto, che carica http://example.com
  2. Attaccante ha sul suo webserver locale uno script che sovrascrive l'id di sessione con uno valido e conosciuto (Preso precedentemente da example.com)
  3. L'attaccante ripristina tutto ed attende che vittima esegua un login su https://example.com, validando l'id di sessione da lui assegnato
  4. Attaccante ha ora un id di sessione valido, e da lui stesso scelto

Vantaggi

  • L'attacco, se eseguito bene ed in condizionali ottimali è silente


Svantaggi

  • Nella maggior parte dei casi non si ottengono credenziali
  • E' di complessa realizzazione
  • Non tutte le webapp usano le sessioni

Esempio

Coinbase.com è uno dei maggiori siti di acquisto e scambio di Bitcoin

Una sessione di un utente non autenticato si presenta, in versione semplificata, così:

session_id:"acedfa683d0d9aa4001c7ac6da40c09a";
_csrf_token:"1NaNj4IXj+FVMJcEYimczqYrJNXejTh2x0E1Wgg5GyeE";

Una sessione di un utente autenticato invece così:

session_id:"acedfa683d0d9aa4001c7ac6da40c09a"
_csrf_token:"1NaNj4IXj+FVMJcEYimczqYrJNXejTh2x0E1Wgg5GyeE"
session_token:"E72b357fa634f0849c9170d80320aba1230e4a2cdae50b7e3ef45ae2d0540968c";

Esempio

Come si può notare il valore di "session_id" ed il valore di "_csrf_token" rimangono invariati.

Tuttavia, viene aggiunto un campo "session_token" come parametro aggiuntivo di sicurezza per verificare l'avvenuto login.


All'attaccante però è sufficiente conoscere il valore di "_csrf_token" per poter iniettare nel traffico non https richieste GET/POST valide.

Contromisure

Lo sviluppatore:


  • Dopo un login rigenerare sempre i token segreti

L'amministratore dovrebbe:


  • Impostare una policy HSTS

Esistono poi alcuni attacchi più complessi:


-BEAST
-CRIME
-Lucky 13
-BREACH

Per approfondire:
https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf

Possibili Scenari Remoti

Fino a questo punto si è parlatto di ARP Spoofing su una LAN locale, tuttavia questo approccio è molto riduttivo, e tratta solo del più comune degli scenari.


Qualsiasi entità che ha il controllo della rete può effettuare un MITM, cominciando dagli amministratori di rete, per passare agli ISP, per finire, come è emerso anche nei media di recente, chi ha accesso alle backbone e alle infrastruttre principali, come il governo USA.


Nelle prossime slide seguiranno alcuni esempi in cui si può effettuare un MITM senza essere una autorità.

Esempio: Exit Node Tor

Benchè tutto il traffico tra i nodi Tor sia criptato, compreso quello tra client e Hidden Services, per poter comunicare con la rete normale è prima necessario decriptarlo e ne consegue che questo compito deve essere svolto dall'ultimo nodo, chiamato Exit Node.


Questo fa si che il gestore dell'Exit Node abbia pieno controllo sul traffico dell'utente.


Casi simili si sono già verificati, una lista è disponibile qui https://trac.torproject.org/projects/tor/wiki/doc/badRelays .

Esempio: Dispositivi Embedded

La sicurezza dei dispositivi embedded, come modem, router e stampanti è sempre stata sottovalutata.


Questo apre le porte ad un attaccante, che dopo aver compromesso uno di questi dispositivi (spesso basta usare le credenziali di default) può effettuare un MITM in piena regola verso tutti gli utenti della subnet.


Basti pensare cosa sarebbe successo se la botnet Carna, che si era autoreplicata in circa 420.000 dispositivi embedded ed aveva come scopo fare una completa statistica sull'intero range ipv4, avesse adottato un approccio simile.

Fonti e Approfondimenti

Arp Spoofing

DNS Spoofing

HTTP MITM

SSL & PFS

Fonti e Approfondimenti

XSS & CSRF

sslstrip

Sessioni & Cookie

Attacchi Complessi

Fonti e Approfondimenti

Attacchi Complessi

Scenari Remoti

Domande?

Fine