Question About Possible Hack of Site

A couple of other preliminary notes:

My reaction to this has been –

1) Immediately creating a new NameVirtualServer and installing a pristine php code base for WP and all of my plug-ins

2) deleting all users registered in September from my database

3) temporarily disabling xmlrpc.php until I have a full understanding of the entire attack sequence.

4) changing all of my passwords (do not forget that the database user/pass is plain text in the config.php

5) fire walled a few blocks of IP addresses that seemed to correlate to ssh password attacks and this exploit from a timing perspective.

This only took about 5 minutes for a bunch of sites/clients but better safe than sorry. The biggest deal for my sites was regeneration of the cache’s on some of my higher volume sites caused some degree of outage.

I also have reason to believe the attack may register a user prior to the actual exploit but I don’t know why yet and it may just be a red herring.

RB

@rwboyer

I’m seeing the same pattern. Funny thing is, I’m seeing it back on 8/30 from a different IP address, whereas I’m seeing the bad base64 code in today’s log.

-Kevin

Just to get things clear here, removing/renaming or changing file permissions on the file: xmlrpc.php is NOT enough!

The script first makes a simple user (but because of an error in admin.php not easily fixed by wordpress (plugin issues)) the simple user is able to fire wp-admin/options-permalink.php and change the permalink… it does this because it needs the weird eval/base64 thing to actually get the code fired by xmlrpc.php.
To stop the script in its track you only need to either change the name of options-permalink.php or change its permissions… and to be sure do the same thing with xmlrpc.php

I cannot verify but I highly suspect this problem is still in the latest build of this moment.

@marc = agree it looks to be in the newest code.

1. I’ve deleted the hidden admin person and eliminated the bogus text from the Custom Structure permalinks setting. The problem is, I had righteous text in that Custom Structure field before, and I don’t remember what it was.

The closest default structure gives URLs like: https://blog.kirkpetersen.net/2009/09/04/sample-post/

But any hard-coded links to my site, either internal or external, point to URLs like: https://blog.kirkpetersen.net/2009/09/04/sample-post.html. Those links all now bust. Anyone know how to recreate that with genuine Custom Structure code?

2. Another thread on this hacking pointed to a tutorial on how to clean your hacked WordPress installation – https://smackdown.blogsblogsblogs.com/2008/06/24/how-to-completely-clean-your-hacked-wordpress-installation/

That page says to back up your data, download a fresh WP installation and ALL PLUGINS that you use and your template, then completely wipe out all files and folders in your WP directory and reinstall WP and each plug-in (and presumably re-customize the template).

Is all that REALLY necessary?

@marc

You are technically correct but the big damage comes in the xmlrpc.php post. At least from my standpoint of system integrity. In any case disable the options-permalink as well for a lockout. I am keeping one or two of my lower volume sites open and just to see if I can track this fool down.

RB

@kirkpete

Probably not required but you need to be sure of dealing with every single compromised file in your system.

Sometimes depending on where you are at and your current operations it is easier to do that.

I happen to keep an pristine version of everything I run (entire config, plugins, etc) around so I can just deploy it in an instant.

RB

This is why when I design applications I put the code base in a non web accessible folder and the files in the web folder only call the code base. That way fools can’t just run files like the permalink file that is only there to be called by other scripts.

Example:

/public_html/index.php

index.php contains one line:

include_once(“/websafe/load.core.inc.php”);

from that point everything else can be loaded which often includes dozens if not hundreds of files. Of course I often have an admin.php and user base but still no real code sits inside the web folder. I wish WP would have a path command so we could move the files into this kind of setup if we wanted.

@kirkpete

If you have shell access see my thread above as it will allow your system, if *nix based, to search your files to see if they have been compromised with that extra code.

Now I can’t promise other stuff isn’t there but if you don’t have any matches for function gpc_ you are probably okay.

@rwboyer

Thank you for reminding me to change the database password!

@rwboyer
“You are technically correct but the big damage comes in the xmlrpc.php” I agree.

“see if I can track this fool down.”
That’s going to be problem because I already have seen 3 different ip addresses on our site and have seen about 4 different ones posted on the forums here…

The other thing is, there are proof of concepts out there on the internets that also work with the problem where admin.php allows basic registered users to fire php files that only an administrator should be able to do… so I guess we aren’t out of the woods just yet.

@cyberws, thanks… I don’t know what “shell access” means, so I suspect I don’t have it.

@rwboyer, how do I identify compromised files? I looked for function gpc_ in the index.php file, but it’s not there. I looked for recently updated files, the only one I can find is .htaccess. I saw another thread that said I should delete that file… does that make sense?

@cyberws-

I would recommend looking at modification dates and visually examining the files considering I don’t think any of us are absolutely sure exactly what is done on all systems after the XMLRPC.php hack.

I archived my entire compromised directory trees for all effected sites and hope to have an analysis today but that won’t prove a whole lot except verify a trend. Better off looking at all files modified during and after the XMLRPC.php hack signature that I uploaded earlier.

RB

@marc

“tracking fool down”

Sometimes it is good to have a pool of IP addresses used for the attack, even if they are botnets/compromised systems sometimes you can get assistance from the owner of the compromised system to search deeper. Sometimes the fools are dumb enough to use local systems in their office, neighbors, etc.

RB

@rwboyer

Well I agree check mod dates isn’t a bad idea. However a common item here is the default exploit tries to hack files and add a function gpc_ into the files.

The command above will run a quick check to make sure it isn’t any files in the path. I do agree that after a hack no can’t be 100% what else might have been done but as with many hacks there is a basic fingerprint and that function gpc_ is one of them.