Ancora un altro blog

NB: articolo modificato dopo la pubblicazione
Ci sono nuovi dettagli, vedi in fondo

Tutto inizia da un post di Maxime: questo. La catena di link mi ha portato qui, dove ci sono alcune particolari query per Google.

Per curiosità ne ho provata una, ed il risultato mi ha portato in modalità Allarme Rosso. Parto con i risultati dell’indagine, i dettagli li metto dopo.

Se avete Wordpress, una qualsiasi versione, forse anche la 2.5 è vulnerabile, controllate attentamente il server su cui è ospitato per la presenza di file strani, di modifiche al codice stesso di Wordpress ed al database. Non sembra essere questo problema l’origine, ma non ho dettagli a sufficienza per escluderlo del tutto.

L’attacco è compiuto in questo modo:

• un blog viene compromesso, e viene installato o modificato qualcosa che reagisce in modo differente secondo due parametri del visitatore: il referer e lo user agent
• Quando un visitatore raggiunge il sito viene controllato lo user agent: se è lo spider di un motore di ricerca la pagina visitata viene riempita di link di questo tipo:

  
  <a href="http://altroblog/?item=135" title="Buy Biaxin">Buy Biaxin</a>
  
  

  dove altroblog è il l’URL di un altro blog, appunto, oppure lo stesso URL del blog visitato. La stringa di query codificata nell’url può variare ed essere una di queste:

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

  Ce ne sono probabilmente anche altre varianti, ma tutte contengono nomi di medicinali all’interno della parte testuale del tag <a>.
  Il risultato è che il sito compromesso, che probabilmente ha un buon pagerank, punta ad un altro sito con pagerank anch’esso buono. La conseguenza è che in una ricerca ad esempio su Google con parole chiave indicanti farmaci, questi siti compariranno fra i primi restituiti.

• Qui entra la seconda fase dell’attacco: chi, cercando farmaci, clicca su uno di questi risultati in teoria dovrebbe finire sul blog, che in realtà non contiene niente del genere. Verosimilmente, il codice malevolo presente nel blog esamina il referer e se è un motore di ricerca viene risposto con un particolare header HTTP, il 302, con un link diretto al sito di farmaci online, ed il browser viene rediretto sul sito della farmacia.
• Se un regolare visitatore del blog, e quindi anche il proprietario, visita direttamente il blog o segue uno dei link trovati nel motore di ricerca con il nome del farmaco, il blog appare integro e senza cose strane. Il trucco è nel controllo di presenza di un cookie di sessione che ogni blog Wordpress inserisce nel browser di tutti i visitatori: se il cookie c’è, il sito appare normale, e il redirect è disattivato. Se si cancella il cookie e si clicca su uno dei link restituiti da Google nella ricerca di farmaci, il redirect avviene immediatamente.

In sostanza, si sfrutta il pagerank dei blog per avere più contatti al sito di farmaci online. Ma potrebbe non essere l’unico sfruttamento possibile, quindi evitate di giocare con browser vulnerabili.

Come diagnosticare il problema

Occorre semplicemente l’utility wget, possibilmente su una distribuzione Linux (per stare un po’ più tranquilli, ma non è essenziale).
Il primo test è per verificare la presenza del controllo user agent.

Si preleva la home page fingendo di essere lo spider di Google:

$ wget -U googlebot http://sito.sospetto/ -O spider.html

con questo comando salviamo la homepage del sito nel file spider.html. Il parametro -U googlebot serve a cambiare il nome del nostro user agent.

Di seguito si preleva di nuovo la home page senza presentarci come uno spider di un motore di ricerca noto:

$ wget -U xxf http://sito.sospetto/ -O normale.html

Poi si confrontano i due file. Se il file dello spider è molto più lungo, e presenta la sfilza di link con nomi di farmaci, il sito è compromesso.

Alcuni siti non presentano questo comportamento, ma solo quello del redirect. Per verificarne la presenza simuleremo un utente che arriva cliccando su un link restituito da una ricerca su Google, lo stesso link che viene mostrato associato ai singoli farmaci nel test precedente. Ad esempio, se il link mostrato è:

http://sito.vittima/?order_id=88

il comando wget da usare sarà:

wget --referer=http://www.google.it/search?q=cialis http://sito.vittima/?order_id=88 -O redirect.html

In caso di sito compromesso la pagina web scaricata appartiene a tutt’altro sito, a causa del redirect, ben visibile anche nei messaggi di lavoro di wget.

Altro sistema molto semplice per vedere se il proprio blog è stato compromesso è fare una ricerca con Google con questa stringa:
buy valium inurl:miourl
dove miourl è una parte del vostro nome del blog, una parte peculiare, ad esempio io cercherò cose come:
buy valium inurl:ismprofessional
Se i primi link riportati contengono il vostro sito con la formula di query mostrata sopra, oppure nella porzione di contenuto del sito mostrato da Google c’è una sequenza di “buy medicinale buy altromedicinale buy…”, è quasi certo che il sito è stato compromesso.

Altra cosa, un sito compromesso può mostrare tutti e due i comportamenti, ossia il redirect e la presentazione di pagine diverse a seconda dello user agent.

Siti al momento compromessi

Il totale dei siti compromessi che ho personalmente verificato è 18, e presentano uno o tutti e due i comportamenti (pagina forgiata per lo spider e redirect). Non appartengono allo stesso servizio di hosting, quindi escluderei un attacco di massa ad un singolo servizio di hosting.

Avevo pubblicato (stupidamente) la lista, ma l’ho tolta per non ingenerare confusione e non aiutare un eventuale script kiddie a scherzare con le disgrazie altrui. Alcuni sono stati contattati per e-mail o con un commento nel blog, per gli altri è impossibile contattare il proprietario o il responsabile, ed i commenti vengono ignorati.

In tre mi hanno risposto. Uno ha trovato il codice malevolo e lo ha rimosso, un altro mi ha detto che è un vecchio problema e che hanno aggiornato a Wordpress 2.5 alcune settimane fa. Peccato che il problema sia ancora presente. Gli ho scritto di nuovo, ma direi che il messaggio è caduto nel vuoto. Il terzo ha corretto un problema, ma il sito ora presenta il comportamento di redirect che prima non aveva, e gli ho notificato l’evoluzione.

Ho anche il sospetto che qualche messaggio sia stato intercettato da filtri antispam troppo zelanti, rivelando così un ulteriore problema: è difficilissimo avvertire qualcuno che stanno usando il suo sito per fare pubblicità al Viagra, senza usare parole come “farmacia”, “pillole”, “medicinale” ed incocciare nei filtri antispam. Insomma sembra una partita al noto gioco Taboo.

In definitiva l’esperienza è deludente. Certo, uno sconosciuto che ti scrive e ti dice che probabilmente il tuo sito è stato violato porta immediatamente a pensare che ci sia qualcosa di poco chiaro sotto. Ma non è che ci siano molte altre strade.

Considerazioni finali

Potrebbe non essere un problema di Wordpress, o almeno non solo. Se il vostro hosting non separa l’utente del web server dall’utente con cui scaricate i file nel server, che tradotto significa che il web server ha gli stessi diritti di scrittura nostri sui file di Wordpress, potrebbe essere una grossa facilitazione per portare a termine l’attacco.

A quanto pare alcuni siti usano wordpress 2.5, l’ultima versione, quindi potrebbe non essere sufficiente un upgrade.

Fino a quando non avrò a disposizione il codice completo di un sito compromesso non potrò dire altro. Ovviamente il team di Wordpress è stato avvertito dal 17 aprile.

Se avete dubbi, non esitate a cercare aiuto. Mi potete contattare usando le modalità indicate nella pagina apposita.

Primi dettagli sull’attacco

Grazie a Jay, abbiamo qualche notizia in più. A seguito di un primo attacco in cui aveva trovato codice Javascript iniettato nella homepage del blog, Jay aveva aggiornato WordPress alla versione 2.5. Questo aveva eliminato l’iniezione di codice, ma il comportamento di redirect era ancora al suo posto, indisturbato, e Jay non se ne era reso conto.

Dopo la mia segnalazione, esaminando meglio il server ha scoperto un file nella directory /tmp/ che era usato come plugin di WordPress, ma non era visibile dal pannello di amministrazione. Solo guardando dentro il database con phpMyAdmin lo aveva notato. A quel punto ha anche scoperto che c’era un account di livello admin chiamato WordPress, anche questo invisibile dal pannello di amministrazione.

Modificando a mano il database il comportamento di redirect è scomparso.

Ha anche trovato altri file PHP piazzati in varie altre directory, che contenevano codice capace di eseguire sia altri script PHP che comandi shell da remoto.

Purtroppo Jay non mi ha mandato i campioni di file iniettati nel server, per cui non ho altri dettagli.