Intense Minimalism

Hacked, restored.

Intorno al 22 di marzo pare che qualcuno sia riuscito ad entrare in alcuni dei miei domini (incluso questo blog) ed installare dei simpatici script. Sono state fatte alcune cose:

1. Hanno sparso per i filesystem dei file con nomi “simili” a quelli esistenti (xml.php, stream.php, …) che però avrebbero consentito l’upload e la modifica remota dei file da parte di chiunque avesse un cookie specifico (gli script sono c99 e r57shell).
2. Hanno editato alcuni file aggiungendo link di spam nei template (curiosamente, anche file di codice mio completamente custom, son andati a cercarsi il template).
3. Hanno editato wp-settings.php delle installazioni di WordPress (indipendentemente dalla versione presente) con un codice eval() scritto oltre il normale spazio visivo di un editor testuale (per intenderci, una riga che inizia con molti spazi). L’eval in questione iniettava un redirect 301 (permanent) verso un sito solo per i crawler dei motori di ricerca.
4. Hanno editato .htaccess delle installazioni di WordPress aggiungendo molte righe vuote ed in fondo un altro redirect analogo al precedente: solo per i crawler (redirect su bablo.me.uk).

Mi sono accorto della penetrazione un paio di giorni fa, a causa di un netto calo delle visite (sceso circa dell’80%). Visite che prima arrivavano sostanzialmente da Google. Ero sparito dalle classifiche su Google (folletto, intense minimalism, davide casali solitamente mi trovavano in prima pagina), pur rimanendo nell’indice. Ho aperto un topic sull’assistenza di Google Webmaster Tools (e ricevuto i consigli in privato di un paio di persone, grazie) e un googler alla fine mi ha segnalato la discrepanza: Googlebot vedeva un redirect 301 verso un altro sito.

Un hack piuttosto furbo.

Per verificare questa situazione potete usare dei siti (1, 2; specificando “Googlebot”) oppure un comando da linea di comando Mac o Linux (curl):

curl --user-agent "Googlebot" http://im.digitalhymn.com/

Provato se guardando solo Googlebot non risulta di suo evidente, basta provare anche con un user agent normale e poi con Googlebot in modo da notare le discrepanze.

I punti 3 e 4 che ho spiegato sopra son abbastanza bene delineati in questi due post che ho trovato mentre analizzavo i miei siti: “Exploit Redirects Googlebot to Malware Sites (Bablo me uk)” e “Did your WordPress site get hacked?“, piuttosto esaurienti.

Ecco cosa appariva come header (redirect 301) mentre i siti erano hackati:

HTTP/1.1 301 Moved Permanently
Date: Tue, 07 Apr 2009 15:35:49 GMT
Server: Apache/2.0.63 (Unix) PHP/4.4.7 mod_ssl/2.0.63 OpenSSL/0.9.7e
mod_fastcgi/2.4.2 Phusion_Passenger/2.0.6 DAV/2 SVN/1.4.2
Location: http://bablo.me.uk/
Vary: Accept-Encoding
Content-Length: 227
Content-Type: text/html; charset=iso-8859-1

Per trovare le modifiche ho fatto affidamento a due tools fin da subito: la data di modifica del file e SVN, con il quale installo quasi sempre le mie versioni di WordPress e simili.

La cosa curiosa in assoluto è stata però che la modifica ai file wp-settings.php non mi veniva segnalata da “svn status”. O mi è sfuggito qualcosa nelle varie verifiche che stavo facendo, oppure non so. Quando ho copiato in locale la cartella per fare ulteriori verifiche, TextMate invece ha trovato che il file era modificato.

Se qualcuno volesse visionare i files e il codice utilizzato per l’attacco e le modifiche ho salvato quasi tutto. Fatemi sapere (un commento con la mail è sufficiente).

Capitasse nuovamente, o capitasse a voi, ecco in sintesi le verifiche che ho fatto:

1. Verificare la modifica su GoogleBot (con curl, wget o analogo web).
2. Verificare la bash history se avete una login via SSH.
3. Verificare .htaccess, wp-config,php, wp-settings.php e i template (i file più frequentemente attaccati).
4. Utilizzare svn per verificare le modifiche fatte (svn status).
5. Utilizzare le date di modifica dei file per vedere se è stato modificato qualcosa (ls -la)
6. Verificare la differenza del codice rispetto ai backup.

Per quanto volendo si potrebbe semplicemente ripristinare la situazione da un backup, questi controlli permettono di capire con maggiore precisione cosa sia successo.

La domanda a questo punto è: da dove sono entrati?

Difficile dirlo. Questo blog ha l’ultima versione di WordPress installata. Di routine ho cambiato tutte le password adiacenti agli account che sono stati toccati, ma credo che l’attacco sia stato fatto tramite alcune vulnerabilità esistenti su xmlrpc.php di WordPress: sono stati sistemati sulle ultime versioni ma… avevo alcune versioni vecchie installate.

Qui nasce un dubbio: io quelle versioni di WordPress non posso aggiornarle, si riferiscono a vecchie edizioni e vorrei tenerle per motivi storici. Ho disattivato il disattivabile (fra cui un bel delete di xmlrpc.php) controllando alcune vulnerabilità segnalate, ma… come fare? Il problema è abbastanza rilevante: non è possibile aggiornare quelle versioni, perché utilizzano codice e componenti ad-hoc e aggiornarle equivarrebbe a rimuoverle. Qualcuno ha idee? Tutto quello che mi viene in mente richiederebbe una manutenzione abbastanza eccessiva (aggiornare tutto, fare un plugin di “lockdown”, staticizzare il sito, …).