A buon intenditor…

Nell’attesa che mi torni la voglia di.
Per ora tutto tace.

A cosa serve

I requisiti per la stesura erano:

• Estrema semplicità d’uso, quindi poche opzioni di configurazione
• Minimo impatto sulle risorse di elaborazione. Molti hosting, al di là dello spazio, offrono realmente poco in termini di tempo processore, spazio database e banda Internet, per cui il plugin deve pesare il meno possibile, soprattutto sul database.
• Funzioni limitate e ben precise. Lo scopo è quello di rilevare modifiche ai file con contenuto in origine “attivo”, lato server o client, quindi solo PHP, HTML e Javascript, sui soli file di cui il webmaster ha conoscenza. Inoltre nessun controllo, voluto, agli uploads, per evitare messaggi ripetitivi ed inutili ad ogni singolo upload di qualsiasi file contenuto nei post.

Il plugin funziona calcolando gli hash SHA1 di tutti i file PHP, HTML e Javascript contenuti nello spazio di hosting di WordPress, ossia a partire dalla directory in cui è installato WordPress e tutto l’albero sottostante, tipicamente subito dopo l’installazione del plugin stesso, e memorizzandoli in una opzione della tabella wp_options di WordPress (quindi niente tabelle aggiuntive, con tutti i problemi che ne conseguono). Di questo database degli hash, il plugin calcola un ulteriore hash, chiamato hash primario, e lo manda via e-mail all’indirizzo dell’amministratore del blog. Questo hash serve a capire se il database degli hash è integro.

Per una installazione media come questo sito, il database degli hash prende circa 60k nel database. Appena disponibile il database degli hash, si può avviare un controllo ad intervalli dell’integrità, ogni ora, due volte al giorno o una volta al giorno a scelta. Se qualcosa non quadra, viene spedito un messaggio all’e-mail configurata.

C’è anche la possibilità di fare un check “a comando” dalla pagina di configurazione. Il plugin è internazionalizzato, ed ha già i file per italiano e inglese.

Il tipo di intrusioni rilevate appartiene alla categoria degli attacchi massicci all’intero hosting, o ad una parte di esso, in cui viene iniettato del codice (di solito PHP o Javascript) in tutti i file con contenuto attivo (PHP e Javascript, appunto) o HTML.

Non è in grado di rilevare un attacco mirato al blog, ossia se l’intruso trova il plugin installato ed attivo, può disabilitarlo, cambiarne il codice, insomma fare il suo comodo.

Installazione

Esplodere il pacchetto zip in una directory apposita dentro il deposito dei plugin, come qualsiasi altro plugin. I file necessari sono solo due:

• wp-autocheck.php
• wp-autocheck-it_IT.mo

Gli altri due sono il template per le traduzioni ed il sorgente per quella italiana, e non servono, a meno che non si intenda creare altri
file di lingua.

Uso

Appena installato, attivarlo nella pagina dei plugin, poi andare nel menu delle impostazioni, come amministratore del blog.
Ci sarà una pagina in più dal nome “WP-Autocheck”. Premere il pulsante “Ricalcola database degli hash”, poi scegliere una cadenza di
controllo, e verificare l’e-mail a cui spedire gli allarmi. Come valore predefinito viene usata quella dell’amministratore del blog, ma
si può cambiare. Al ricalcolo del database degli hash viene inviato l’hash primario per posta elettronica all’indirizzo indicato.

L’hash primario è calcolato sul database completo degli hash, quindi è un check di integrità del database. Ogni tanto conviene andare nella
pagina di impostazioni del plugin e controllare che non sia cambiato. Se è cambiato, qualcuno ha pasticciato con i file, il database o il
plugin.

Disabilitazione e rimozione

Per rimuoverlo conviene prima disabilitarlo, dato che alla disabilitazione vengono rimosse tutte le impostazioni ed i record dalla tabella del database wp_options, per cui non ne rimane traccia e si libera lo spazio occupato. Poi si può procedere alla rimozione dei file dallo spazio di hosting.

Download del plugin

Il plugin, completo di tutto, è qui:
wp-autocheck-0.1.0.zip

Data la scarsità di tempo (e di voglia), tendo ad aggiornare le cose solo se necessario, quindi vanno presi per come sono: senza alcuna garanzia né assistenza.

Mybook hacking

Come recuperare una piccola appliance (una micro-NAS di Western Digital), installando un sistema operativo da zero.

Prisma

Un semplice programma che permette di analizzare a colpo d’occhio il contenuto di file molto grandi o di interi dischi.

WP-Autocheck

Un plugin minimalista che funziona da allarme anti-intrusione per WordPress. Non è un antivirus e non è un IPS.

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.

La procedura di analisi

Non potendo accedere direttamente al contenuto originale dei siti, che permetterebbe una analisi puntuale ed accurata, quanto riportato è frutto di controlli e verifiche fatte dall’esterno, con strumenti assolutamente innocui: un browser, un editor di testo per programmatori, le utility whois, dig, host per ottenere informazioni pubbliche su IP e registro dei nomi DNS. Eppure, anche con così poche informazioni è possibile imparare molto sul phishing.

All’arrivo di ogni messaggio di posta elettronica palesemente di phishing, se ne salva una copia del “sorgente”, con tutte le intestazioni e le parti normalmente non visibili all’utente normale. Segue poi una visita sul sito di phishing, con prelievo di uno screenshot e del codice html della pagina così come emessa dal server. Se il sito è in hosting, il prelievo dei campioni finisce qui, altrimenti si tenta di arrivare al sito originale, catturando anche qui uno screenshot e l’html della pagina così come emesso dal server. In qualche caso è stato possibile visitare le directory intermedie fra il sito principale e il sito di phishing, acquisendo informazioni preziose su come e dove è avvenuto l’insediamento. In qualche caso è stato possibile mettere le mani sul sorgente originale del sito di phishing, lasciato in una directory intermedia da chi lo ha installato, di solito sotto forma di file ZIP o RAR.

Il materiale è poi analizzato e classificato per quanto possibile, ricavandone informazioni che ritengo interessanti. Ma basta con le chiacchiere, andiamo al sodo.

Quanti? Quali?

In tre mesi i messaggi ricevuti ed esaminati sono stati 73, non moltissimi, ma certamente sufficienti per costituire un campione con qualche significato statistico. Iniziamo con la distribuzione dei “bersagli”, ossia gli istituti di credito e servizi online presi di mira.

Distribuzione dei tentativi di phishing verso Istituti di credito e servizi online

I più bersagliati sono i clienti di Poste Italiane e di Intesa S. Paolo, seguiti da quelli di Cartasì, ma non mancano i soliti eBay e PayPal. In tutti i casi esaminati i siti di phishing sono praticamente indistinguibili dall’originale, se non per qualche dettaglio, di cui ci si accorge solo possedendo adeguate conoscenze: ad esempio i link sono tutti uguali, ossia conducono tutti alla pagina per inserire i dati, oppure vi sono piccoli difetti nella presentazione della pagina, poco evidenti.

Le cose naturalmente cambiano quando si va ad esaminare il codice html emesso dai siti di phishing. Tipicamente sono copie dei siti originali, prese con note utility, di cui spesso non viene neanche rimosso il marchio dai file, eccone un esempio:

<!-- Mirrored from www.monetaonline.it/layout/03069/pop/dispores_card_01.asp by HTTrack Website Copier/3.x [XR&CO'2008], Mon, 13 Apr 2009 23:59:09 GMT -->

In qualche caso il sito usa solo pagine html, le immagini vengono prelevate dal sito originale, diminuendo la dimensione necessaria ad ospitare il codice per mostrare ed eseguire la raccolta di dati.
Il metodo di raccolta dati preferito è l’e-mail, ossia al momento in cui il cliente vittima del phishing inserisce i suoi dati e preme il pulsante di conferma, vengono inviati per e-mail all’autore del phishing, in vari modi: se il sito è in PHP, viene usata la funzione mail(), in altri casi viene sfruttato un form di invio posta di un altro sito, legale, che però permette di inviare messaggi a chiunque semplicemente chiamandolo con i giusti parametri (vedere ad esempio questi due avvisi di sicurezza di Secunia). In qualche caso gli indirizzi di posta di destinazione sono in chiaro e perfettamente leggibili dalle pagine HTML del sito di phishing.

Veniamo ora alla questione di dove vengano ospitati i siti di phishing. Ebbene, come avevo premesso, per me non è una sorpresa, ma il grafico parla chiaro.

Dove vengono ospitati i siti di phishing?

Circa un terzo è ospitato in normali servizi di hosting, spesso gratuito, con dei trucchi per ritardare il rilevamento e la cancellazione del sito, come ad esempio l’uso di directory profonde per ospitare il sito di phishing, invece della home page, lasciata a quella di default, e l’uso di servizi di abbreviazione degli URL (come Tinyurl o Snipurl). Uno dei sistemi utilizzati è quello di registrare il nome del sito da un fornitore e prendere lo spazio di hosting da un altro, in entrambi i casi usando dati di identità falsi e differenti.

Oltre due terzi dei siti di phishing sono inseriti in siti web violati. In quasi un quarto dei casi i siti violati coinvolti sono due, differenti: il primo è quello di cui compare l’URL nella e-mail di phishing: una volta chiamato, il codice nascosto nel sito opera un semplice redirect con vari metodi al secondo sito violato, contenente il sito di phishing vero e proprio.

Per quanto riguarda il tipo di web application colpita nei siti violati, in gran parte dei casi non è stato possibile determinare se l’applicazione è preconfezionata, ad esempio un software open source o commerciale, o se è stato sviluppato ad hoc. Quello che appare da alcuni indizi è che in buona parte dei casi si tratta di applicazioni costruite a partire da una open source, cancellando ogni riferimento alla web application originale. Il problema è che molto probabilmente la base di partenza è una versione che a distanza di uno o due anni è obsoleta e verosimilmente vulnerabile a diversi tipi di attacchi, di conseguenza lo diventa anche l’applicazione da essa derivata, con ovvie conseguenze. Dato che chi cerca siti vulnerabili opera un fingerprinting della web application, l’operazione di nascondere, eliminare o modificare il contenuto dei messaggi di copyright dell’applicazione non sposta di un millimetro il problema. Anzi, proprio perché l’applicazione è modificata pesantemente è impossibile operare un aggiornamento in tempi rapidi, o spesso per motivi contrattuali non è proprio previsto, per cui il sito diventa e rimane vulnerabile a lungo.

Altre volte è proprio l’applicazione sviluppata a mostrare chiaramente problemi. In un caso, un sito che pubblicizzava “enlargement sessuali” (uno dei preferiti da chi fa spam), era costruito con una semplice web application in ASP, che non controllava per nulla i parametri di tipo URL-encoded che usava per mostrare i vari sottomenu. Inserendo una lettera al posto del numero in uno di essi appariva nel codice emesso un errore caratteristico delle applicazioni vulnerabili ad attacchi di tipo SQL-Injection. Eccone un esempio con uno dei parametri modificati appositamente:

<p>Microsoft JET Database Engine</font> <font face="Arial" size=2>error '80040e14'</font>
<p>
<font face="Arial" size=2>Syntax error (missing operator) in query expression 'nMenuNumb = cLNG(''0 or 1=1;'')'.</font>
<p>
<font face="Arial" size=2>/source/view_data.asp</font><font face="Arial" size=2>, line 38</font> 

Quando invece è stato possibile determinare con certezza l’applicazione colpita, i nomi che escono sono in un certo senso attesi.

Numero di siti violati e siti di phishing ospitati per tipo di web application

Sei siti con Mambo, uno con WordPress, due con Joomla, tre con phpBB, quattro con applicazioni commerciali, di cui ho trovato i rispettivi avvisi per vulnerabilità piuttosto gravi. Non sembrano molti, ma tenendo conto che chi li ha violati li sta sfruttando a fondo, il danno è rilevante: sia in quello WordPress che in uno di quelli con phpBB vi sono nascosti tre differenti siti di phishing e quelli con Mambo presentano anche i segni di altre intrusioni, volte a diffondere malware.

Dei 49 siti violati, solo 8 appartengono a privati, ossia sono personali o amatoriali. La parte del leone la fanno i siti delle società, seguiti a distanza dai siti istituzionali.

I siti delle società sono i più gettonati.

I siti di cui non è stato possibile determinare la categoria erano o sotto forma di puro indirizzo IP, oppure erano vuoti o quasi, al momento del phishing, forse abbandonati dai proprietari, o forse sorpresi a metà di una ristrutturazione, quindi non c’era indicazione della reale appartenenza del sito. Anche ricerche nella cache di Google hanno dato esito negativo, segno che i siti stessi erano da tempo in quella condizione.

Altro fronte di analisi è quello dei presunti autori dei tentativi di phishing. E’ ovviamente impossibile determinare con sicurezza se l’autore è lo stesso per due siti, ma quello che si può dire è che i siti confezionati per il phishing possiedono in qualche caso delle caratteristiche che li accomunano, ma a parte alcune eccezioni notevoli, i responsabili potrebbero essere differenti.

La sorpresa viene da uno dei siti di phishing impiantato nel sito con Joomla: il “wannabe” Grande Hacker ha lasciato in bella vista il file zip con il kit di phishing in una delle directory. Chissà se il Grande Hacker si è accorto che un Più Grande Hacker lo ha fatto fesso? Il kit di phishing è uno di quelli con la sorpresa, con un secondo indirizzo email offuscato e nascosto nel codice PHP.

Conclusioni

Per ora chiudo qui. Dovrebbe essere evidente il pericolo ed il rischio di avere un sito con una applicazione obsoleta, vulnerabile notoriamente a vari tipi di attacchi, come pure dovrebbe essere chiaro che anche un sito web sviluppato appositamente, se non è pensato in origine per resistere a vari tipi di attacchi, tutti arcinoti e ampiamente documentati, diventa una porta di ingresso per tutta la pletora di mentecatti in giro per la Rete. Il fatto che non sia disponibile il sorgente dell’applicazione non rende affatto più difficile il lavoro di chi ha intenzione di violare il sito per farci i suoi comodi.

Ed ancora, chi ha un sito violato non si aspetti di vedere segnali particolari o sentir squillare una sirena: le intrusioni sono estremamente silenziose, poco evidenti e ben tollerate da tutti i siti e applicazioni. Difficilmente sul sito si vedrà un defacement, o almeno non contemporaneamente all’apparire del sito di phishing. Potrebbe invece succedere che prima ci sia il sito di phishing, e solo dopo che abbia fatto i propri comodi l’autore del phishing abbandoni il sito al suo destino, dopo aver lasciato porte scardinate e finestre sfondate. A quel punto il defacement sarebbe il minore dei problemi.

Riferimenti

• PhishTank – un progetto collaborativo per segnalare i siti con phishing attivo, avviato dal team di OpenDNS
• Il progetto di protezione anti-phishing di Mozilla Firefox, in collaborazione con Google
• Il sito del Gruppo di lavoro Anti Phishing.

Il servizio esegue dei controlli sul codice emesso dal web server del sito esaminato alla ricerca di indizi e segni tipici dell’intrusione che per oltre un anno ha devastato i blog basati su versioni obsolete e vulnerabili di WordPress. Oltre questo, propone di usare Google per individuare i segni esterni dell’intrusione.

Peccato che, dagli ultimi siti analizzati, l’iniezione di link abusivi sia praticamente sparita per fare posto a codice malevolo molto più pericoloso. Non so se il sito in questione faccia dei controlli in tal senso, ma posso affermare che tali controlli sono quasi impossibili da automatizzare, per una ragione molto semplice: mentre l’iniezione di link nascosti ha certe caratteristiche comuni e ben individuabili, le violazioni su cui sto indagando negli ultimi tempi inseriscono del codice PHP offuscato che produce pagine web con codice Javascript, a sua volta offuscato, che opera redirect o tenta di rifilare malware a chi visita il sito. Il modello di offuscamento cambia ogni volta e non è possibile trovare degli elementi comuni, tali da permettere un automatismo nella ricerca.

Insomma, il mentecatto, come sospettavo, si sta dando da fare. La soluzione è sempre la stessa: aggiornare prima di essere violati.

Fra questi, ho eliminato il test per i blog WordPress “0wn3d”, per vari motivi:

• Non è più efficace. L’ondata di spam, nascosto e mostrato agli spider dei motori di ricerca, è stata resa inefficace dalla reazione forte dei motori di ricerca stessi. I blog con ancora installate le vecchie versioni, o che erano colpiti dalla pestilenza, sono ora colpiti da varianti meno complesse ma infinitamente più subdole: iniezioni di Javascript colpiscono i visitatori tentando di rifilare malware estremamente dannosi; link singoli vengono nascosti in punti insospettabili; backdoor vengono insediate in punti poco evidenti. Insomma, il test è del tutto inefficace per queste varianti, ma chi ha un blog violato, anche se ha aggiornato all’ultima versione di WordPress potrebbe avere gravi problemi di sicurezza, non rilevabili facilmente dall’esterno.
• Nelle ultime settimane ha lavorato pochissimo, segno che l’interesse non è più così alto. Naturalmente, blog colpiti ve ne sono ancora tanti, ma i sintomi sono differenti.
• Il codice è stato scritto senza preoccuparsi troppo della correttezza formale e dei canoni della programmazione. Non è da escludere che contenga errori gravi abbastanza da compromettere l’intero sito. E non mi va di rischiare, senza nessun vantaggio.

Per questo motivo, la pagina del test è sostituita con un redirect a questo post. Se a qualcuno interessa, lo script PHP dell’ultima versione è disponibile per il download, senza nessun vincolo, a parte la licenza GPLv2.

WordPress Autotest v1.11 (zip)

Questo capitolo si chiude, ma il mentecatto è là fuori che trama. Il suo problema non è trovare siti vulnerabili da conquistare, no. Questo è semplicissimo. Il suo problema è trovare il modo di guadagnarci sopra, ma non dovrebbe essere troppo difficile inventarsi qualche birbonata.

Ringrazio di nuovo l’Associazione e Gerardo Costabile per l’opportunità concessami.

Presenterò due casi reali, presi fra quelli su cui ho lavorato, con le tecniche e le considerazioni relative all’analisi per individuare punto d’ingresso, modalità e scopi dell’intrusione. Uno dei due casi riguarda un blog WordPress compromesso.

Sul sito IISFA tutti i dettagli del seminario, e le informazioni per raggiungere la località. Per chi fosse interessato all’argomento, è il caso di prendere in considerazione l’iscrizione all’associazione.

Per chi partecipa, ci vediamo là.