Feeds:
Posts
Comments

Posts Tagged ‘crack’

Mailserver hack

Qualche giorno fa Debian ha rilasciato un aggiornamento per exim4 che risolve una serie di vulnerabilità estremamente pericolose.

Come sovente accade in questi casi, risulta evidente che una discreta quantità di amministratori ritiene gli aggiornamenti del sistema operativo una operazione opzionale, poichè in questi giorni è evidente un fiorire di mail di phishing aventi envelope sender come…

debian-exim@sj3d55.svwh.net

debian-exim@front2.imind.hu

debian-exim@mailer4xp.com.br

debian-exim@vps02.davepusey-itservices.co.uk

debian-exim@www.securityfail.com

debian-exim@icedtea.classpath.org

debian-exim@immediamkt.it

…e ovviamente molti altri.

No comment.

Piuttosto: per rimanere in tema con il topic, nelle ultime ore si riporta un massiccio avvistamento di open-relay come non se ne vedevano da tempo. Non si tratta di nuove installazioni, bensì di mailserver operanti da tempo che di punto in bianco hanno iniziato a comportarsi come degli open-relay.

La prima cosa che è venuta alla mente di praticamente tutti è che si trattasse di macchine Exim4 afflitte dalle vulnerabilità succitate e che fossero state compromesse in altro modo rispetto a quello qui sopra: dato che la vulnerabilità consente il remote exploitation a root (!!!), nulla di più facile…

In realtà dal feedback ricevuto dagli amministratori dei sistemi in questione appare trattarsi perlopiù di sistemi MS Exchange 2010…

Resta ancora da capire se si tratti di qualche curiosa interazione tra software (es: AV “agganciato” ad Exchange), di un trojan/worm in grado di riconfigurare il mailserver per farlo divenire open-relay (ma non sarebbe molto chiaro perchè dovrebbero farlo…) o se si tratti di un qualche aggiornamento da parte di MS andato disastrosamente male

Buone feste, eh.. 😛

Read Full Post »

Due piccioni e una fava…

Nelle ultime ore, c’è in circolazione un proliferare di spam che vuol apparire come proveniente da LinkedIn, come quello che riporto qui accanto.

Lo spam esce dalla botnet denominata Cutwail, ben nota alle cronache per essere una delle botnet più grandi in circolazione e al centro di svariate attività (ovviamente tutte illegali) tra le quali alcuni recenti DDoS come quello ai danni di Twitter.

Abbastanza ovviamente, il contenuto dello spam non linka affatto LinkedIn: punta infatti a pagine html depositate su webserver “innocenti”, cui lo spammer ha avuto accesso grazie al fatto di essersi impossessato delle credenziali FTP. Nel caso specifico, il pattern è quello riconducibile allo Zeus Trojan, che ha infettato il PC del proprietario dell’account FTP, ha sniffato le credenziali e le ha solertemente mandate al suo controllore.

Nel caso della mail qui accanto, la pagina linkata è http://altanyilmaz .com.tr/1.html (lo spazio l’ho messo apposta per evitarvi tentazioni).

Se si va a vedere cosa contiene la pagina in questione, si trova:

In sostanza, la pagina fa due cose:

  • esegue una redirezione verso un sito di pilloline (il marchio “Pharmacy Express” riportato dallo stesso è di norma riconducibile alla gang che fa capo a Leo Kuvayev, recentemente incassettato)
  • include un iframe puntante ad un altro sito

A che serve l’iframe?

Facile: cerca di installare lo Zeus Trojan sul PC del visitatore incauto.

Prendono due piccioni con una fava, insomma.

E indovinate dove cercan di mettervi la fava…

Read Full Post »

Come promesso, ho provato a tenere traccia dell’età delle pagine crackate, man mano che i miei script le individuano.

Il “come” è abbastanza banale: dopo aver stabilito che la pagina è abusiva, estraggo via LWP l’header Last-Modified fornito dal server per la pagina in questione e loggo l’età della pagina (dopo una semplice sottrazione).

Ovviamente, c’è il compromesso di affidarsi ad un timestamp fornito dal webserver, senza avere la garanzia che esso sia correttamente configurato riguardo alle impostazioni di data e ora, ma per ricavarne una statistica dovrebbe essere un assunto accettabile.

Il campione finora disponibile consiste nell’età di 1920 pagine crackate individuate approssimativamente nelle 48 ore precedenti a questo post.

La distribuzione risultante la pubblico qui: sull’asse X è riportata l’età in ore della pagina, mentre sull’asse Y c’è il numero di campioni della data età, approssimata a step di 10 minuti. Si noti come risultino anche dei campioni con età negativa, che sono evidentemente un risultato di errate configurazioni come quelle sopra citate, ma che ho scelto di lasciare, anzichè filtrarle.

Appare abbastanza evidente che lo spammer inizia a spammare la nuova risorsa immediatamente dopo averla uploadata sul sito compromesso, anzichè “pescare” da un archivio di URL già precedentemente compromesse…

Il che è anche coerente (ovviamente) con la necessità dello spammer di essere “flessibile” qualora il sito a cui puntano i redirect dovesse venire reso inaccessibile.

Read Full Post »

I più attenti si saranno forse accorti di una variazione significativa nel comportamento di parecchio spam; in particolare di quello legato a Canadian Pharmacy, emesso sostanzialmente tutto da botnet.

Se fino ad alcuni mesi fa, infatti, questo spam linkava il sito dove lo spammer vendeva poi le pilloline, oggi come oggi questo non è più vero nella gran parte dei casi.

Ad essere linkata è invece una qualche pagina “plain-HTML” dal nome composito (tipo ${word}${number}.html), depositata su un sito non inerente le attività di vendita di pillole e anzi sovente del tutto innocuo. La pagina in questione è stata preventivamente uploadata sul sito attraverso una sessione FTP abusiva, disponibile allo spammer grazie al fatto che il client del webmaster è stato infettato da un qualche trojan che solertemente ha prelevato/sniffato/keyloggato le credenziali di accesso allo spazio FTP e le ha comunicate allo spammer.

In tal modo, lo spam inviato non contiene un link diretto ad una risorsa dello spammer che -se già nota- fornirebbe un appiglio ai software di filtraggio.

Di tutto questo ho già parlato in passato.

Attorno al mese di Marzo, piuttosto, ho iniziato a mettere in piedi una infrastruttura pensata per monitorare questi siti crackati, in modo da individuarli e listarli (nella mia infrastruttura di filtraggio) non appena vengono utilizzati dallo spammer per raggiungere uno degli indirizzi monitorati.

Ovviamente, con l’obiettivo di ridurre la finestra tra il momento in cui lo spammer usa una nuova risorsa e il momento in cui i miei sistemi sono in grado di individuare questa risorsa come tale. Il risultato è entrato in funzione attorno al 10 Aprile, e -con qualche aggiustamento in corsa- sta girando in autopilot da allora, risparmiandomi un sacco di lavoro manuale.

Non scenderò in dettaglio riguardo a come questa infrastruttura funzioni, ma ritengo interessante condividere qualche dato prettamente numerico sul fenomeno, che appare avere un trend decisamente crescente.

Qui riporto un grafico che rappresenta il numero di host compromessi individuati giornalmente. Appare piuttosto evidente come il fenomeno sia in effettiva crescita, ma si nota anche come l’uso di queste nuove risorse avvenga sostanzialmente “ad ondate” della durata di qualche giorno.

Vale la pena di confrontare questo andamento con l’uso di link puntanti a crack (siano essi “nuovi” o no) nel corso di un analogo periodo. Purtroppo, per via delle variazioni subite dal mio script prima di raggiungere la completa maturità, posso fornire solamente una analisi relativa agli ultimi 2 mesi circa, prima dei quali i dati sono inconsistenti a causa di una diversa logica interna. Li propongo comunque sulla stessa scala temporale.

E’ possibile notare una certa correlazione, ma è anche evidente come i picchi relativi a nuovi crack non corrispondano ai picchi di emissione di spam linkante pagine crackate.

Qualsiasi cosa ciò significhi 🙂

Quel che in realtà sarebbe più interessante sapere è quanto è “ampio” il bacino di siti già crackati ma non ancora spamvertized. O, meglio ancora, di credenziali compromesse ma non ancora sfruttate.

Forse intercettando e archiviando le date relative all’header Last-Modified potrei ricavare la data in cui la pagina (quand’anche linkata in spam solamente al momento in cui il sistema la rileva) è stata effettivamente creata sul server, ma non ho fatto alcun tentativo in tal senso.

Sarà in caso oggetto di un aggiornamento su queste pagine ma, volendo fare una ipotesi a braccio, non mi aspetto di trovare pagine spamvertized per la prima volta ma depositate sul server da più di un paio di giorni.

Vediamo se mi riesce di smentirmi da solo (di nuovo)… 😛

Read Full Post »

FTP crack

La presente non è certo una novità per chiunque gestisca servizi pubblici in maniera sufficientemente “numerosa”, o per chi si occupi di botnet o altro.

Quindi, questo post è destinato ad un pubblico più o meno “ignaro”. La ragione è che stamattina, sul posto di lavoro, ho ricevuto in gestione i ticket di un paio di clienti, che si sono ritrovati il loro sito (completamente statico) defacciato.

In questo caso, il defacement è ottenuto nella forma di obfuscated javascript “appiccicato” in coda alla pagina originale, che causa la visualizzazione di link a siti di contenuto pornografico.

Un tempo, casi del genere avrebbero significato nel 99.99% dei casi una compromissione dell’intero webserver. Ora, invece, nel 99.99% dei casi sono il risultato di una compromissione dei client.

Questi defacement, infatti, avvengono come conseguenza del fatto che il PC utilizzato per l’accesso FTP allo spazio web è stato trojanizzato.

Diligentemente, il trojan provvede a reperire le credenziali utilizzate (tramite sniffing o tramite keylogging) e a spedirle a chi controlla la botnet di cui fa parte, per utilizzo successivo.

Tale utilizzo successivo consiste nell’instaurare una connessione FTP con tali credenziali (a partire, ovviamente, da un altro BOT e non certo dall’IP del botmaster) ed utilizzarla per uploadare contenuti malevoli di vario genere: target di spam, phishing, malware. Spesso lo stesso trojan utilizzato per appropriarsi delle credenziali è stato prelevato dal client per questa stessa via (un sito web bucato) e il cerchio si chiude.

Qualche tempo fa, Spamhaus ha pubblicato un articolo riguardo a questo meccanismo, che invito a leggere.

Con un unico appunto: da quell’articolo parrebbe di evincere che la soluzione al problema sia l’utilizzo di SFTP o di altri protocolli che consentano l’encryption delle credenziali di autenticazione.

La mia tesi è che anche quell’approccio, benchè certamente utile, sia lungi dall’essere una soluzione: la crittografia della comunicazione è pensata per garantire la confidenzialità delle informazioni scambiate tra due entità, ma non è in grado in alcun modo di garantirla qualora la compromissione riguardi una delle due entità che stanno scambiando traffico.

In altre parole, l’approccio crittografico può evitare che le password vengano sniffate, ma non può in alcun modo opporsi al fatto che esse vengano prelevate tramite keylogging.

La soluzione, quindi? Solo una, IMHO: tenete sicuro il vostro client e se usate un client Win32, accertatevi di usare un account con privilegi di amministratore il meno possibile.

Read Full Post »

%d bloggers like this: