Feeds:
Posts
Comments

Archive for June, 2012

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…

Read Full Post »

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…

Read Full Post »

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

Read Full Post »

%d bloggers like this: