[MonoURL] BTW, Proteggersi dai trojan (o almeno provarci)

http://www.senki.org/archives/966

Read Full Post »

Proteggersi (o almeno provarci) dai Trojan – Part 4

Con un po’ di fatica, continuo questa disamina…
Avevamo visto nelle puntate precedenti come “segare a vista” alcune comunicazioni quando dirette ad entità malevole e/o compromesse possa aiutare in misura sensibile a limitare l’esposizione agli agenti infettivi e, in particolare, come affidarsi a  RPZ per posizionare parte di questa funzionalità all’interno del nostro resolver.

Tuttavia, come detto in uno dei primi episodi di questa serie, la prima cosa che viene alla mente quando si parla di “bloccare traffico” è il firewall. Perché non usare dunque le sue funzionalità?

L’idea è certamente buona, e certo non è nuova, ma ha un problema: poiché il nostro obiettivo è bloccare del traffico che normalmente consentiamo (come la navigazione web, ovvero la porta 80/TCP outbound) in virtù della nozione che alcune destinazioni non sono sicure, quel che ci serve è un ruleset dinamico, che ci permetta di far evolvere le nostre regole nel corso del tempo.

Per poterlo ottenere, ci servono due cose:

1. Uno o più fornitori di intelligence, in grado di fornirci i dati che ci servono per applicare dei blocchi mirati
2. Un framework che ci consenta di alimentare il ruleset dei nostri firewall con i dati succitati

Tutto sommato, non siamo in una situazione molto dissimile da quella del DNS che abbiam trattato la volta precedente…

Poco sorprendentemente, quindi, troviamo che lo scenario anche qui è lo stesso: per quanto riguarda i dati di intelligence, abbiamo i diversi progetti collaborativi con finalità di cyber-security, purché ci forniscano degli IP. Prima tra tutti la già citata Spamhaus.

Il vero problema è invece la disponibilità di un framework con cui poter alimentare i motori di filtraggio: ogni fornitore di firewall ha la sua GUI, a volte la sua CLI e (quando li ha) meccanismi di update dinamico dei dati di filtraggio la cui implementazione è chiusa e gestita centralmente dal fornitore, ergo pressoché inutilizzabile.

Ecco perché fare ‘ste cose direttamente sul firewall può rivelarsi estremamente ostico: è pur vero che, se c’è una CLI da poter utilizzare, in qualche maniera (expect e sue varianti?) si può scriptare qualcosa, ma non è certo una cosa semplice da realizzare nè alla portata del “tecnico medio”…

Fortunatamente, ci sono altre strade O:-)

Se ci pensate un poco, a conti fatti le funzionalità di un firewall non ci servono. Segare tutto il traffico da/per un determinato IP che si sa essere in mano a criminali non è in linea di massima un grosso problema; anzi, forse è la cosa più saggia… 😉 Questo ci lascia un’alternativa quasi migliore: saltare a piè pari la necessità di istruire un firewall e concentrarci sul come istruire un normale router, che può essere il router posto davanti al firewall o il firewall stesso: comandandogli di eseguire nullroute di tutto il traffico da/per gli IP che sappiamo essere malevoli, otteniamo esattamente lo stesso effetto.

“Bene” -mi si dirà- “ma perché istruirlo a fare il router dovrebbe essere più semplice che istruirlo a fare il firewall?”

Per due ragioni, in sostanza:

1. scriptare qualcosa che “comandi” il router è necessità tutt’altro che rara, in parecchi ambienti. Ciò fa sì che esistano librerie specifiche, in diversi linguaggi, che rendono il compito abbastanza agevole (la prima che mi sovviene è Net::Telnet::Cisco disponibile in Perl…)
2. poiché per far eseguire nullrouting al router dobbiamo nientemeno che passargli delle rotte, la CLI/GUI/API non è l’unico modo per farlo, nè il più comodo: i protocolli di routing sono stati inventati appositamente per quello, e fanno tutto da soli o quasi. In particolare BGP, oltre ad essere particolarmente adeguato allo scopo, gode anche di parecchia documentazione su come è possibile usarlo a tal fine.

In particolare il fatto di affidarsi a BGP affinché provveda lui ad istruire il router consente di spostare la componente di scripting altrove, ad un più tradizionale OS general purpose purché dotato di un routing daemon che supporti BGP. Quagga, per dire, è estremamente semplice da usare e più che adatto allo scopo.

In questo post non entrerò nel merito di come realizzare la struttura in questione; al limite ne scriverò a parte, per chi non fosse autonomo nell’implementarla da sè.

Voglio invece tornare sull’aspetto “sorgenti di intelligence”…

Quali dati usare per finalità di questo tipo?

Ci sono diverse scelte, che in parte si sovrappongono e in parte si completano, e che -se avete la pazienza, la competenza e l’autonomia decisionale di vagliarle- vi possono consentire di raccogliere buona parte dei dati necessari senza fare lavoro di intelligence da voi.

Da diversi anni, Spamhaus mantiene una lista di reti direttamente controllate da criminali, la cui finalità è esattamente quella di consentire il filtraggio a livello di router di confine. Si tratta di DROP, recentemente integrata da EDROP (non mi dilungo a spiegare la differenza tra le due: la trovate direttamente sul sito di Spamhaus; basti dire che, a meno che non siate un ISP, per le finalità qui descritte sono equivalenti). Di cosa sia in grado di fare DROP ne ho già parlato in passato, per quel che vale…

In DROP si trovano elencate reti estremamente permissive nei confronti dei propri utenti, tanto da consentire loro di far girare operazioni platealmente illegali garantendo (nei limiti del possibile) che esse non verranno interrotte a seguito di segnalazioni. Come immaginabile, è questi in servizi c.d. bulletproof che le operazioni veramente brutte si concentrano…

Tuttavia, proprio come conseguenza della notorietà cui queste reti sono soggette e della relativa facilità con cui è possibile isolarle, oggi come oggi parecchi degli exploit kit (vedi seconda puntata) vengono pubblicati su macchine dedicate appartenenti alle reti dei grossi datacenter e fornitori di VPS: è pur vero che in tal modo resteranno probabilmente in piedi solo per alcune ore prima che l’operatore -informato di cosa sta accadendo- le termini, ma per molte delle attività di Pay Per Install questa finestra temporale può essere sufficiente.

Soprattutto, ciò spiega anche quale sia lo scopo del layout a livelli multipli che abbiamo analizzato nella seconda puntata di questa serie di articoli. Se è vero infatti che l’host che esegue l’exploit kit può divenire indisponibile da un istante all’altro, è anche vero che lo spam-run inviato dal nostro malfattore non punta ad esso, ma ad uno o più siti del tutto leciti nei confronti dei quali i tempi di intervento degli operatori sono assai più dilatati. Sono poi queste pagine compromesse a portare l’incauto visitatore (direttamente o indirettamente) all’exploit kit. Se quest’ultimo diviene indisponibile, tutto ciò che il criminale deve fare è modificare le pagine già uploadate affinché linkino una nuova istanza dell’exploit kit, in esecuzione altrove.

In tal modo, il run di mail già inviate e contenenti un link non va buttato e mantiene inalterata la sua utilità, cosa che non avverrebbe se le mail linkassero direttamente l’exploit kit.

Ora: per via di come è strutturata l’accoppiata DROP+EDROP, singole macchine su reti lecite non vi sono incluse; quindi usando solamente queste due non le blocchereste. Ciononostante gli IP dove avvengono queste attività sono ugualmente noti a Spamhaus, che li eroga sotto forma di listing SBL…

Per renderli utilizzabili (ed in una maniera “semplice”) Spamhaus ha pertanto iniziato a mettere a disposizione dei propri utenti un feed BGP, attraverso cui fornisce i dati presenti in DROP+EDROP insieme con i singoli IP dei sistemi come quelli sopra descritti estratti da SBL. Al pari di RPZ, anche questo è al momento un servizio che Spamhaus offre ai soli clienti e non all’utenza generica; ma se già avete accesso al datafeed con tutta probabilità potete richiedere l’attivazione di BGPf già ora: senza nemmeno prendervi la briga di scriptare alcunchè, tutto ciò di cui avete bisogno è un router (o un firewall) che supporti BGP…

Read Full Post »

Piccola ricerca….

Chi volesse compilare questa form ha i miei ringraziamenti in anticipo…

Read Full Post »

Proteggersi (o almeno provarci) dai Trojan – Part 3

Proseguiamo il monologo 😀

Come argomentato nella puntata precedente, un buon meccanismo per limitare infezioni da trojan consiste nel rendere irraggiungibili agli utenti i veicoli di infezione, che tipicamente sono webserver. Come farlo, quindi?

Il primo strumento che viene in mente in questi casi è ovviamente il firewall perimetrale della rete. Ma siccome così è troppo facile (ma poi vedremo che tutto sommato così facile può non essere) partiamo da tutt’altro: il vostro DNS di risoluzione…

Non è esattamente il primo oggetto che viene in mente quando si tratta di security, ma l’utilizzo in quest’ambito è ampio e datato. Il concetto è molto banalmente questo: quando un client della vostra rete deve raggiungere un determinato sito (diciamo http://www.malicioussite.com) per prima cosa ne domanda l’IP al server DNS di risoluzione. Se su tale nameserver configurate una zona “www.malicioussite.com.” e vi create all’interno un record del tipo

@    IN    A    10.11.12.13

quel che accade è che il client in questione raggiungerà il vostro host interno dotato di tale IP, anziché contattare il “vero” server che risponde a quel nome.

Se http://www.malicioussite.com era il sito usato dal malware per l’infezione dell’utente, avete impedito all’utente di farsi del male, senza alcuna necessità di affidarvi a firme virali, che potrebbero non essere sufficientemente aggiornate.

Banale. E nulla di nuovo, appunto: gran parte degli ISP fa questo genere di “giochino” da diversi anni, per le esigenze più svariate. Ci sono un po’ di  problemi, però:

1. per applicare questo approccio, bisogna avere a disposizione un elenco di hostname/domini che ospitino malware
2. poiché tale elenco varierà più o meno di continuo, è necessario che la creazione (e la rimozione) di tutte le “zone fittizie” avvenga automaticamente
3. le tempistiche sono importanti: se non si “blocca” la raggiungibilità del sito malevolo abbastanza in fretta, è facile che l’utente lo “visiti” prima che le nostre contromisure siano in funzione. Questo si può sposare molto male con setup impostati basandosi su script che creino tutte le direttive per le zone fittizie da bloccare, le “diano in pasto” al DNS e facciano ricaricare a quest’ultimo le configurazioni aggiornate, poichè difficilmente questa operazione può essere eseguita in continuazione

Come gestire un setup di questo genere in maniera efficace, quindi?

A venirci in aiuto è una funzionalità implementata nelle versioni più recenti di BIND (>= 9.8), chiamata RPZ (che sta per “Response Policy Zones“). Se volete vedervi in dettaglio le specifiche di implementazione vi rimando volentieri alla documentazione ufficiale relativa (cercate il paragrafo denominato “Response Policy Zone (RPZ) Rewriting“), oppure questa breve serie di slide che ne illustrano scopi e funzionamento.

Per le esigenze di questo post basti dire che in pratica funziona pressappoco così:

• un “fornitore” pubblica la lista di hostname/domini da oscurare via DNS e vi consente l’accesso alla stessa
• voi configurate una entry sul vostro BIND che fa riferimento a tale lista
• il vostro server si “porta in locale” la lista attraverso un Zone Transfer e inizia direttamente ad usarla per inibire l’accesso alle risorse ivi listate
• ogni volta che il fornitore della lista la aggiorna, le modifiche raggiungono automaticamente il vostro resolver attraverso le funzionalità di Incremental Zone Transfer (IXFR) native del protocollo DNS, sicché siete allineati in pochi secondi

Questo copre in sostanza sia il punto 2 che il punto 3 dell’elenco di problemi sopra riportato.

Ci rimane ancora da risolvere il punto 1. Ovvero: chi ci può mettere a disposizione ‘sto servizio?

Più o meno, le stesse entità che vi forniscono (direttamente o indirettamente) i dati relativi a domini usati per scopi poco simpatici; con poca sorpresa, a partire dalle liste antispam. Sia Spamhaus che SURBL forniscono accesso ai propri dati attraverso RPZ. Se quindi usate già i loro dati attraverso un feed, probabilmente avete già accesso a queste funzionalità anche senza saperlo; non sono comunque le sole entità a fornirle e un giro di domande ai vostri fornitori o una ricerca su google al loro riguardo potrebbe valere lo sforzo…

Continua…

Read Full Post »

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…

Read Full Post »