WordPress › Support » Question About Possible Hack of Site

cyberws
Member
Posted 2 years ago #

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.
rwboyer
Member
Posted 2 years ago #

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
netnothing
Member
Posted 2 years ago #

@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
marc_dutch123
Member
Posted 2 years ago #

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.
rwboyer
Member
Posted 2 years ago #

@marc = agree it looks to be in the newest code.
kirkpete
Member
Posted 2 years ago #

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: http://blog.kirkpetersen.net/2009/09/04/sample-post/

But any hard-coded links to my site, either internal or external, point to URLs like: http://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 - http://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?
rwboyer
Member
Posted 2 years ago #

@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
rwboyer
Member
Posted 2 years ago #

@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
cyberws
Member
Posted 2 years ago #

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.
cyberws
Member
Posted 2 years ago #

@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.
dyske
Member
Posted 2 years ago #

@rwboyer

Thank you for reminding me to change the database password!
marc_dutch123
Member
Posted 2 years ago #

@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.
kirkpete
Member
Posted 2 years ago #

@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?
rwboyer
Member
Posted 2 years ago #

@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
rwboyer
Member
Posted 2 years ago #

@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
cyberws
Member
Posted 2 years ago #

@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.
rwboyer
Member
Posted 2 years ago #

For instance I can tell you that 72.167.131.221 looks like it is running an apache server. Not real common on hacked windoze systems
rwboyer
Member
Posted 2 years ago #

@cyberws

I guess my previous life causes me to be extra extra careful - I look at finding the signature as just a validation the system was compromised rather than the ONLY compromise.

RB
cyberws
Member
Posted 2 years ago #

@rwboyer

Well I agree a multiprone approach is a good idea. However if you go back three days in backups you might have function_gpc somewhere in them too. Afterall who knows many advances this hack has gone through.

Bottom line is do several things. That is what I am doing.
rwboyer
Member
Posted 2 years ago #

@cyberws

Violent agreement - hence why I keep a pristine code base laying around for deployment. The only thing I took from my active backups are my database and my image files. Everything else in that VirtualServer tree is history. Even checked my database for entries made over the last couple of days, users that shouldn't be there etc.

RB
kirkpete
Member
Posted 2 years ago #

@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?
dyske
Member
Posted 2 years ago #

I would not delete .htaccess
rwboyer
Member
Posted 2 years ago #

@kirk

what system are you running wordpress on?

can you look at your webserver access logs?

can you do any kind of advanced file search based on change dates or content?

RB
Joseph Scott
Member
Posted 2 years ago #

If you have specific details on the steps to reproduce this please email security@wordpress.org.

I have been trying to reproduce the problem on a test WP 2.7.1 install (since someone specifically mentioned that version) and so far have not been able to reproduce the problem.

The HTTP POST request with the base64 encoded data to xmlrpc.php might be part of the problem, but so far I haven't seen any information to indicate (nor have I been able to reproduce) that the attack originated with that request. It could be a step in the hack after they've already broken in via other means.
marc_dutch123
Member
Posted 2 years ago #

@josephscott
Information has been made available to wordpress already this year by CoreLabs around june/july.
kirkpete
Member
Posted 2 years ago #

@rwboyer,

My host is called 1&1. I don't know what kind of system they use -- how would I be able to tell?

I stumbled on a Logs subdirectory, which has two files dated today -- http://ftp.log and access.log.36.5

Other than .htaccess, I have not found any files dated today. Two days ago I posted successfully and I find a .jpg file associated with that with the proper date, but I can't find any system-looking files that are any more recent than June, the last time I reinstalled.

I'm not aware of any way to do file searches for change dates - I'm using Windows Explorer to look at the directory. I've tried painstakingly opening every subdirectory to check file dates, but there are dozens and dozens of nested subdirectories, I get lost.
cyberws
Member
Posted 2 years ago #

@josephscott

I sent you my logs so you can see if you can infect a copy of your own.
Joseph Scott
Member
Posted 2 years ago #

@marc_dutch123
If it is one of those already known hacks then it isn't a hole in xmlrpc.php.
Andrea_r
team pirate
Posted 2 years ago #

"I wish WP would have a path command so we could move the files into this kind of setup if we wanted. "

Actually it does. Look in the wp-config files, plenty of declarations there for changing the default dirs.
dyske
Member
Posted 2 years ago #

I have access to my logs but it's huge, like 800MB. How does one go about looking at such a huge log file? That is, what sort of program/utility can I use to see the data from yesterday (which is when my site was hacked).