Feeds:
Posts
Comments

Riprendiamo da dove avevamo lasciato.

Scopo di questa breve serie di suggerimenti è dare ai miei lettori qualche appiglio su come implementare strategie di difesa dai trojan che non si limitino al semplice “eseguire un antivirus”.

Per capire però quali strategie possono essere di aiuto è necessario sapere perché queste possono essere efficaci, e ciò richiede a sua volta qualche infarinatura di come avviene una tipica compromissione e quali sono i “canali” a rischio. Quindi meglio avere le idee chiare e specificare qualcosa al riguardo.

Da parecchi anni, il protocollo principe per la compromissione dell’utente è HTTP: allegare i binari alle email, infatti, funziona oramai molto raramente, dato che

  • poche realtà oramai consentono il transito di email contenenti eseguibili
  • quand’anche il transito è consentito formalmente, il livello di ispezione è molto alto e le soglie di intervento molto basse
  • il binario è destinato a rimanere nella mailbox anche per ore prima che l’utente lo apra, e ciò consente ai produttori di AV di realizzare e distribuire le firme in grado di riconoscerlo

Questi “difetti” non sono invece incontrati da meccanismi di propagazione che si basino su HTTP, in cui magari il mezzo SMTP viene utilizzato per “invitare” l’utente a seguire il link che lo porta al malware vero e proprio. Infatti in questo modo il malware puntato dal link può:

  • essere meno “identificabile”, dato che trattasi di un link ad un sito X
  • godere di una migliore “penetrazione”, dato che -diversamente dal filtraggio della posta- ancora non tutti utilizzano meccanismi di filtraggio della navigazione, anche in ambito business
  • essere costantemente aggiornato da chi lo distribuisce semplicemente sostituendo il file puntato, il che consente a costui di essere “un passo avanti” rispetto ai produttori di AV
  • essere depositato su siti compromessi (magari grazie al trojan stesso, che ha prelevato le password dell’accesso FTP relativo allo spazio web da un client già compromesso), in modo da sfruttare la reputazione di un sito del tutto lecito
  • essere molto più “smart”, dato che lato webserver c’è la possibilità di identificare (attraverso lo UserAgent annunciato dal browser) la piattaforma usata dall’utente e fornire di conseguenza del malware specificamente pensato per sfruttare le vulnerabilità della stessa

In particolare quest’ultimo punto ha portato ad una grande diffusione di meccanismi di infezione cosiddetti drive-by, in cui l’utente in pratica si ritrova con il client compromesso senza aver esplicitamente mandato in esecuzione alcunché. Lo schema tipico per queste infezioni (o almeno della versione più ricorrente di tali attacchi) è il seguente:

  1. il criminale (chiamiamolo con il nome corretto) acquista una VPS da qualche fornitore, di norma con i dati e la carta di credito di una delle sue vittime
  2. sulla VPS installa un exploit-kit (particolarmente diffuso è BlackHole), ovvero un servizio web che ha il solo scopo di individuare la piattaforma del visitatore e dare in pasto al browser tutti gli exploit noti per la stessa (i più ricorrenti prendono di mira Java, Acrobat e Flash, in ordine di popolarità; sapevatelo…)
  3. su N siti compromessi, il criminale esegue l’upload di un file javascript che esegue una banale redirezione verso la URL dell’exploit-kit
  4. su altri M siti compromessi, il criminale esegue l’upload di uno o più file HTML contenenti uno o più iframe che includono i javascript del punto 3
  5. a questo punto, il criminale invia una gran quantità di email (che tipicamente appaiono come notifiche provenienti da Facebook, LinkedIn, DHL, ecc) che invitano l’utente a cliccare -per le motivazioni più svariate- ad un link contenuto nell’email stessa, che punta alla pagina di cui al punto 4

Cosa accada all’utente a questo punto lo dovreste poter immaginare senza troppa fantasia.

Se avete letto la ricerca citata (e linkata) alla prima parte di questa serie di post, sapete di che parlo, e sapete anche come questo genere di attività si sia oramai strutturato in un vero e proprio mercato criminale, in cui qualcuno trojanizza grandi quantità di macchine, per poi rivenderne l’utilizzo a qualcun altro che le usa per instaurare delle botnet, che a loro volta vengono usate per erogare servizi illeciti (dall’invio di Spam alla possibilità di eseguire DDoS a qualche entità online), oppure  noleggiate ad altri, ecc.

Ciò che è interessante notare, tuttavia, è che vi sono, nello schema di infezione sopra descritto,alcune componenti estremamente variabili, ma più si risale la catena più il numero di risorse utilizzate per “erogare il malware” si riduce.

Se infatti le mail inviate dal criminale sono sovente abbastanza diverse tra loro, gli host relativi alle URL linkate nelle stesse appartengono ad una cerchia relativamente ristretta di sistemi compromessi. A loro volta, gli host che ospitano i file javascript inclusi nella pagina abusiva sono in numero ancora minore (su questo vi tocca fidarvi, o provare a fare qualche ricerca da voi analizzando i campioni di questo tipo che dovessero raggiungere le vostre mailbox). E, ovviamente, ancora minore è il numero di domini e/o indirizzi IP ospitanti l’exploit kit, dato che il criminale in questione paga una licenza (sì, veramente…) per ciascuna istanza che mette in linea.

Dopo tutta ‘sta manfrina, arriviamo alle conclusioni: dovrebbe risultare abbastanza evidente che, se riusciamo a impedire all’utente finale di raggiungere le risorse “preparate” dal criminale, di fatto possiamo riuscire a “salvare l’utente” dall’infezione.

Il come, però, lo demando alla puntata successiva… 😛

Continua…

Visto che a quanto pare i miei 4 lettori non son d’accordo con la chiusura di questo spazio, presumo di doverci scrivere qualcosa, di tanto in tanto.

E sia…

Periodicamente, quando mi capita di tenere presentazioni riguardo a spam, phishing, trojan etc, arriva la considerazione da parte degli auditori: “Nella mia rete gira $ANTIVIRUS, non dovrei essere sicuro?”

Ovviamente, la mia risposta è: “No!

Chiunque sappia come funziona un AV ha plausibilmente presente anche il fatto che questi in sostanza riescono ad intercettare quello che conoscono, ma poco o nulla possono riguardo a ciò che non conoscono. La conseguenza abbastanza ovvia è che è “sufficiente”, per i cattivoni, produrre nuove versioni di trojan abbastanza velocemente, e avranno la certezza pressoché matematica di riuscire a transitare indenni attraverso le difese del 90% delle loro vittime…

Ma scrivere un trojan “nuovo”, che non sia identificato dagli AV, è davvero così difficile? In pratica, non molto…

Invito chi fosse interessato ad approfondire a leggere questa ricerca riguardo ai meccanismi sottostanti la distribuzione di molto del malware in circolazione, ma per i pigri mi limito a quotare questo estratto:

Zlob affiliate downloader repacking. Unlike for the malware that their clients provide, PPI providers typically repack affiliate downloader binaries on a periodic basis and notify their affiliates to switch to the fresh downloader [29]. We found that the Zlob service has incorporated a twist on this approach. They provide a web service for affiliates to request a fresh binary, which, interestingly, apparently repacks the affiliate binaries onthe-fly. We requested the downloader for a single affiliate 27 consecutive times, resulting in 27 distinct, working Zlob binaries with identical sizes but differing MD5 hashes. Attackers could likewise apply such on-the-fly packing to other areas, such as drive-by-downloads, to create unique malware for each compromised host.

Se è troppo criptico, traduco: già da tempo sono a disposizione dei cattivoni strumenti che permettono loro di generare, a partire da un binario, un nuovo eseguibile diverso dall’originale in quanto ad “aspetto” ma del tutto equivalente in quanto a funzionalità, e farlo all’infinito, tutte le volte che vogliono, con l’ovvio obiettivo di rendere ardua l’identificazione del singolo binario per quel che è.

Il diretto risultato è che, di media, solo il 20-25% degli antivirus è in grado di intercettare questi malware nel momento in cui essi vengono “distribuiti”; e poiché di norma sul singolo PC può girare solamente un AV per volta, ciò implica che 4 volte su 5 il client è del tutto indifeso da trojan “appena rinnovati”.

Come migliorare questa situazione, quindi?

Un primo suggerimento viene dall’articolo di Brian Krebs linkato qui sopra: se per le attività critiche (come l’accesso alle funzionalità di home-banking) utilizzate una macchina dedicata, magari virtuale, linux-based ed “effimera”, è possibile limitare i danni: dato che questa macchina avrebbe una esposizione estremamente limitata ai “pericoli”, sarà difficilmente compromessa, e poiché essa riparte da uno stato “sicuro” ad ogni reboot, qualsiasi schifezza ci finisca dentro sparisce al primo riavvio. Ovviamente, se l’accesso a tale macchina avviene a partire da un client compromesso ciò non vi mette comunque al riparo da keylogger che stiano girando su quest’ultimo, quindi abbiate la percezione esatta di quali sono i limiti di questo approccio…

Nelle successive parti di questo articolo, invece, vedremo come poter limitare l’esposizione dei client agli “agenti infettivi” attraverso l’uso di strumenti come DNS, BGP e firme virali “ad-hoc”.

Continua…

…e chiudere ‘sto blog una volta per tutte? :-\

ClamAV Repository

No, non mi sono dimenticato di avere un blog.

Per ridicolo, anzi, la ragione della mancanza di nuovi post è dovuta al fatto che -se li scrivessi come li vorrei scrivere- non ne avrei il tempo. Sicché finisco per non scrivere niente…

Questa però è breve, quindi ho deciso di buttarla giù.

Chi tra voi si ritrova a gestire mailserver forse si sarà accorto che negli ultimi giorni è in corso l’invio di una discreta quantità di mail che hanno mittente e corpo relativo a NACHA, e che ovviamente non hanno nulla a che fare con nacha.org.

Si tratta di mail contenenti link a siti compromessi il cui ruolo è quello di far arrivare (attraverso una serie più o meno complicata di iframe e javascript) l’incauto visitatore ad un sito ospitante un exploit kit, che cercherà poi di applicare ogni exploit ad esso noto per la piattaforma del visitatore, al fine di trojanizzarne la macchina.

In pratica, malware drive-by.

Queste mail sono intercettabili attraverso svariati meccanismi più o meno complicati; dalla scrittura di ruleset che ne matchi il template all’uso di SPF (almeno per le non poche mail che riportano nacha.org a mittente di envelope), all’uso di servizi di domain-reputation (SURBL, DBL e URIBL in primis) che stiano listando il virtualhost compromesso.

Tutti questi meccanismi hanno un unico difetto: sono meccanismi pensati per il filtraggio dello spam, e utenti che non desiderino avere la posta filtrata rimangono esposti, ma non molti antivirus (di certo non clamav) riconoscono la mail come una minaccia, dato che -come sovente accade di questi tempi- essa non ha un payload effettivo, ma si limita a linkare un sito sostanzialmente lecito ancorché craccato.

Dato che già mi occupo di tracciare le URL compromesse per questo genere di attacchi, ho deciso quindi di automatizzare la generazione di un piccolo (almeno per ora) database di firme -basato sulle URL a me note- da dare in pasto a ClamAV.

Se interessa, lo trovate qui, attualmente solo-soletto:

http://clamav.bofhland.org/

Se lo volete usare, il mio suggerimento è di affiancarlo ad una oculata selezione dei database di SaneSecurity, utilizzando lo script fornito a corredo per prelevare anche il file della URL qui sopra. Sia chiaro e scritto con il sangue che lo fate a vostro rischio e pericolo, e che io non rispondo di niente. 😉

Attualmente è popolato solamente con un subset di quel che potrei metterci dentro, ovvero son i soli link relativi a malware “diretto” (come nel caso sopra descritto).

Potrei decidere di popolarlo anche con URL relative a pagine note per essere crackate ma che non sono direttamente coinvolte (ma potrebbero esserlo in qualsiasi momento) in tentativi di infezione dei client.

Oppure potrei creare un secondo database per questo secondo genere di “minaccia”…

Si accettano -ovviamente- suggerimenti…

 

UPDATE 03/02/2012: Per quel che vale, i database si sono già moltiplicati e sono diventati 3… 😛

Infiltrating the storm

Vecchio, ma chi non conoscesse già il tema botnet e dintorni apprezzerà ugualmente.

http://fora.tv/2009/10/21/Christian_Kreibich_Infiltrating_a_Botnet

%d bloggers like this: