Feeds:
Posts
Comments

Archive for the ‘Spam & dintorni’ Category

Oggi vedo arrivare messaggi contenenti presunte fatture di Aruba.it:

 

From: comunicazioni@staff.aruba.it
Subject: Invio copia bollettino

Gentile cliente,

come da lei richiesto in allegato potrà trovare copia del bollettino postale con cui effettuare il pagamento.

Saluti
______________________________

Aruba S.p.A.

Servizio Clienti – Aruba.it

http://www.aruba.it

http://assistenza.aruba.it

Call center: 0575/0505

Fax: 0575/862000

_______________________________

 

In allegato, un file con nome del tipo 123456789_1234567890.pdf.zip

Guardando l’allegato un po’ più da vicino:

skull@mithrandir:~$ unzip 12345678_1234567890.pdf.zip
Archive: 12345678_1234567890.pdf.zip
inflating: 87654321_0987654321.pdf.pif

skull@mithrandir:~$ file 87654321_0987654321.pdf.pif
87654321_0987654321.pdf.pif: MS-DOS executable

Ovviamente, una occhiata agli header conferma che la mail non viene affatto da Aruba:

Return-Path: <xxxxx@hotel.de>
Received: from [80.86.156.104] (unknown [80.86.156.104])
	by mta1.spin.it (Postfix) with ESMTP id xxxxx
	for <xxxxx>; Mon, 21 Jul 2014 13:xx:xx +0200 (CEST)
Received: from [59.22.31.20] (helo=xxxxx.xxxxx.net)
	by  with esmtpa (Exim 4.69)
	(envelope-from )
	id xxxxx
	for xxxxx; Mon, 21 Jul 2014 12:xx:xx +0100
Received: from [109.26.59.81] (helo=xxxxx.xxxxx.su)
	by  with esmtpa (Exim 4.69)
	(envelope-from )
	id xxxxx
	for xxxxx; Mon, 21 Jul 2014 12:xx:xx +0100
Date: Mon, 21 Jul 2014 12:xx:xx +0100
From: comunicazioni@staff.aruba.it
To: <xxxxx>
Subject: Invio copia bollettino


Al momento della ricezione, la lista degli AV che lo riconoscono per quel che è è desolantemente scarna, come di consueto:

 

VirusTotal

 

All’occhio…

Advertisements

Read Full Post »

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 »

I spent a good part of the last few days trying to debug a very weird problem involving postfix and opendkim, so I thought it was a good idea to write the entire experience down for anybody who might be encountering the same (or a similar) problem. This was probably the weirdest misbehaviour I managed to trigger without involving any real bug…

 

On a system I control, I installed opendkim for signing only and configured postfix to interact with it: installation was smooth as usual and everything was deployed in an hour or two. The emails sent by the system are partly anonymized and some headers are therefore stripped before the mail goes out. For this reason, DKIM was configured to sign only some of the headers (and not all of them) or the signatures would fail to validate for remote users.

I sent a few test emails to Gmail and everything seemed to be fine: mail signed, signature header as expected, Google verifying the signature correctly and so on. So I told other users of the same server that the feature was enabled and to poke me in case something was wrong. Immediately one user wrote back saying he wasn’t seeing any signature at all in the emails he was sending.

I checked the logs for his email and found this:

Mar 24 12:22:56 myserver opendkim[32082]: 0CA2F2F1: can’t determine message sender; accepting

The presence of a “From” or “Sender” header within the email is mandatory for DKIM, otherwise the mail can’t be signed; this message was saying that the mail had none and was therefore refusing to sign it.

Easy.

 

(more…)

Read Full Post »

Ogni tanto capita di scrivere qualcosa di lungo in risposta ad una domanda posta in qualche newsgroup/ML/forum/whatever.
Visto che oramai son scritte, tantovale riciclarle qui, dove magari possono essere integrate e corrette nel tempo (e magari popolano anche queste pagine altrimenti scevre di novità)…Inizio con questa, passata su it.comp.os.linuxsys:
On 03/02/14 10:05, Roberto Tagliaferri wrote:

Hola, capita che qualche cliente si becchi uno worm di quelli che invia le
credenziali email per spammare.
Il server ovviamente lo fa inviare (ha login e password corretti) e le
botnet nuove sono abbastanza intelligenti da non inviare troppe email
insieme (per non sovraccaricare il server) e magari le spediscono fuori
orario ufficio (così vengono beccati dopo qualche giorno).
Oltre a decapitare il cliente (è comunque una azione postuma) che si può
fare?
Avevo pensato ad un controllo che bloccasse invii da classi di ip diverse
(chessò, invii da 10 classi ip differenti in 12 ore) ma è un approccio forse
un po’ troppo grossolano (c’è comunque un filtro di fail2ban o un milter
adatto?)
Con postfix che si può fare?
(more…)

Read Full Post »

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

Read Full Post »

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 »

Older Posts »

%d bloggers like this: