Didier Stevens, un guru del formato PDF, oltre che di molte altre cose legate alla sicurezza, quella vera, non le chiacchiere, ha rilasciato una semplicissima applicazione che potrebbe essere l’uovo di Colombo, per alcune situazioni.

Ha connesso un sensore di temperatura a infrarossi con uscita USB al computer. Questo tipo di sensore è in grado di misurare la temperatura di qualsiasi cosa verso cui viene puntato, senza alcuna necessità di contatto, quindi anche a distanza.

Il sensore è puntato verso la sua sedia. Se la temperatura misurata scende sotto i 25° la sua applicazione blocca schermo e tastiera del computer, esattamente come quando parte lo screensaver del computer.

In pratica, se l’operatore si alza dalla sedia senza bloccare il computer, appena esce dal campo visivo del sensore termico il computer si blocca da solo. Utile per tutte le situazioni in cui un “occasionale passante” non debba leggere i dati sullo schermo di un computer rimasto senza operatore.

Personalmente lo userei al contrario: bloccare ogni accesso appena un essere umano vi si siede davanti, dato che la maggior parte dei problemi dei computer si trova fra la tastiera e la sedia… PEBKAC, you know.

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:

Usando varie tecniche (XSS, RFI, ecc.) gli attaccanti iniettano il codice Javascript in alcuni siti web vulnerabili. Il codice è profondamente offuscato, e lavora in modo nascosto e silenzioso, usando tag IFRAME e applicando stili CSS specifici per nascondere la propria presenza, oltre alle modifiche nelle pagine web attaccate.
Quando un visitatore arriva sulla pagina con il codice nascosto, il browser viene “dirottato” verso un server (sploitme.com.cc) che contiene codice attivo di analisi e di attacco. Per prima cosa il browser viene indirizzato con un apposito header HTTP di tipo 302 Found verso una pagina di errore
La pagina di errore è in realtà una trappola, ed è falsa, tanto che che l’analisi dei pacchetti di risposta dal server mostra un codice HTTP di risultato del tipo 200 OK, mentre la pagina simula un errore di tipo 404 Not Found (vedi pacchetti #63,174,366). Questa pagina, lato server, contiene in realtà un codice di analisi che controlla il tipo di browser.
In funzione del risultato dell’analisi (nel seguito se ne vedrà il tipo e lo scopo), nella falsa pagina 404 viene emesso un altro pezzo di codice Javascript, anche questo profondamente offuscato, che tenta di sfruttare varie falle nel browser per eseguire codice arbitrario.
Vi sono indizi (vedi pacchetti da #299 a #366) che il codice lato server sia in grado di capire da quale nazione giunga il visitatore, attraverso uno dei tanti servizi di geolocalizzazione, per escludere i visitatori da una certa nazione, o per includere solo quelli provenienti da una nazione, dall’essere colpiti. La prova viene dalla cattura stessa, dove viene visitato il sito principale di Google, www.google.com, che come sappiamo inoltra i visitatori verso i server di Google della nazione di provenienza: il browser viene inoltrato verso www.google.fr, ossia Google in francese. La visita immediatamente successiva fatta dallo stesso browser ad uno dei siti violati simulati (Il finto RapidShare) porta alla fine ad una falsa pagina 404 sul sito attaccante (sploitme.com.cn) che non contiene alcun codice Javascript (vedi pacchetto #366).

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:

Il codice iniettato è sempre offuscato, e qualche volta camuffato da altro, per cui facilmente passa inosservato, anche al webmaster più attento.
L’attacco viene portato senza aprire altre finestre o popup, per cui sembra provenire dal sito violato, non dal sito chiamato dal codice Javascript dentro i tag IFRAME.
L’attacco è portato appunto da un sito differente, che non compare mai nel codice, ma solo nel Javascript offuscato, per cui è impossibile saperlo senza svelare il codice stesso.
Anche svelando il codice Javascript offuscato e ricavando il nome del sito attaccante, ci si trova davanti ad una pagina 404 (falsa ma efficace).
Il codice Javascript che tenta di eseguire codice arbitrario sfruttando falle note è codificato usando la notazione Unicode con una escape sequence esadecimale (%u1234), e non è banale da decodificare.

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.

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:

La prima nel 2004 (all’epoca si chiamavano Scan of the Month) riguardava il reverse engineering di un malware “fatto in casa”.
La seconda è la prima sfida pubblicata nel 2010, dopo alcuni anni in cui non sono state pubblicate sfide. La sfida riguardava l’analisi di una registrazione del traffico di rete durante l’attacco di un malware. Non è andata molto bene, l’analisi era incompleta, per cui sono arrivato diciottesimo su 91 partecipanti.
La terza è la seconda sfida del 2010, riguardante l’analisi della registrazione del traffico di rete durante l’attacco portato al browser di un computer durante la navigazione. In questo caso posso dire che è andata decisamente meglio: primo a pari merito con altri tre sfidanti.
La quarta è la terza sfida pubblicata, riguardante l’analisi di un computer sospettato di essere attaccato da un malware in grado di rubare credenziali di accesso a servizi online ed altri dati riservati.

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“.

Attacco al browser, prima parte
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:

Vittime: 10.0.2.15, 10.0.3.15, 10.0.4.15, 10.0.5.15
Attaccanti: 192.168.56.52 (hostname: sploitme.com.cn)
Servizi: 10.0.2.2, 10.0.3.2, 10.0.4.2, 10.0.5.2 (DHCP server e gateway); 192.168.1.1 (DNS)
Host violati simulati: 192.168.56.51 (hostname: shop.honeynet.sg), 192.168.56.50 (hostname: rapidshare.com.eyu32.ru)
Host esterni: www.honeynet.org, www.google.com, www.google.fr, www.google-analytics.com

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

rapidshare.com.eyu32.ru/login.php: questa pagina contiene codice Javascript offuscato che carica in un tag IFRAME la pagina [2]
sploitme.com.cn/?click=3feb5a6b2f: questa pagina risponde con un header HTTP di tipo 302 Found, e dirotta i visitatori verso la pagina [3]
sploitme.com.cn/fg/show.php?s=3feb5a6b2f: una falsa pagina di errore 404, contenente una porzione di codice Javascript che cambia in funzione di che browser visita la pagina
sploitme.com.cn/fg/load.php?e=1: questa pagina restituisce un eseguibile binario per Windows che apre il sito [5]
www.honeynet.org: sito ufficiale del progetto Honeynet
www.google.com: Google
www.google.fr: Google in francese
www.google.fr/generate_204: una pagina di servizio di Google
shop.honeynet.sg/catalog/: anche in questa pagina c’è un pezzo di Javascript offuscato che carica la pagina [10] in un tag IFRAME.
sploitme.com.cn/?click=84c090bd86: identica situazione della pagina [2], con un header HTTP di tipo 302 Found, che dirotta verso la pagina [11]
sploitme.com.cn/fg/show.php?s=84c090bd86: questa pagina è una delle più interessanti. Contiene un pezzo notevole di codice Javascript, fortemente offuscato, che tenta di sfruttare un numero consistente di vulnerabilità note, quasi tutte relative a controlli ActiveX. Nel seguito dell’analisi vi saranno tutti i dettagli
sploitme.com.cn/fg/directshow.php: questa pagina è chiamata dal codice Javascript in [11], e contiene una falsa immagine Jpeg necessaria a sfruttare un bug in un altro controllo ActiveX
sploitme.com.cn/fg/load.php?e=3: stessa situazione della pagina [4]
sploitme.com.cn/fg/show.php: stessa situazione della pagina [3]
www.google-analytics.com: pagina di Google Analytics

Riassumendo, vi sono tre categorie di pagine:

pagine relative a siti web violati (simulati), con codice Javascript iniettato (pagine [1] [9]) che forzano il browser a caricare pagine da altri siti
pagine attive di attacco ([3], [11], [14], tutte con lo stesso URL di base) che scelgono che attacco sferrare in funzione del tipo di browser e della geolocalizzazione dell’indirizzo IP del visitatore
pagine di servizio: la root di sploitme.com.cn che opera un redirect con un header HTTP 302 Found; sploitme.com.cn/fg/load.php che in funzione del parametro “e” codificato nell’URL fornisce un eseguibile, verosimilmente un malware; sploitme.com.cn/fg/directshow.php che invece fornisce un file Jpeg forgiato al fine di sfruttare alcune vulnerabilità

Come si possa affermate tutto ciò sarà evidente nel seguito.

Fine della prima parte. Fra qualche giorno il seguito.