Feeds:
Posts
Comments

Posts Tagged ‘botnet’

Months ago I wrote a serie of articles (Italian only) about why relying on an AntiVirus only is far from being an effective approach to network safety nowadays. Today, I stumbled upon this piece, where Brian Dye, Symantec’s senior Vice President for Information Security apparently says «AntiVirus is dead».

To quote Mark Twain, I think the report of AV death is an exaggeration: nobody should -in my opinion- turn their AV off because it’s not effective anymore. It is certainly true, however, that this approach cannot be the only one in place if you plan to combat malware on your network effectively.

In the fourth part of the series above I already suggested using lists of Command & Control IPs to create nullrouting or firewall entries to inhibit network traffic trying to reach “bad resources”. I also said how one of these lists is available from Spamhaus (as that’s the one I’ve been using) and how they provide this list in the form of a BGP feed you can configure directly in your border router(s).

Whatever the list you chose and however you’re feeding it to your router, you’re going to face a problem: how to monitor what is being nullrouted and what the supposedly infected system is trying to do?

Here is what I did and how you can use a normal linux system to dump and log the blocked traffic and hijack the HTTP sessions (that are by far the most interesting ones) to obtain more intel about the infections.

(more…)

Read Full Post »

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 »

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 »

A Guide to SpyEye C&C Messages.

Read Full Post »

http://krebsonsecurity.com/2011/03/rustock-botnet-flatlined-spam-volumes-plummet/

Read Full Post »

Older Posts »

%d bloggers like this: