Session Hijacking (Session Sidejacking) – Entrare nell’account di qualcuno senza conoscere le credenziali

Finiti gli esami comincio ad avere più tempo da spendere per me stesso e per il blog, ho appena finito la migrazione da BackTrack all’Italianissima BackBox (dategli un’occhiata!) e sono pronto con un bellissimo tema per l’articolo: Session Hijacking (dirottamento di una sessione) ma vediamo bene di cosa si tratta.

Quando facciamo login ad un servizio (che sia Gmail, Facebook, Twitter, eccetera) ci vengono richiesti il nostro username e la nostra password e se la combinazione dei due è corretta allora ci vengono assegnati dei “cookies” grazie ai quali non dovremo autenticarci ad ogni richiesta di una pagina ma saranno proprio quei cookies ad identificarci, abbiamo aperto una sessione. In pratica è come se, dopo esserci autenticati, ci venisse fornito un “pass” (la nostra sessione) grazie al quale possiamo accedere ai nostri dati semplicemente facendolo vedere al server.

Comodo no? Pensate se avreste dovuto inserire username e password ad ogni click e ogni messaggio inviato su Facebook, ad ogni email inviata e ogni volta che cambiate cartella in GMail… Un inferno direi! Molti siti (ma non tutti!) criptano non solo l’invio di username e password durante il login ma anche tutte le informazioni che scambiano con un cliente (voi), cookies compresi. Vedremo tra poco come questa non sia affatto una “formalità” ma una vera necessità.

Molti di voi avranno già intuito cosa andremo a fare: faremo un attacco di ARP Spoofing (o ARP Poisoning) in modo da far passare attraverso di noi tutte le informazioni che server e client vogliono scambiarsi e cercheremo, tra tutti questi dati scambiati, dei cookies che andremo poi ad impostare sul nostro browser nella macchina attaccante, vedrete che è un compito, ahimè, davvero semplice ed efficace.

Gli ingredienti di oggi sono:

1. Una macchina vittima fisica o virtuale connessa alla nostra LAN.
2. Una macchina attaccante che disponga dei seguenti tools:
   Scaricatevi BackBox (o BackTrack) e avrete tutto già pronto a parte Greasemonkey e lo script Original Cookie Injector.
3. arpspoof – http://arpspoof.sourceforge.net/
4. sslstrip – http://www.thoughtcrime.org/software/sslstrip/
5. wireshark – http://www.wireshark.org/
6. firefox con greasemonkey – http://www.mozilla.org/it/firefox/fx/ e https://addons.mozilla.org/it/firefox/addon/greasemonkey/
7. Original Cookie Injector – http://userscripts.org/scripts/show/119798

Installate tutto il necessario e siete pronti a partire!

Let’s Go!

Per prima cosa andiamo ad avvelenare le tabelle ARP della vittima. Nel mio test la macchina vittima è in 192.168.1.120 mentre il router è in 192.168.1.1 e la mia interfaccia di rete è eth1. Per saperne di più su questo tipo di attacco vi rimando ad un mio precedente articolo: ARP Spoofing e MITM (Rubare password e credenziali).

arpspoof -i eth1 -t 192.168.1.120 192.168.1.1
arpspoof -i eth1 -t 192.168.1.1 192.168.1.120

Abilitiamo l’IP Forwarding (se nel codice compare “>”, sostituitelo con “>”, scusate ma ogni tanto sballa!):

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

Controlliamo che il comando sia andato a buon fine con:

cat /proc/sys/net/ipv4/ip_forward

L’output del comando deve essere 1.

Indirizziamo il traffico HTTP alla porta 10000 sulla quale sslstrip sarà in ascolto e lanciamo sslstrip:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
python sslstrip.py -k -l 10000

Ora tutto il traffico tra vittima e server passerà attraverso di noi, non resta che avviare l’analizzatore di pacchetti Wireshark:

wireshark -i eth1 -k

Ci siamo…

Tutto è pronto: andate nella macchina virtuale, fate login su Facebook, Twitter o quello che volete, smanettate un po’ (ovvero usate quel servizio richiedendo pagine, aggiornando e così via, non dovete starci un ora!). Tornate sulla macchina attaccante e fermate la cattura dei pacchetti (Capture -> Stop). Premete Ctrl+F per fare una ricerca, impostate “By:” -> “String”, inserite “cookie” come parametro di ricerca, selezionate “Case Sensitive”, “Search In:” -> “Packet Details”, “Direction” -> “Up” e premete Find, al primo risultato controllate che la scroll-bar dei pacchetti sia verso la fine (all’inizio abbiamo dei cookies risalenti a prima del log-in e quelli non ci interessano), dovete cercare pacchetti simili a questo:

Per Facebook è sufficiente cercare “datr” anzichè “cookie” in quanto quello è il nome del cookie che ci serve per Facebook. Selezionate la riga comprendente “cookie:”, cliccateci col destro e fate Copy -> Bytes -> Printable Text Only. Aprite il vostro browser dove avete già installato Greasemonkey e lo script “Original Cookie Injector” e andate sulla pagina che vi interessa (se avete copiato i cookie di Facebook andrete sulla pagina “facebook.com“, per GMail su “www.gmail.com” e così via), premete ALT-c e si aprirà un piccolo box dove dovrete incollare i cookies appena copiati (CTRL-v), lo script vi avvertirà della corretta impostazione dei cookies. Ora non vi resta che aggiornare la pagina e… Eccovi nell’account della vostra vittima 😉

Devo stare sempre all’erta?

Crediamo costantemente di essere al sicuro dietro ai nostri schermi ma i pericoli sono ovunque e grazie alle reti WiFi questi si sono decisamente moltiplicati (avere accesso ad una LAN non Wireless è difficile, rompere la sicurezza di una rete Wireless è decisamente più facile e c’è molto meno rischio di essere scoperti). Questo non vuol dire che dobbiamo diffidare di Internet e dei computer, una vita senza di loro è difficilmente immaginabile, portano troppa innovazione, dobbiamo però fare un po’ più di attenzione: di segnali per capire che questo tipo attacco era in corso ce ne sono e avremmo potuto evitare che la nostra sessione o le nostre credenziali venissero rubate.

Contromisure.

Come possiamo difenderci? Il programma sslstrip, semplificando molto, non fa che forzare un utente ad usare http anzichè https e quindi le informazioni scambiate con un server non sono criptate, altrimenti un attaccante non avrebbe potuto capire nulla delle informazioni che questi si scambiano (sempre che il server cripti TUTTE le informazioni e non solo durante il login). Se andiamo sulla pagina della nostra banca o anche quella di Facebook notiamo il simbolo di un lucchetto accanto all’indirizzo: se ci clicchiamo possiamo leggere “Your connection to this website is encrypted to prevent eavesdropping” insieme ad altre informazioni relative al certificato, vuol dire che la connessione col server è criptata, stiamo quindi usando https. Nell’indirizzo inoltre è facilmente leggibile “https://“, altro segnale dell’utilizzo di questo protocollo. In caso qualcuno abbia usato sslstrip il lucchetto non ci sarebbe (ma potrebbe anche esserci, in ogni caso cliccandoci non avremmo le informazioni di prima) e non compare “https://” nell’indirizzo ma “http://” che potrebbe anche essere omesso, segnali che indicano che non ci stiamo connettendo in modo sicuro al server e dovremmo fare attenzione a cosa facciamo. Inoltre se, sia da Linux che da Windows, lanciamo il comando “arp -a” (vedi immagine) noteremo che ci sono più corrispondenze con lo stesso indirizzo fisico, qualcuno sta “ascoltando” quello che accade sulla rete fingendo di essere il nostro router.

Anche i server sono in parte colpevoli e le soluzioni a questo problema non sono poi così costose o complicate, basta leggere qui per qualche spunto: http://en.wikipedia.org/wiki/Session_hijacking#Prevention