I ricercatori di sicurezza Internet hanno annunciato una ripresa nella diffusione di Malware del genere
Gumblar, che nel mese di maggio, a infettato migliaia di siti Web.
Questa volta pero'
ci sarebbero importanti novita' sulla tattica adottata per diffondere il malware tra cui, la piu' importante, l'uso di siti Web compromessi per hostare gli exploit.
Chi gestisce la diffusione in rete di malware sa che e' solo una questione di tempo prima che un
dominio "maligno" venga messo
offline ma la nuova tattica, tuttavia, consente di disporre di vettori di attacco decentrati e ridondanti,
sparsi in migliaia di siti legittimi di tutto il mondo.Ecco quindi un post tratto da
http://blog.unmaskparasites.com/ che mi pare interessante non solo per la notizia in se' del ritorno online di Gumblar ma perche' analizza in dettaglio,
modalita' di diffusione e contromisure da attuare per ridurre il pericolo di questa nuova minaccia malware.
==================================================================
Revenge of Gumblar ZombiesVi ricordate di
Gumblar?, il massiccio attacco hacker che e' riuscito a infettare piu' di un
centinaio di migliaia di siti web legittimi in un tempo molto breve questo mese di maggio?L'infezione e' stata relativamente facile da individuare ma
molto difficile da eliminare completamente. Infetta vari tipi di file e
crea gli script backdoor in luoghi poco appariscenti del sito web in modo che i cybercriminali potrebbero facilmente ripristinare il contenuto dannoso.
Il Sito
gumblar(dot)cn (e il suo immediato successore
martuz(dot)cn) erano stati prontamente
messi OFFline.Come risultato,
lo script dannoso iniettato nei siti compromessi e' diventato innocuo per i visitatori.Tuttavia, molti webmaster
non hanno adeguatamente ripulito i loro siti dopo l'infezione Gumblar, lasciando intatti gli script di backdoor.
Era stato previsto che chi gestisce questa distribuzione malware avrebbe trovato il modo di utilizzare
questo esercito di siti web potenzialmente controllabili ed ora, cinque mesi piu' tardi, vediamo
una nuova ondata di un massiccio attacco che somiglia a Gumblar per molti aspetti.*
Credenziali FTP rubate vengono utilizzate per iniettare contenuti dannosi in file esistenti.
*
Script dannosi vengono iniettati sia nel codice HTML delle pagine web che in files js stand-alone.
*
Script Backdoor sono caricati in directory di immagini. Essi hanno gli stessi nomi
"gifimg.php" e "image.php"e il resto del codice PHP e' quasi identico , a quello durante l'attacco Gumblar.Tuttavia, questo nuovo attacco,
ha molte caratteristiche che lo rendono piu' resistente.Injected Malicious Scripts (caratteristiche degli script dannosi iniettati)Al posto del famigerato
script offuscato, questa volta
viene iniettato un tag che carica uno script esterno.Questo script e' meno sospetto della presenza dello script offuscato lungo ed illeggibile utilizzato da Gumblar.Lo stesso script viene iniettato dopo la parte di codici JavaScript (. Js) presenti nella pagina.Un webmaster solitamente ricerca il codice dannoso in HTML mentre puo' dimenticare i files.js in quanto il loro contenuto non e' visibile quando si utilizza la funzionalita' "Visualizza sorgente pagina".Su alcuni siti, ho notato che che agisce per diffondere Gumblar, gli hacker volutamente
caricano script infetti dai nomi popolari (builder.js, effects.js, lightbox.js, Prototype.js, scriptaculous.js)Alcuni webmaster non conoscono l'architettura dei loro siti 'abbastanza bene per individuare gli script infetti caricati,
soprattutto quando questi hanno nomi di script benigni.Un gruppo di host "maligni"Su diversi siti compromessi un tag script carica il contenuto dannoso da host differenti. Al momento ho una lista
di piu' di 60 URL di diversi server in tutto il mondo.
Inoltre, i cybercriminali
aggiornano regolarmente il codice iniettato e il tag script sullo stesso sito puo' contenere diversi indirizzi di host sources in giorni diversi. Questo rende piu' difficile l'individuazione, se qualcuno tenta di eseguire la scansione dei file per specifiche URL malevoli.
Un altro effetto interessante che richiama l'attenzione degli specialisti di sicurezza e quello di utilizzare
piu' server "maligni" ed ogni nuova URL puo' essere considerata come un caso indipendente (tra l'altro, ogni nuovo indirizzo propone files exploit leggermente diversi).
Nel caso di Gumblar, ogni sito compromesso puntava a
gumblar(dot)Cn, sito che era il solo indicato dagli Antivirus.
Le societa' di sicurezza hanno impressionanti statistiche per i siti infettati con lo script Gumblar
(da 60.000 a 200.000 siti).
Si parlava solo di
Gumblar e la stampa ha parlato Gumblar. Come risultato di questa enorme pubblicita'
il dominio gumblar(dot)cn era stato rapidamente messo OFFline (lo stesso e' successo a martuz. CN), cosa che di fatto ha interrotto l'attacco.
Una singola fonte di contenuti dannosi era l'anello piu' debole di Gumblar, il suo unico punto di fallimento.
Ora che diversi siti compromessi puntano
a vari indirizzi dannosi, non esiste un consistente flusso di informazioni circa l'attacco. La statistica di infezione per ogni URL non e' impressionante.
Ogni indirizzo ad host maligno puo' riguardare un numero relativamente ristretto di siti (100 - 2.000) e questo non basta per parlare di una epidemia. Questo aiuta i cybercriminali rimanere in ombra anche nella fase attiva di attacco e significa anche che le societa' di sicurezza
passano meno tempo a combattere la minaccia. Tuttavia, l'effetto complessivo di questo tipo di attacco
puo' essere paragonabile a Gumblar. A questo punto ho rilevato oltre
5.000 siti unici compromessi e non credo che la mia lista sia completa.
D'altra parte, tutti parlano di indirizzi diversi ed e' difficile trovare un denominatore comune e vedere l'intero quadro della situazione. Cercando di risolvere lo stesso problema, webmaster di diversi siti sono alla ricerca di informazioni sulle diverse URL pericolose e di conseguenza, non riescono a trovare una sola fonte di informazione. Cio' rende piu' difficile per i webmaster trovare le informazioni pertinenti e pulire in modo efficace i loro siti. Come risultato l'infezione col passare del tempo aumenta.
Cerchero' di raccogliere tutte le informazioni su questo tipo di attacco con tutti gli URL maligni conosciuti, in modo che i webmaster dei siti interessati possano verificare gli indirizzi, indipendentemente dallo script trovato sui loro siti.
(segue elenco siti compromessi)Questo elenco non e' completo. Cerchero' di aggiornarlo quando trovo nuove URL pericolose.
A questo punto, il tratto distintivo di queste URL e che
esse fanno tutte riferimento a uno script PHP in una sotto-directory di un sito di terze parti e se trovi uno script esterno con un indirizzo ad uno degli indirizzi web di cui sopra, assicurati di leggere il resto di questo post.
Siti WEB Zombie.Gli script maligni risiedono su siti legittimi compromessi.
Questa e' probabilmente la caratteristica piu' innovativa di questo attacco. Non si puo' semplicemente chiudere i siti o i nomi a dominio
poiche' appartengono a legittimi siti.Naturalmente, i siti possono essere sulla lista nera (per esempio di Google), ma a questo punto meno del 20% di essi sono elencati come sospetti (soprattutto a causa di altri problemi piu' vecchi).
Non ho mai visto sfruttare direttamente siti compromessi per piazzarci i files exploit.
I siti legittimi sono stati utilizzati per reindirizzare i visitatori , in maniera silenziosa, su siti che appartenevano ai cybercriminali.
Qualche volta sono
state create pagine spammy su siti legittimi (es. per SEO con lo scopo di avere link non blacklistati per le loro e-mail di spam.) ma non mi ricordo siti compromessi che venivano sfruttati per proporre files exploit.
La ragione principale
e' che probabilmente questo tipo di attivita' puo' essere facilmente individuata dai proprietari dei siti compromessi: aumentato utilizzo della banda utilizzata, ecc .....
Uno script iniettato in iframes e' piu' conveniente per chi compromette i siti dal momento che non lascia alcuna traccia nei registri e non influenza l'utilizzo della larghezza di banda.
Allora perche' utilizzare siti compromessi ora? Non hanno forse paura di essere smascherati? Credo, di no ed ecco perche':Dopo l'attacco Gumblar monitorando siti infetti da qualche mese ho notato che
molti proprietari del sito non hanno neanche tentato di rimuovere il contenuto dannoso.
Alcuni dei siti potrebbero
essere stati abbandonati (ma i loro nomi di dominio e hosting sono prepagati e possono esistere in uno stato incustodito per qualche tempo), altri siti sono
semplicemente mal gestiti da webmaster ignoranti che non hanno la minima idea su minacce alla sicurezza. Ora
chi gestisce Gumblar ha un gruppo di siti che puo' usare senza il rischio di essere smascherato rapidamente dai proprietari del sito.Allo stesso tempo,
il loro nuovo modello distribuito (uso di fonti multiple di contenuti dannosi)
riduce significativamente l'utilizzo di risorse di ogni singolo sito. Anche siti presenti in hosting condiviso sono in grado di gestire il carico.
E non importa se alcuni dei loro siti zombie vengono chiusi - hanno molti zombie a loro disposizione.
Con la loro botnet di client-zombie, possono aggiornare rapidamente i codici maligni sui siti compromessi per fare riferimento ad un nuovo host.Molto comodo, non e' vero? I cybercriminali non devono piu' preoccuparsi di server abuse-proof e della loro larghezza di banda.
Non c'e' bisogno di registrare centinaia di nomi di dominio che diventano ben presto una lista nera. Hanno a disposizione siti usa e getta, quindi perche' non farlo gratuitamente a spese del webmaster che non si cura del proprio sito?MalwareIl codice maligno sui siti zombie viene generato al volo. Ogni volta che si ricarica la pagina PHP si ottiene una copia differente del JavaScript offuscato. Cio' puo' impedire l'individuazione dello script dagli strumenti di AV che si basano esclusivamente sulle firme digitali.
Il codice maligno
dipende dalla versione del browser web e sistemi operativi. Si ottiene un codice diverso per IE6, IE7, Firefox (non ho provato altri browser). E se siete su Linux otterete semplicemente il codice 404 –not foud error. In questo modo gli hacker
cercano di sfruttare le vulnerabilita' conosciute dei computer visitatori '.
Ad esempio, in tutte le versioni dello script che tenta di caricare
un file PDF "maligno", se rileva che "PDF.PdfCtrl" o "AcroPDF.PDF" (Adobe Reader o Adobe Acrobat) e' installata la versione del prodotto piu' vecchia della 9,0, ma non della 8.1.3 (versione corrente e' la 9.2.0)
Un altro exploit universale e' un file di Flash per il "ShockwaveFlash.ShockwaveFlash.9" (Shockwave Flash) plugin se la sua versione e' piu vecchia della 9,124 (versione corrente e' la 10.0.32.18)
Come si puo' vedere, il malware ha come
obiettivo vulnerabilita' piuttosto vecchie, corrette circa un anno fa. Mi chiedo, quanti navigatori del web non si siano preoccupati di aggiornare i plugin? Sembra che siano in molti.Ogni sito zombie serve binari leggermente modificati. Una settimana fa i files facilmente passavano il controllo di VirusTotal inosservati. Oggi ho controllato ed il PDF e' stato individuato come "maligno" da 5 dei 41 strumenti AV e il file SWF e' stato rilevato da 4 dei 41 strumenti di AV.
In caso di IE7, gli hacker cercano anche di sfruttare le vulnerabilita' in "OWC10.Spreadsheet" / "OWC11.Spreadsheet" plugins. It's Office Web Components. In altre parole, MS Excel che lavora all'interno di Internet Explorer.
Per IE6, provano un VBScript che scrive semplicemente un trojan. Exe nella cartella Esecuzione automatica del menu Programmi di Windows. (
State ancora usando IE6 ?)Non solo gli hacker hanno come bersaglio diversi browser, ma anche come target diversi paesi. Su ogni
server zombie ho trovato un file binario (1 ottobre 2009) MaxMinds GeoLite, database di geolocalizzazione degli IP
Backdoor scriptLe Backdoor script sono quasi identiche a quelle utilizzate durante la fase dell'attacco Gumblar.Script con il nome "image.php" e "gifimg.php" si possono trovare nelle directory dei siti compromessi....................
Uno degli script esegue il codice PHP che gli hacker passano attraverso una richiesta HTTP POST.Vengono usate le richieste POST, perche' a differenza di richieste GET, non lasciano alcuna informazione sui parametri passati nei log del server web. Quindi non e' possibile rilevare eventuali attivita' sospette quando si guarda attraverso i log del server..............
Pagine di erroreSu alcuni server
404 (pagina non trovata) e 403 (proibito) le pagine di errore sono state infettate con i tag script dannosi.
Furto di credenziali FTPCome Gumblar,
questo tipo di attacco ruba le credenziali FTP. Questa circostanza e' stata confermata dai servizi di sicurezza dei provider di web hosting che hanno ispezionato i registri FTP.
In maggio, il comportamento Gumblar e' stato testato su un computer Windows intenzionalmente infettato. Il test ha dimostrato che il malware ruba le password salvate nei programmi FTP (FileZilla in questo caso).
E 'stato anche notato che Gumblar (in questo nuovo attacco) infetta i siti che sono stati precedentemente infettati con iframe maligni nascosti. L'attacco ruba le credenziali FTP dal file di configurazione
di 10 piu' popolari client FTP. Il ................
RilevamentoWarning: Il caricamento siti web in un browser Web con JavaScript abilitato puo' essere pericoloso.
E 'una buona idea usare qualcosa come
NoScript che permette solo l'esecuzione dello script di domini trusted. In questo modo, se si vede un avvertimento che alcuni script sono stati bloccati sul tuo sito, si puo' essere certi che qualcosa non va e si dovrebbe eseguire la scansione dei file sul server per gli script sospetti.
E' inoltre possibile Unmask Parasites. . Tuttavia, poiche' la maggior parte dei siti zombie non sono ancora in lista nera da parte di Google, non vedrete avvertimenti. Tuttavia, gli script dannosi saranno elencati nella sezione riferimenti esterni e si dovrebbe essere in grado di individuare i nomi di dominio sconosciuto.
Per individuare questa infezione, effettua la scansione di ogni file sul server per i tag script che fanno riferimento
a strani script PHP che puntano a sottodirectory di siti sconosciuti di terze parti. Si trovano di solito a destra prima del tag . Come webmaster dovresti sapere che script appartengono al tuo sito e quali no.
Assicurati di controllare tutti. File js.Quindi cerca script backdoor con la scansione dell'intero albero di directory per i file con i nomi "gifimg.php" e "image.php". Essi si trovano di solito in directory denominate "immagini" .Quindi cerca i files che contengono eval "(base64_decode (...))" codice di solito e' usato per nascondere codice maligno.Non dimenticare di controllare le pagine di errore personalizzate.Istruzioni per la rimozione1. Iniziare dal proprio computer (questo soprattutto per gli utenti Windows).Eseguire la scansione di virus e spyware. L'uso di almeno due diversi AV e strumenti anti-spyware. (In maggio, Malwarebytes e' stato segnalato per essere in grado di rilevare il malware)
2. Una volta che il computer e' pulito, assicurarsi che il software sia aggiornato (questo passo aiuta a prevenire la reinfezione del tuo PC):Windows Update (Microsoft Questa ottobre ha rilasciato correzioni per la protezione di molte vulnerabilita' critiche)
Utilizzare un browser recente (suggerisco Firefox 3.5 con l'estensione NoScript). Se si utilizza Internet Explorer 6 - aggiornamento ASAP!
3. Aggiornamento di Flash e Adobe Reader - questo tipo di attacco usa le vulnerabilita' nelle versioni precedenti (A partire dal 23 ottobre 2009 le versioni attuali di questi plugin dovrebbe essere: Flash: 10.0.32.18; Adobe Acrobat / Reader: 9.2.0)
4. Cambiare tutte le password del sito. Non salvate nuove password nel vostro FTP client, se non volete che siano rubate di nuovo. Considerare l'utilizzo di protocolli sicuri (FTPS o SFTP) invece di FTP.
5. Bonifica del sito. Questo attacco hacker modifica un sacco di file e crea script backdoor in luoghi poco appariscente quindi sarebbe molto difficile da rimuovere manualmente i contenuti dannosi da ogni file infetto. E se non si riesce a rimuovere anche uno script di backdoor, il rischio di reinfezione sara' elevato.Il modo piu' semplice e' quello di eliminare tutti i file sul vostro sito e caricare una copia pulita da un backup (assicurarsi che il backup non e' infetto). Non dimenticate i files di configurazione e le pagine di errore personalizzate.
Non dimenticare di controllare regolarmente il sito per problemi di sicurezza.================================================================Questo un riassunto dei contenuti apparsi su unmaskparasites a cui rimando per la lettura del post originale ( in lingua inglese ).Edgar