Netlog vulnerabile a CSRF

Premetto che non mi assumo nessuna responsabilità per eventuali danni causati sul sito in questione.

In un mio precedente articolo, risalente a qualche mese fa, riportavo la suddetta vulnerabilità di questa (abbastanza) famosa piattaforma di social networking.
Ho inviato delle mail al support italiano, sono stato rimandato a quello europeo dai quali non ho mai più ricevuto alcuna risposta…. evidentemente non lo ritengono una minaccia.

Data Contatto: 11/07/2009 (senza ottenere risposta)
Pubblicazione:18/10/09
Tipologia:Cross Site Request Forgeries
Indirizzo: it.netlog.com

netlogEseguendo  nel browser la pagina creata ad hoc (ecco un esempio) mentre è attiva una sessione in netlog,  la vittima si ritroverà tra i post del suo blog un nuovo articolo, il quale contenuto sarà a completa discrezione di chi esegue l’attacco. Non ho avuto tempo di provare ad inserire vettori XSS ma probabilmente ci sarà modo ,visto che non fixano il form nemmeno sotto segnalazione.

Questa vulnerabilità permette la auto-distribuzione dell’ attacco, poichè se il post forgiato  contenesse un link alla pagina di partenza da cui il post stesso è stato creato e se un altro utente vi cliccasse, esso si replicherebbe istantaneamente nel profilo di chi ha visitato la pagina infetta . La capacità di autodiffondersi unita ad una falla XSS rappresenterebbe una minaccia per gli utenti di Netlog.

Il file di prova che ho inserito in questo articolo è puramente a scopo informativo, scoraggio chiunque nell’effettuare un attacco verso il sito internet indicato.

Annunci

Netlog vulnerabile a CSRF

netlog

Proprio di recente mi sono rimesso sui libri, non quelli dell’università perchè quelli non li ho mai lasciati e non lascerò per parecchio tempo,  ma quelli che leggo di notte davanti al pc.

Ho ricominciato la mia serie di pubblicazioni proprio parlando di CSRF e facendo una piccola pausa, ho loggato in Netlog, un social di cui sono membro da ormai più di un anno.

In questo periodo,la mia installazione di firefox è praticamente inutilizzabile per navigare, a causa delle estensioni installate, ma spinto dall’abitudine , ho aperto nelog proprio con firefox  nel quale erano attive Firebug e Webdeveloper.

Dopo poco tempo sono venuto a capo della questione, scoprendo che quella sezione del sito è vulnerabile ad attacchi di tipo CSRF e poichè si tratta di un sito con tantissimi utenti, la faccenda sembra seria. :/

Non posso aggiungere altri dettagli finchè alla Netlog inc (xD) non avranno messo una toppa o finchè non sarà passato troppo tempo.

CSRF Cross site request forgeries: difendersi con i tokens

In un precedente articolo, ho introdotto il concetto di CSRF, questa volta ci occuperemo di ovvero fornire i concetti di base della protezione contro questo tipo di attacchi. funny_cat_pictures_092

Ci tengo a precisare che anche questo articolo conterrà metodi di base per la protezione delle proprie applicazioni, in quanto la scienza dietro gli attacchi è davvero molto sviluppata al momento.Abbiamo visto che un attacco di tipo CSRF consiste nel fare in modo che la vittima invii delle richieste inconsapevolmente, sfruttando le sue credenziali. Riportiamo brevemente un esempio per riprendere le fila del discorso: Mentre visitiamo la pagina “posta in arrivo” del nostro account email non protetto, apriamo un altra scheda del browser, capitando in un sito malevolo creato ad hoc per attaccare la pagina del nostro email service provider. Cliccando su un semplice link del tipo:

<a href=”happy_page.php” onClick=”document.send_mail_form.submit()”>Click</a>

e magari avendo semplicemente (ci sono modi di gran lunga migliori per inviare richieste POST) predisposto il seguente form nascosto:

<form name=”send_mail_form” method=”POST” action=”www.unsafe-email-service.com”>

<input type=”hidden” name=”receiver” value=”randomReceiver1”>

<input type=”hidden” name=”receiver” value=”randomReceiver2”>

<input type=”hidden” name=”receiver” value=”randomReceiver3”>

..

<input type=”hidden” name=”receiver” value=”randomReceiverN”>

<input type=”hidden” name=”object” value=”Object”>

<input type=”hidden” name=”text” value=”randomText”>

</form>

comporterebbe l’immediato e totalmente involontario invio delle email con il nostro account di posta elettronica.

Come possiamo mitigare il rischio CSRF ,quantomeno, rendere gli attacchi meno scontati e facilmente implementabili? Un metodo largamente usato, in quanto offre un buon rapporto sicurezza/facilità di implementazione è quello dei Token.

Un token è una stringa di testo che funge da validazione per le richieste che inviamo alla nostra applicazione e deve essere correlata alla sessione dell’utente.

Potremmo sintetizzare il concetto nei seguenti passi: Creo il token, lo salvo nella sessione e lo richiedo per validare ogni input utente. Se il sistema rileva una richiesta POST non accompagnata dal corretto token ci permetterà di riconoscere un probabile tentativo di attacco e di interrompere l’esecuzione.

Parte 1: creiamo il token.

Presupponendo che la sessione sia già stata inizializzata

<?php

$token = sha1(uniqid(rand(),TRUE));

$_SESSION[‘token’] = $token;

?>

Parte 2: generiamo il form

<form name=”myForm” method=”POST” action=”myPage.php”>

<input type=”hidden” name=”token” value =” <?php echo $_SESSION[‘token’]; ?> “ />

<input type=”text” name=”myText” />

<input type=”submit” value=”invia”>

Parte 3: controlliamo la validità della richiesta

<?php

if (!isset ($_POST[‘token’] OR !isset ($_SESSION[‘token’] OR $_POST[‘token’] != $_SESSION[‘token’] OR)

{

//errore! Interrompere l’esecuzione

} else {

//Il token è validato, possiamo procedere

}

?>

n questo modo costringiamo l’attaccante a scoprire il token assegnato alla sessione della vittima, inoltre questo fa si che l’attacco colpisca soltanto quell’utente, o comunque costringe l’attaccante a replicare il token di ogni vittima, affinchè le richieste artificiali da lui create bypassino il sistema di controllo.

Come migliorare questo approccio?

Come ho già detto, questo metodo non garantisce la sicurezza assoluta, quindi se state cercando di mettere al sicuro i form di un sito di e-commerce, non vi consiglierei mai di fermarvi a questo livello di validazione; possiamo però migliorare il nostro codice di controllo in diversi modi. Vediamone alcuni.

Generiamo un token per ogni form della pagina che l’utente visualizza, così da aumentare la complessità del problema, potremmo dire che creare un token per ogni richiesta dell’applicazione sarebbe un’ottima cosa.

Associamo un tempo di validità del token dopo il quale non verrebbe più considerato valido:

<?php

$token = sha1(uniqid(rand(),TRUE));

$_SESSION[‘token’] = $token;

$_SESSION[‘token_time’] = time();

?>

e successivamente controlliamo che non sia passato troppo tempo dalla creazione del token, altrimenti lo consideriamo scaduto :

<?php

if (!isset ($_POST[‘token’] OR !isset ($_SESSION[‘token’] OR $_POST[‘token’] != $_SESSION[‘token’] OR)

{

//errore! Interrompere l’esecuzione

} else {

$token_time = time() – $_SESSION[‘token_time’];

//Facciamo in modo che la durata massima del token sia di 10 minuti

if ($token_time < 600)

{

//interrompiamo l’interruzione informando che la pagina è scaduta

}

//Il token è validato, possiamo procedere

}

?>

Concludo proponendovi una riflessione: anche la miglior difesa contro attacchi di tipo CSRF può essere superata se non vi affianchiamo una ottima difesa per gli attacchi di tipo XSS, in quanto questi ultimi potrebbero essere utilizzati come “apripista” verso le nostre difese.

CSRF: basi di Cross Site Request Forgery

Ho parlato a lungo ed abbastanza dettagliatamente del cross site scripting, ora invece vi presento una tecnica dal nome simile ma dall’efficacia maggiore per portare a termine certi tipi di attacchi: i famigerati CSRF attacks (o XSRF).

Il nome della tecnica è eloquente: si tratta di creare delle richieste ad hoc da inviare ad una applicazione sfruttando le autorizzazioni di un utente ‘trusted’, ovvero sfruttando la sua identità!!

csrf.jpg

Notiamo subito una differenza sostanziale tra XSS e CSRF: con i primi, ad essere sfruttata è la fiducia che l’applicazione ripone nell’utente attivo, che invece di svolgere le sue normali operazioni sfrutta le falle dell’applicazione stessa; Nel caso del CSRF invece, ad essere sfruttata è la fiducia che l’utente ripone in un certo applicativo, che invece lo sfrutta (non è esattamente l’applicativo che sfrutta l’utente, ma il programmatore che lo ha sviluppato!! altrimenti l’applicazione sarebbe una specie di Agente Smith di Matrix XD).

Ma come inviare delle richieste ad un server?? ci sono zilioni di modi 😀 la maggior parte dei quali realizzabili da chiunque e questo non fa altro che aumentare i problemi di sicurezza nelle grandi applicazioni web: anche il più impreparato degli script kiddies potrebbe portare a termine un attacco del genere!!

Vediamo ora un semplice esempio pratico:

L’azienda Pancom, mette a disposizione dei suoi utenti un certo numero di inviti, da inviare ai propri amici per permettere ad essi di unirsi alla comunity di bloggers altrimenti riservata.

Ogni utente ha nella propria dashboard, un form composto da una textbox in cui va inserito l’indirizzo email del proprio amico a cui si vuole donare l’accesso a Pancom, e chiaramente un pulsante di submit.

Come poter sfruttare gli inviti dell’utente Mattia che non sta attento alle sessioni e naviga su internet con moltissime tab aperte senza curarsi della sua sessione in Pancom.com??

Se i programmatori Pancom non sono stati attenti, no cè niente di più semplice!!
Dopo aver analizzato il form di invio degli inviti (pensate a quello di Gmail), il cui codice possiamo immaginare essere simile al seguente:

<form name="invita” method=”GET” action =”invita.php”>
<input type=”text” name=”email”>
<input type=”submit” value=”Invita!”>
</form>

Ne risulta che la richiesta da inviare al server sarà una del tipo:

http://utenteLoggato.pancom.com/invita.php?email=indirizzo@maligno.com

Per fare in modo che l’utente loggato invii al posto nostro una richiesta del genere sarà sufficiente che visiti una pagina web creata ad hoc dall’attaccante. e contenente un tag come un link ad uno stylesheet, una immagine o una tag META:

<img src=”http://utenteLoggato.pancom.com/invita.php?email=indirizzo#maligno.com”>
<link rel=”http://utenteLoggato.pancom.com/invita.php?email=indirizzo#maligno.com”> 

Anche una banale immagine di sfondo che viene caricata con il corpo della pagina html innesca il meccanismo sopra citato!!

Capirete dunque che un attacco del genere (filtraggio degli url,utilizzo di token sicuri, controllo del referrer… mmm ok ne parlerò più avanti :D), può essere portato a termine in pochissimo tempo e senza delle conoscenze specifiche di SQL, PHP, Javascript o qualsiasi altra code injection esistente :S