session hijacking

Il Session Hijacking

Il problema del web è sempre lo stesso, non esiste una soluzione concreta a tutti i problemi che riguardano la sicurezza.

Per questo, buona parte dei servizi più autorevoli ed influenti al mondo richiedono l’aiuto ad hacker e hijacker esperti per testare i sistemi di sicurezza. Queste persone di fatto mandano attacchi contro gli stessi sistemi che devono proteggere e ne testano l’efficacia.

Il problema del Session Hijacking, così può essere chiamato, è qualcosa da cui alcuni siti non riescono ancora a difendersi.

Ammettetelo, almeno una volta della vostra vita avete cercato un modo per accedere a servizi a pagamento in modo del tutto gratuito e forse illegale.

Quanti video troviamo su YouTube che mostrano come ottenere account gratis ed utilizzabili da tutti per ottenere Netflix gratis o cose simili?

In realtà, un trick ovvero un trucco, esiste un po’ per tutto. Basta saper trovare la falla ed il gioco è fatto.

Ricordate lo scandalo di inizio anno che vedeva un giovane ragazzo hackerare milioni di account Vodafone (della compagnia TalkTalk) in Gran Bretagna? Quel ragazzo ha trovato la falla in uno dei siti che non possono certamente permettersi di fare errori.

Questo per dirvi che, la perfezione è impossibile da raggiungere, si può migliorare la propria situazione ma non si riesce ad essere completamente al sicuro da tutto.

Il Session Hijacking

Ok, ma come molti di voi si staranno domandando, cos’è questo “Session Hijacking”?

La domanda è più che lecita e ne consegue una risposta che a primo avviso può sembrare un po’ complessa.

Il Session Hijacking è quella forma di attacco informatico che consente al proprietario di un computer (o a terzi), di bypassare ogni forma di controllo su una sessione Web, costringendo il server del target (il bersaglio) a generare un cookie valido che consenta l’accesso ad un sistema chiuso.

Mi aspetto già di vedere molti di voi, presi da crampi e convulsioni nel tentativo di capire bene cosa diavolo ho appena scritto 🙂

Per chi vuole la definizione in parole povere e non una alla “Wikipedia” come oserei definirla, continuate a leggere l’articolo.

Quando l’utente esegue l’accesso ad un sito, per esempio perché vuole fare il login ed accedere alla sua area personale, deve inserire delle credenziali di accesso ovvero la solita mail/nome utente e password.

Quando premiamo sul pulsante login si attiva un meccanismo che, suddiviso in varie fasi, svolge queste funzioni:

  1. Inviare i dati inseriti al server
  2. Validare i dati e controllare che siano validi (la mail deve essere valida, il nome utente…)
  3. Controllare che i dati siano presenti sul database del sito alla quale cerchiamo di accedere
  4. In caso affermativo eseguire un hashing della password tramite una chiave o un numero di “round” prefissato
  5. Controllare la corrispondenza della password inserita con quella criptata presente sul database
  6. In caso di corrispondenza generare una sessione che è sticky ovvero che ci viene assegnata per permettere di ricordare al server: “hey quest’utente ha già eseguito il login poco fa, non chiedergli di nuovo di accedere e permettigli di vedere il contenuto!”

Il processo dietro ad un meccanismo di login, come potete vedere, è abbastanza lungo e complesso ma, ogni passaggio è fondamentale per assicurare la sicurezza dell’utente e del sito.

Cosa accade realmente con il session Hijacking?

Con l’hijack della sessione molti di questi step vengono saltati, “imbrogliando” il sistema di controllo del login.

Si passa direttamente dallo step 1 a 6 senza ulteriori controlli. Molti studiosi si sono chiesti negli anni come fosse possibile che un Bug simile non fosse stato scovato anni prima.

La spiegazione è molto semplice, perché in realtà questi “bug” non sono propriamente dei problemi, bensì sono parte integrante del sistema che garantisce la sicurezza.

Ricordate una cosa: Session Hijacking <=> Cookie Hijacking (sono legati in ogni caso).

Ho dimenticato volutamente un passaggio intermedio che in realtà può essere benissimo inglobata dalla funzione numero 6 del sito, vi ricordate? Quella che diceva:

6) In caso di corrispondenza generare una sessione che è sticky ovvero che ci viene assegnata per permettere di ricordare al server: “hey quest’utente ha già eseguito il login poco fa, non chiedergli di nuovo di eseguirlo e permettigli di vedere il contenuto!”

dovremmo aggiungere:

Nel processo di creazione di una sessione, vengono generati dei cookie (non sono proprio dei biscotti ?) ma un codice che può essere salvato sul browser.

Per riassumere abbiamo quindi due parti che costituiscono il sistema di autenticazione:

  • le sessioni -> si trovano sul server del sito
  • i cookie -> si trovano nel browser dell’utente

Il problema però è un altro, perché indipendentemente dalla sessione salvata sul server, il cookie sul browser può essere la chiave di accesso alla stessa sessione sul server.

In sostanza, molti siti oggi utilizzano una sessione dalla parte server (server-side) che mantiene in memoria tutte le informazioni sull’accesso eseguito dall’utente, sulla validità, su preferenze temporanee ecc… dal lato browser (client-side) i cookie svolgono la funzione di pass per accedere alla sessione.

Se la sessione viene raggiunta il login è valido ed i dati possono essere visualizzati.

La vera domanda è: Come è possibile raggiungere la sessione senza il login?

Disponendo dei cookie.

E i cookie possono essere forniti o rubati da persone che hanno effettuato il login.

Netflix è affetto dal problema. Ma i casi sono molti.

Quello che accade con Netflix è una condivisione dei cookie con tutti.

Chi esegue il login estrae e condivide il codice del cookie che viene inserito da altri utenti che vogliono eseguire l’accesso con il session hijacking.

Cosa è possibile fare per difendersi?

Purtroppo non c’è molto da fare per risolvere del tutto il problema. Bisognerebbe lavorare di più sulla sicurezza dell’autenticazione del sito, ma questa è una cosa che può fare solo chi gestisce il sistema.

Dato che questa strategia permette di avere un servizio del tutto gratuito molti immagino penseranno che sia del tutto lecito utilizzare cookie di terzi ed appropriarcene. Invece non è così, anche se evidentemente la colpa di tutto ciò è del sito.

Voglio farvi un altro esempio.

Ieri, mentre scrivevo questo articolo, ho provato ad utilizzare il session hijackng per entrare sul mio profilo Facebook senza eseguire il benché minimo login e purtroppo ha funzionato.

Vi spiego come ho fatto:

Ho eseguito un accesso iniziale a Facebook tramite il login per entrare nella mia area privata.

Ho scaricato la seguente estensione chrome: EditThisCookie realizzata proprio per estrarre un cookie dai siti web o permettere di sostituirli.

Sono andato su una pagina Facebook dopo aver fatto il login e ho aperto l’estensione scaricata in precedenza:

Ho selezionato l’icona segnata in rosso sulla foto e ho copiato il codice restituito dall’estensione che altro non sono che i cookie del sito.

A questo punto, ragionando un momento ho pensato: “Se eseguo il logout per poter riutilizzare i miei cookie estratti, molto probabilmente la sessione sul sito (quella dalla parte server) verrà cancellata e quindi nessun cookie generato in precedenza sarà più valido“.

Quindi, l’unico modo per evitare di cancellare la sessione, ho cancellato solo i cookie sul mio browser (se avessi utilizzato un computer diverso non avrei avuto bisogno di eseguire nemmeno questo passaggio).

Così facendo, sessione era ancora valida, solo che Facebook non poteva permettere il login senza il pass (cookie) valido.

A questo punto, sono tornato alla pagina di login di Facebook e dopo aver riaperto l’estensione dei cookie:

E ha funzionato! Sono entrato senza password, nome utente, senza niente.

Ora quindi sappiamo che la maggior parte dei siti sono vulnerabili.

Se qualcuno dovesse riuscire ad appropriarsi dei vostri cookie può accedere a tutti i vostri dati, il che è molto pericoloso.

Volete davvero difendervi? 

Eseguite il logout ogni volta che uscite da un sito.

La nostra guida termina qui. Mi sono dilungato molto per spiegare i vari processi dietro l’hijacking delle sessioni per rendere più chiaro perché si tratta di un problema così serio.

Spero di essere stato sufficientemente chiaro nella spiegazione, alla prossima!