In un prossimo seminario presso IISFA parlerò dei metodi di analisi relativi ad una intrusione in un sito web, al fine di trovare cosa è stato modificato, in che modo e quale sia lo scopo delle modifiche rilevate.

Per l’occasione userò il materiale raccolto negli ultimi tempi in alcuni incidenti di sicurezza riguardanti vari siti web, il cui proprietario ha dato naturalmente il consenso per l’uso. Una parte consistente sarà tratta dal lavoro fatto su numerosi blog con Wordpress compromessi in vari modi.

Siti puliti, o sporcati in modo differente

Con l’occasione ho dato uno sguardo a parecchi siti web “storici”, ossia compromessi da tempo, che non sono mai stati ripuliti. Alcuni sono lindi e innocenti come un neonato. Niente link, niente codice strano prodotto al passaggio di uno spider, niente di niente. La versione di Wordpress è esattamente la stessa di prima, cioè non è stato fatto alcun aggiornamento all’installazione, solo che l’infezione è sparita. In altri siti è cambiato il tipo di infezione, da quello più sofisticato, con il codice attivo nascosto nel database che reagisce agli spider dei motori di ricerca, ad un semplice blocco di codice HTML accodato ad uno o più post, di solito un tag <font>, <u> o <b>, con una istruzione di stile che serve a nascondere il blocco (tipicamente uno style=”display:none;”). Nel blocco, 100-200 link con le solite parole chiave, invisibili a meno che si disabiliti l’uso dei fogli di stile nel browser o si vada ad ispezionare il codice emesso dal server.

Probabilmente la presenza del blocco non è neanche visibile aprendo il post modificato nell’editor avanzato di Wordpress.

Cosa cambia

I siti rimasti con la vecchia infezione sembrano abbandonati dal mentecatto, ossia i link iniettati sono rimasti gli stessi da parecchio tempo. Alcuni siti che sono stati ripuliti usando un backup, senza quindi aggiornare, hanno subito una o due reinfezioni per poi essere lasciati in pace, segno che o il mentecatto ha capito che non ne vale la pena, o ha chiuso l’attività.

Sicuramente la reazione forte dei principali motori di ricerca, ossia il ban e la totale esclusione del sito dall’indice alla rilevazione dell’infezione, ha avuto la sua parte nella rinuncia del mentecatto, sempre se di rinuncia si tratta.

Per i siti ancora riportanti i link, il modello dell’intrusione è differente. Per poter modificare i post e aggiungere in coda i link nascosti è necessario molto meno lavoro e l’intrusione è molto meno profonda: non servono plugin nascosti, non servono modifiche ai file di Wordpress, non servono blocchi di codice nascosti nel database. E’ sufficiente operare solo la prima parte dell’intrusione per creare un amministratore nascosto, ed utilizzarlo per modificare a piacere i post già pubblicati. Il vantaggio è che non serve codice complesso o strane alchimie, è sufficiente avere tale account nascosto.

Il Wordpress Autotest

In questo frangente l’autotest è molto meno efficace, mancando gran parte delle firme caratteristiche dell’intrusione. Efficace nel senso che gli indicatori rossi sono molti meno, non meno efficace nel rilevare le stranezze. Quindi le indicazioni appaiono meno preoccupanti ad un osservatore poco attento. In pratica l’autotest è quasi inutile.

A questo proposito nelle prossime settimane aprirò il codice, mettendolo a disposizione di chi vuole studiarselo, visto la sua probabile inutilità.

Il pericolo non è passato

Il fatto che il nostro amico mentecatto abbia rinunciato, non vuol dire che i blog con versioni vulnerabili di Wordpress (ossia tutte quelle anteriori alla 2.6.5, al momento in cui scrivo) possano ritenersi al sicuro. Manco per niente. Quella che è passata è solo questa specifica tempesta di intrusioni, ma i siti sono ancora vulnerabili e sfruttabili per un numero incredibile di usi poco etici. Phishing, distribuzione di materiale proibito o illegale, spam, solo la fantasia (malata) di questa gente pone un limite. Ficcare un sito di phishing in un sito Wordpress compromesso è un gioco da ragazzi.

Per capirci, il nostro amico mentecatto non ha avuto alcuna particolare difficoltà a trovare il modo di violare tanti siti web. Basta fare un giro su alcuni siti web, fra cui il conosciutissimo e professionale SecurityFocus per trovare tutto quello che serve. In questi siti si trovano nel caso migliore solo dei PoC (Proof of Concept, dimostrativi) ossia dei brevi spezzoni di codice che mostrano come sfruttare il bug nel codice dell’applicazione. Mettere insieme alcuni di questi spezzoni e costruire uno strumento automatizzato per violare a catena un numero a piacere di siti web è una operazione banale per chi sappia maneggiare un po’ di codice.

Il motivo per cui questi spezzoni di codice vengono pubblicati è perché gli errori e le vulnerabilità sono note al produttore, che ha rilasciato la correzione da tempo, e che probabilmente sono arcinoti alla pletora di acari in giro per la Rete, quindi il passarli sotto silenzio è infinitamente più pericoloso che renderli pubblici. Se la serratura della mia auto si apre con una mina di matita senza lasciare tracce, io voglio saperlo. Ed il parallelo è quanto mai azzeccato, potete credermi sulla parola.

Se poi sappiamo dove andare a guardare ci sono in giro kit già pronti con tutto il necessario per trovare, violare e sfruttare a proprio piacimento siti web vulnerabili, utilizzabili da qualsiasi idiota che sappia come lanciare un programma. Ne ho parlato un due diverse occasioni, una delle quali era il convegno di CFItaly nel giugno 2008.

Quindi, torno a ripetere: il fatto, possibile anche se non confermato, che il nostro amico mentecatto abbia abbandonato la sua attività non è un segnale che autorizza a lasciare il proprio sito Wordpress (vale anche per Joomla, Xoops, Drupal, MediaWiki, ecc.) non aggiornato ad una versione obsoleta e vulnerabile. E’ un comportamento irresponsabile, niente di meno.

Niente di più facile che il sito vulnerabile sia usato come “testa di ponte” per attaccare l’intero hosting, situazione già verificatasi più volte. Per il proprietario del sito sarebbe una brutta storia, perché il servizio di hosting scaricherebbe la responsabilità della riuscita dell’attacco (giustamente, dico io) sul proprietario del sito web vulnerabile.

Insomma, spero sia chiaro che non c’è da scherzarci sopra. E per la legge italiana, chiedete conferma a chi volete, se qualcuno subisce un attacco dal vostro sito web, violato da qualcun altro, occorre dimostrare di aver fatto il possibile per evitare che succedesse. E non credo che il mancato aggiornamento di un software in versione notoriamente vulnerabile possa essere considerato “tutto il possibile”. Ed un avvocato considererà molto peggio una scusa del tipo “non mi funziona il template con le versioni nuove”.

Cosa ci insegna la vicenda

Che se da un lato è semplice e “trendy” parlare di Web 2.0 e social networks, a quanto pare parlare di sicurezza in Rete è considerato demodé, ed i risultati si vedono. Negli ultimi tempi gli attacchi si stanno facendo meno sofisticati, mantenendo di contro una altissima efficacia. Segno che non solo gli utenti sono impreparati ad affrontare un attacco di phishing o a base di social engineering, ma il dramma è che gli stessi professionisti del settore informatico sono poco preparati, quando non ignorano del tutto il problema.

Mi sono capitati sviluppatori, webmaster, grafici, sysadmin che non hanno la più pallida idea del livello di sicurezza richiesto per “andare in Rete”. In qualche caso mi è stato risposto che “basta prendere un hosting blindato”. Non mi stupirebbe che siano in molti a pensarla così.

Una cosa che personalmente ho imparato, e che mi ha lasciato molto perplesso, almeno all’inizio, è l’estrema difficoltà a far capire alle persone quanto pericoloso sia avere un sito vulnerabile, o peggio già violato. Lo dimostra anche il fatto che il mentecatto non è stato sconfitto, per niente. Ha rinunciato lui perché la strategia di piazzare link nascosti nei blog non è più efficace ai suoi scopi. Semmai è stato sconfitto dalla prontezza e dalle azioni di contrasto di chi gestisce i motori di ricerca, più che dalla reazione dei proprietari di siti violati. Tanto è che alcune persone mi hanno contattato alla ricerca di aiuto solo dopo che il dio Google li aveva eliminati dalla faccia del web, bannandoli dall’indice.

Altra cosa è che presentarsi per segnalare che un certo sito web è stato violato provoca spesso reazioni ostili, piuttosto che di attenzione o allarme. Insomma, o ti chiami con un nome notissimo (e magari con fama immeritata), o nella migliore delle ipotesi vieni ignorato. C’è stato un momento in cui ho temuto di essere scambiato per il nostro amico mentecatto… Ovvio, no? Prima ti “buco” il sito, poi mi presento e ti chiedo 500 euro per ripulirtelo.

Semmai mi è successo il contrario: vengo contattato perché il blog è stato bucato e una ricerca su Google restituisce il mio sito, ed alla mia offerta di dare una mano senza nulla chiedere mi viene detto che i blog in realtà sono di più, perché anche quelli di altri amici sono bucati.

Alla fin fine

Questo probabilmente sarà l’ultimo articolo dedicato alla vicenda, che per quanto mi riguarda ha esaurito la sua importanza, per non parlare del mio interesse in merito. Come ho già detto, nelle prossime settimane, se il mentecatto non si farà vivo con qualche altra trovata geniale, pubblicherò il sorgente del Wordpress Autotest, che contestualmente verrà eliminato dal mio sito. Non sono uno sviluppatore esperto di sicurezza, e non è una ipotesi peregrina che il codice possa contenere un disastroso errore, tale da compromettere la sicurezza del mio sito. Il codice è stato sviluppato in fretta e con il preciso scopo di fornire uno strumento di autoverifica affidabile e di facile uso per chi non ha le competenze necessarie.

Se il mentecatto ha rinunciato perché efficacemente contrastato da Google, il test è diventato inutile ed è privo di senso lasciarlo online, visto che potrebbe costituire un pericolo per il mio stesso sito.

Tutto ciò non deve autorizzare nessuno a dormire sonni tranquilli. Ogni giorno decine, forse centinaia di siti web vengono violati in modi sottili, perché la violazione spesso non si esplicita in un defacement, plateale ma inutile agli scopi di questa gente. Sempre più spesso il sito violato finisce per ospitare un sito per il phishing, o peggio un appoggio per materiale illegale da distribuire. Quasi tutti i siti di phishing che mi capita di trovare nei messaggi di spam che ogni giorno infestano la mia casella di posta sono “ospitati” in siti di ignari utenti che non hanno la più pallida idea di cosa stia capitando. Chi detiene un sito vulnerabile, e lo sa, sarà prima o poi vittima di un attacco del genere. E’ inevitabile. Lo dice lo spam.

Tags: code analysis, iisfa, Owned Wordpress