Proteggersi (o almeno provarci) dai Trojan – Part 2

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…