Il servizio esegue dei controlli sul codice emesso dal web server del sito esaminato alla ricerca di indizi e segni tipici dell’intrusione che per oltre un anno ha devastato i blog basati su versioni obsolete e vulnerabili di WordPress. Oltre questo, propone di usare Google per individuare i segni esterni dell’intrusione.

Peccato che, dagli ultimi siti analizzati, l’iniezione di link abusivi sia praticamente sparita per fare posto a codice malevolo molto più pericoloso. Non so se il sito in questione faccia dei controlli in tal senso, ma posso affermare che tali controlli sono quasi impossibili da automatizzare, per una ragione molto semplice: mentre l’iniezione di link nascosti ha certe caratteristiche comuni e ben individuabili, le violazioni su cui sto indagando negli ultimi tempi inseriscono del codice PHP offuscato che produce pagine web con codice Javascript, a sua volta offuscato, che opera redirect o tenta di rifilare malware a chi visita il sito. Il modello di offuscamento cambia ogni volta e non è possibile trovare degli elementi comuni, tali da permettere un automatismo nella ricerca.

Insomma, il mentecatto, come sospettavo, si sta dando da fare. La soluzione è sempre la stessa: aggiornare prima di essere violati.

Fra questi, ho eliminato il test per i blog WordPress “0wn3d”, per vari motivi:

• Non è più efficace. L’ondata di spam, nascosto e mostrato agli spider dei motori di ricerca, è stata resa inefficace dalla reazione forte dei motori di ricerca stessi. I blog con ancora installate le vecchie versioni, o che erano colpiti dalla pestilenza, sono ora colpiti da varianti meno complesse ma infinitamente più subdole: iniezioni di Javascript colpiscono i visitatori tentando di rifilare malware estremamente dannosi; link singoli vengono nascosti in punti insospettabili; backdoor vengono insediate in punti poco evidenti. Insomma, il test è del tutto inefficace per queste varianti, ma chi ha un blog violato, anche se ha aggiornato all’ultima versione di WordPress potrebbe avere gravi problemi di sicurezza, non rilevabili facilmente dall’esterno.
• Nelle ultime settimane ha lavorato pochissimo, segno che l’interesse non è più così alto. Naturalmente, blog colpiti ve ne sono ancora tanti, ma i sintomi sono differenti.
• Il codice è stato scritto senza preoccuparsi troppo della correttezza formale e dei canoni della programmazione. Non è da escludere che contenga errori gravi abbastanza da compromettere l’intero sito. E non mi va di rischiare, senza nessun vantaggio.

Per questo motivo, la pagina del test è sostituita con un redirect a questo post. Se a qualcuno interessa, lo script PHP dell’ultima versione è disponibile per il download, senza nessun vincolo, a parte la licenza GPLv2.

WordPress Autotest v1.11 (zip)

Questo capitolo si chiude, ma il mentecatto è là fuori che trama. Il suo problema non è trovare siti vulnerabili da conquistare, no. Questo è semplicissimo. Il suo problema è trovare il modo di guadagnarci sopra, ma non dovrebbe essere troppo difficile inventarsi qualche birbonata.

Andiamo al motivo che mi ha fatto uscire dalla tana e scrivere queste poche righe.

Quando ho creato il WordPress Autotest, la mia intenzione era di fornire uno strumento automatico di diagnosi alla portata di tutti per verificare se il proprio sito era caduto vittima di un attacco molto specifico ed estremamente pericoloso. Al contempo, avevo pubblicato anche una guida rapida per riportare il blog con WordPress, attaccato e violato, sotto il nostro controllo legittimo.

Tramite il test, a distanza ormai di quasi un anno dall’inizio dell’attacco, ed a oltre otto mesi dalla pubblicazione del test, vengono tuttora scoperti blog violati sotto il controllo del mentecatto che ha dato origine a tutto questo, segno che il pericolo è tutt’altro che passato.

Quello che avevo immaginato è che coloro in possesso di un sito WordPress autogestito (in self-hosting, come si dice) dopo aver fatto il test e rilevata l’infezione, procedessero, da soli o con l’aiuto di qualcuno, alla pulizia seguendo le più elementari regole di buon senso, primo fra tutti un sano e robusto upgrade della versione di WordPress ad una che non offra occasioni di far birbonate ai mentecatti in giro per la Rete.

Invece quello a cui sto assistendo è che molti usano il test come un “allarme” per rilevare se è ora di ripristinare un backup. E rimettere la stessa identica versione di WordPress, lasciando di fatto il sito aperto ad una nuova intrusione che puntualmente si verifica nel giro di qualche giorno.

Immagino ci siano delle ottime ragioni per usare questa strategia, come ad esempio il dover rifare un template, o il rinunciare ad alcuni plugin assolutamente necessari, ma a questo punto perché non installare un plugin apposito come il WordPress Exploit Scanner. Faccio notare che il plugin funziona solo con WordPress 2.5.1 o successivo, perché (cito l’autore): “There’s not much point in finding exploited files if you’re running an old version of the software that can be broken into again.” (tradotto grossolanamente: non è molto utile cercare file modificati se si usa una vecchia versione che può essere sfasciata in qualsiasi momento).

C’è anche un altro problemino. Un sito bucato con questa tecnica potrebbe diventare la porta di ingresso in un hosting condiviso. Mi spiego: molti servizi di hosting impiegano dei software per far convivere tanti siti web sullo stesso server, mantenendoli separati sia dal punto di vista logico che dal punto di vista sicurezza. Ma i meccanismi di separazione non sono infallibili, e un singolo sito violato rappresenta una minaccia gravissima per tutti i siti ospitati sullo stesso server fisico. Tanto per fare un esempio, sullo stesso server su cui state leggendo queste righe sono ospitati centinaia di siti, tutti indipendenti uno dall’altro.

Non è un caso raro, anzi, mi sono capitati casi in cui siti perfettamente a posto sul piano sicurezza, o addirittura “statici”, ossia senza pagine dinamiche ma solo in HTML, fossero iniettati di schifezze a causa di una intrusione massiccia originata da un altro sito ospitato sullo stesso server.

Ad un certo punto, il mentecatto che usa i siti WordPress bucati per fare pubblicità a scrocco (il termine tecnico sarebbe black SEO o black hat SEO) potrebbe trovarsi tagliato fuori dai motori di ricerca, che stanno attivamente reagendo a queste tecniche di spamming con l’esclusione dei siti infettati dagli indici. Nessuno ci assicura che non possa prendere una strada differente e cercare di violare l’intero server, invece di limitarsi ad un singolo blog. Alcuni servizi di hosting prendono provvedimenti molto seri verso chi ha il sito “bucato”, a partire dalla diffida a provvedere a turare le falle, fino alla risoluzione del contratto ed alla citazione per danni. Leggete attentamente le clausole del vostro servizio di hosting e poi riflettete se è il caso di continuare a ripristinare un backup dello stesso sito, o magari non è giunto il momento di tappare qualche buco.

Nella bacheca, nello spazio di solito ospitante le notizie dal blog di sviluppo di WordPress, appare improvvisamente un avviso di aggiornamento immediato ad una fantomatica versione 2.6.4, di cui sul sito originale non vi è traccia. L’avviso è contrastante con il pulsante in alto, sempre nella bacheca, che afferma che l’ultima versione disponibile è la 2.6.3. Il link porta ad un falso sito di WordPress, residente sul dominio wordpresZ.org, dove l’ultima “s” del nome è sostituita da una “z”.

La versione distribuita da quel sito è contraffatta: nel file wp-includes/pluggable.php alla riga 598 sono state aggiunte 5 righe il cui scopo è trafugare cookie di autenticazione e di sessione di utenti registrati nel blog.

La domanda più importante è: come hanno fatto a modificare le impostazioni del “widget” che mostra i feed del blog di sviluppo di WordPress? Tali impostazioni dovrebbero essere modificabili solo da utenti con un livello di accesso alto, tipicamente un amministratore, e le impostazioni stesse sono conservate nel database. Ho provato ad ipotizzare tre scenari:

1. bug che permette un SQL-injection non ancora scoperto in WordPress 2.5.x e successivo
2. bug nel codice di modifica del widget che mostra i feed RSS nella bacheca
3. blog violato in precedenza, prima di un upgrade, con un amministratore abusivo

La prima la escluderei per un semplice ragionamento di economia: se c’è una vulnerabilità di questo tipo, perché non usarla direttamente per iniettare un amministratore abusivo nel blog e fare tutti i comodi da quell’account? Il fatto che la versione “troianizzata” si limiti a trafugare i cookie di sessione fa pensare che lo scopo è di operare tramite session hijacking per agire sul blog con le credenziali di un utente attivo in quel momento, quindi se lo scopo è questo, ossia operare nel blog, perché non creare al volo un utente amministratore tramite SQL-injection, operare ed eliminare poi l’utente per non lasciare tracce. Quindi escluderei questa ipotesi.

La terza è parimenti da escludere per le stesse ragioni: se c’è un amministratore abusivo frutto di una violazione precedente all’aggiornamento, perché non usare direttamente quello? I due blog che hanno avuto il problema non mostrano nessun segno dell’intrusione, e sono entrambi in versioni “non sospette”, uno ha la 2.5.1, mentre l’altro addirittura ha l’ultima versione ufficiale, la 2.6.3.

La seconda invece è abbastanza verosimile. Un bug limitato al solo codice di modifica delle impostazioni del widget limiterebbe l’effetto alla sola visualizzazione del widget e niente altro. Si spiegherebbe anche perché venga usato il falso sito con l’avviso per l’aggiornamento, per indurre l’utente ad autoinfettarsi installando la versione troianizzata.

Ulteriori indagini sono in corso. Se qualcuno ha notizie più fresche o ha elementi nuovi, non esiti a contattarmi. Se vi capita di avere questo messaggio che invita a passare alla versione 2.6.4 nella bacheca, non toccate nulla, fate un backup del database e dell’installazione di WordPress e contattatemi. E’ importantissimo poter analizzare questi dati per trovare il punto d’ingresso.

Aggiornamento delle 14.45

Il sito wordpresz.org è ora “down”, nel senso che non è più risolto dai DNS. Il record Whois è ancora presente, segno che il nome è registrato e non pare cancellato. Rimane comunque alto il livello di attenzione: potrebbero provarci con un altro sito, con nome differente, e tentare lo stesso trucco, o una variante. Rimane da stabilire quale sia stato il sistema usato per cambiare il feed nella bacheca, e se la mia ipotesi è vera potrebbero esserci sviluppi in futuro.

Instructions and results are in English language. Some documentation about WordPress spam injection and redirection is here.

Niente riposo invece per il nostro amico mentecatto. Anzi, si vedono le prime avvisaglie di una modifica allo schema di spamming, probabilmente per contrastare alcune misure prese dai maggiori motori di ricerca (grazie alle quali il rank di questo sito è collassato da 5 a 3, ma ormai ho smesso di farmi domande). Naturalmente, il numero di blog italiani compromessi continua a crescere, più velocemente di quanti ne vengano ripuliti, a cui vanno aggiunti quelli infetti da mesi e quelli ripuliti male, naturalmente di nuovo violati. La considerazione che ne emerge è che il mentecatto, informaticamente parlando, si dimostra più competente della media dei webmaster. Dovrebbe essere ormai evidente, fin qui, ma puntualizzare non guasta.

Alcuni dei test stanno perdendo di efficacia. Il numero di link emessi dal codice malevolo alla visita di uno spider è passato da 100 a meno di una quarantina, le parole utilizzate cambiano in continuazione, citando medicinali sempre nuovi. In effetti sto imparando nomi di prodotti farmaceutici mai sentiti prima. Stilarne l’elenco è sempre più difficile, data l’estensione del mercato. In questo modo due degli indicatori nel test, quelli con le parole proibite, spesso segnano giallo o addirittura verde. Le parole rilevate sono troppo poche.

Non basta: diventa più difficile trovare i blog compromessi tramite i motori di ricerca, non so che parole cercare. Sarà sempre più difficile scovarne, di blog, e di conseguenza sempre più difficile avvertire le vittime.

Di contro, il mentecatto è tutt’altro che in ferie. Nelle due ultime settimane ho trovato almeno quindici blog italiani che prima non erano presenti fra quelli compromessi, e che ora mostrano i segni della nuova strategia (pochi link e poche parole chiave), quindi a tutti gli effetti sono “freschi di violazione”. Sui blog compromessi da tempo, ed i cui proprietari sono stati avvertiti, anche da mesi, in media ogni pochi giorni cambiano i link e le parole chiave, altro segno che il mentecatto è ancora nella stanza dei bottoni.

Sul fronte temi infetti, oramai sono definitivamente convinto che il danno cerebrale sia irreversibile: proprio qualche giorno addietro ho notato nei log prodotti dal test uno dei test richiesti al controllo. Il link era alla demo di un tema WordPress, offerto da uno dei siti noti per offrire temi troianizzati. Ovviamente il test era negativo NON ESSENDO UN TEST PER TEMI DI WORDPRESS, ma il tema provato era naturalmente farcito con il solito codice PHP per inserire link pubblicitari, nascosto ed offuscato. Mi arrendo. Potrei mettere una domanda obbligatoria nel test, tipo “Hai capito che questo non è un test per temi infetti?”, ma scommetto che non servirebbe. Magari in una prossima versione del test la metto, giusto per farmi due risate.

Ah, a proposito: c’è un blog infetto da mesi nei primi cento di una nota classifica di blog italiani, da me avvertito alla fine di maggio.

Il test è al solito posto. Fatelo, e raccomandatelo ai vostri amici.

Trust no one

Cambiano le parole dello spam iniettato, e cambia anche sottilmente la struttura dello spam, per cui un aggiornamento del controllo è doveroso. Al momento i prodotti più pubblicizzati, oltre ai soliti medicinali di vario genere, sono: suonerie per cellulari, finanziamenti e mutui a basso costo, kit per sbiancare i denti e test per droghe. Gli ultimi due prodotti sono freschi freschi, trovati in tre del sette blog compromessi nelle ultime due settimane, ed in vari blog compromessi da tempo, segno che il mentecatto è più attivo che mai. Dormite sonni tranquilli, voi col blog bucato, il mentecatto veglia sui vostri blog. Chissà che non li gestisca anche meglio

Ho dovuto introdurre un semplice meccanismo di blacklist, perché a questo punto le cose sono due: o alcuni visitatori non sanno leggere o non leggono proprio. Non so quale delle due è peggio.

Il test non funziona NON SERVE su Splinder, Live, Blogspot, WordPress.com e simili, sono immuni da questa specifica pestilenza, c’è scritto nella pagina del test, ma continuano ad essere eseguiti controlli su questi domini. Quindi da oggi niente più test, c’è la blacklist.

Ma guarda tu a cosa tocca arrivare…

La pagina con il WordPress autotest è al solito posto.

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.

Le modifiche sono per lo più cosmetiche: viene stampato l’elenco sia delle parole chiave trovate con il conteggio, sia un campione dei link abusivi. Ho aggiunto alcune parole chiave nuove fra quelle controllate, visto che fra i link spam ora c’è anche la pubblicità per le suonerie dei cellulari.

Ho aggiunto un avviso sulla natura del controllo, che naturalmente è stato equivocato per un controllo sui temi troianizzati, invece che un test per vedere se il blog ci appartiene ancora, cosa un po’ più grave.

Ma di questo ho già parlato. Ieri ho avvisato altre sei persone che si trovano con il blog compromesso, e sono siti importanti. Indovinate un po’? Nessuna risposta.

Penso che a breve lascerò perdere questa indagine, e mi dedicherò ad altro. Il mio tempo è limitato e le cose da fare si accumulano, quindi sono costretto a scegliere.

Per ora non pubblicherò il codice del test per evitare che gli spammer possano cambiare lo schema di infezione e vanificare il controllo. Poi chissà.

Da questo momento, se avete il blog compromesso niente più avvisi e niente più aiuto gratis. Spiacente. Come si dice in inglese: you are on your own.

Per i dettagli

Segue il vecchio articolo

Avete dei dubbi sulla integrità fisica e sulla salute del vostro blog? Fate un test!

Mi spiego. Ho attrezzato una pagina PHP che effettua alcuni test automatici sul blog di cui viene fornito l’indirizzo completo. Il risultato è analizzato alla ricerca dei segni distintivi di questo tipo di intrusione: pagine differenti a seconda dello user agent, link contenenti i soliti farmaci venduti online ed altre stranezze. Al termine del test viene visualizzata una tabellina con i risultati.

Naturalmente, data la automaticità del test, il risultato è tutt’altro che certo, per cui occorre una verifica manuale in caso di segnalazione.

Cosa fa il test

• Tenta l’identificazione della piattaforma su cui si basa il sito, tramite un semplice fingerprinting: controlla se esiste una pagina di login, se nella home page esiste la parola “wordpress”. Se non trova questi segni caratteristici stampa un avviso ed esegue comunque il controllo. Ovviamente se si esegue il test su un sito non basato su WordPress il risultato è privo di senso, o comunque non significativo.
• Legge più volte la pagina principale del sito. Una volta la legge presentandosi come spider di un noto motore di ricerca, poi la legge di nuovo presentandosi come un normale browser. Se le due pagine sono differenti, vengono fatti dei controlli sulle differenze, alla ricerca di parole tipiche dello spam, di link e di righe troppo lunghe.
• Altri controlli vengono fatti sulla pagina restituita nella visita come spider, contando le parole tipiche dello spam, cercando stringhe esadecimali lunghe e particolari tipi di stile CSS atti a nascondere contenuto. Questi controlli sono “euristici” e la presenza di queste anomalie non è indice di infezione certa, ma se ne sono presenti più di uno, ed in numero consistente, conviene fare un controllo.
• Viene infine controllata la presenza di due particolari elementi nella pagina, indicatori certi di infezione, una sorta di firma dell’intrusione. Se si verifica la presenza di questi, anche uno solo, si è in presenza degli effetti di una violazione del sito.

Cosa non fa

Il controllo vale solo per WordPress installato su un sito dedicato, e solo per il tipo di intrusione documentato negli articoli elencati poco sotto. Non è un controllo antivirus, non è un rilevatore di intrusioni di qualsiasi tipo, né un controllo di integrità generico per WordPress. Non è neanche un “tester di temi contraffatti”: è impossibile da realizzare a tema installato, il tema va controllato prima di installarlo, e da una persona competente. Tanto meno può ripulire o “disinfettare” un blog compromesso: questo può farlo solo il proprietario o il webmaster, e non sarebbe neanche tecnicamente possibile senza operare con i dati di accesso del webmaster.

Se il sito è molto personalizzato, il controllo può fallire in tutti i sensi, cioè segnalare come infetti siti puliti e viceversa. Può non riconoscere un sito basato su WordPress, come può scambiare un sito costruito con altri software con WordPress. In tutti questi casi i risultati sono da prendere molto con le molle.

Il controllo non esegue alcuna operazione critica o intrusiva sul sito: esegue le stesse operazioni di chiunque lo visiti con un normale browser, niente di più.

Nota bene

Per evitare abusi e scherzi idioti, ogni richiesta è loggata e sono inseriti alcuni controlli preventivi. Uomo avvisato…

La pagina del test è qui.

Se volete altri dettagli, leggete gli articoli predenti elencati sotto, o contattatemi direttamente.

Gli articoli precedenti

Per chi vuole leggere tutta la storia, qui c’è l’elenco con tutti gli articoli che trattano dell’indagine sui blog violati:

• WordPress + Pagerank + Spammer = PANIC!
• Attention: your WordPress blog may be compromised. (in inglese)
• Spam con WordPress: esempi di codice iniettato
• Spam con WordPress: primi dettagli su un sito compromesso
• Spam con WordPress: altri esempi di codice iniettato
• Spam con WordPress: sempre più sofisticato
• WordPress: perché non basta l’aggiornamento

Di seguito alcuni consigli per diminuire il rischio di essere colpiti, e cosa fare quando succede:

• Come rinforzare le difese di WordPress
• Cosa fare quando si viene colpiti