Il non-blog di Mario Pascucci

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

Articoli con tag Owned Wordpress

WordPress autotest: versione 1.10 e considerazioni.

Aug 12

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

Agosto, tempo di pensieri poco impegnativi e riposo da tutto.

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

Tags: , ,

Owned WordPress autotest: versione 1.9

Jul 14

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

Come ho più volte detto, il nostro amico mentecatto là fuori non dorme certo. Nuovi blog si aggiungono ogni giorno alle centinaia già sotto il suo controllo.

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.

Tags: ,

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: ,

Owned WordPress autotest: versione 1.5 rilasciata

Jun 24

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

Ho aggiornato il test di controllo per blog compromessi (vedi qui).

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.

Tags: , , ,

Owned WordPress Blog: test di contagio

Jun 5

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

Il test non è più disponibile dal 17 giugno 2009

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:

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

Tags: , , ,

WordPress + Pagerank + Spammer = PANIC!

Apr 18

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

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.

Tags: , , ,