2.5.1: Looks like there is still a hole

Just to be clear – I didn’t need to update, mine was a recent fresh install of 2.5.1 – and I was still hacked.

I’ve just deleted the xmlrpc.php file, and am hoping for the best.

@pearible –

If you have details on how this was done? If so please send them to [email protected].

If you aren’t sure that this problem got in via XML-RPC then deleting xmlrpc.php may not have addressed the issue.

itsrainingtonight: Plugins are NOT the answer. That is at best a bandaid solution that doesn’t revolve the ongoing issue. Rather than trying to find another way to filter, restrict, and bodge another patch over problematic code, let’s get the code fixed. This sort of injection / breaking / whatever you want to call it has been going on way too long with wordpress, and it needs to get fixed. All the new features in the world are meaningless if blogs are being defaced or turned into spam pages that the search engines will no longer list.

josephscott: The password on that blog has been changed on numerous occasions, and all blog passwords were changed very recently (just about the same time as the 2.5.x upgrade cycle). While I cannot confirm the actual content of the hack POST command, I can assure you that the hack occurs via XMLRPC.

Now, something I did notice: In the 2.5.1 version I downloaded from wordpress, the xmlrpc.php file is dated 3/14/08. It would seem that it wasn’t changed from 2.5.0 to 2.5.1 (although I don’t have a copy of 2.5.0 on my drive here) It is different from 2.3.3 (almost 6k more code) but I am not clear on the differences.

Moderator: If you are going to kill posts, can you kill all the unpleasantness and not just one side? Thanks ??

I think that a reiteration about preventative measures would be great.

Know about any plug-ins that help?
Should I change my password often?

1. There are more than a few plugins that help in this regard — wp-security scan is one that immediately comes to mind.

2. It wont hurt.

what;s the best way to discover if you’ve been hit by this attack?

Now, something I did notice: In the 2.5.1 version I downloaded from wordpress, the xmlrpc.php file is dated 3/14/08. It would seem that it wasn’t changed from 2.5.0 to 2.5.1 (although I don’t have a copy of 2.5.0 on my drive here)

I do, and you are correct, xmlrpc.php did not change between 2.5 and 2.5.1. However, there are still no known hacks via xmlrpc.php.

BUT, if somebody can create a user on your blog through some other method, then they can use the xmlrpc to make a post. This is an easy automated way to do that sort of thing. The problem is not necessarily with xmlrpc, is what I’m saying.

But then here’s the thing: unless you can tell how it was done, it won’t be fixed. Unless the hacker hits one of the several honeypots I know are out there, nobody will have the information to know how he got in. And a lot of the “hacks” I’ve investigated are, to my certain and absolute knowledge, exploits in other, older, backdoors that were left behind from previously hacked versions.

In other words, if you ever got hacked before, and did not completely wipe your site clean and sanitize everything, then that’s probably how they got back in. You can’t simply fix up a hack without checking every line of code in every single file.

Here’s what to do after a hack:
1. Download your WP database using the “Export” method. This doesn’t preserve options and such, so it will likely be clean of any hacks.
2. Make a backup copy of your theme and plugins. Redownload fresh copies of the plugins that you can find, and use those copies instead of the backed up ones.
3. Delete your entire WP directory. Everything.
4. Install a fresh WP and restore your site to it, themes, plugins, everything. This takes time.

Of course, simply keeping backups every so often removes the need for this drastic action, but still, it’s the only way to be sure nothing was left behind. These automated hacking programs are smart, they leave themselves ways in, even after you remove the original one.

@otto42:

In other words, if you ever got hacked before, and did not completely wipe your site clean and sanitize everything, then that’s probably how they got back in.

I keep seeing this, but considering that my site was a brand-new, fresh install of 2.5.1 in every way (new host, new server, etc.) and received the *exact same* hack – I don’t think it’s the issue you’re describing.

BUT, if somebody can create a user on your blog through some other method, then they can use the xmlrpc to make a post.

There were no new users added to my site – the first post was just hacked with:

<span style="overflow: hidden; position: absolute; height: 0pt; width: 0pt;"><a href="https://kvantservice.com/">компютри втора употреба</a></span>

And everything after the “more” tag was gone.

@rawalex –

While I cannot confirm the actual content of the hack POST command, I can assure you that the hack occurs via XMLRPC.

That statement seems to contradict itself. If you don’t know the content of the HTTP POST, then how are you sure that it happened via XML-RPC?

The unwanted content may have been added via XML-RPC, that does not mean that’s how your blog was compromised though. This is the point Otto42 was making.

@pearible –

In order to fix an issue we need have enough information to re-create, other wise we won’t be able to confirm that code changes actually fix the situation. Please send the needed details to [email protected].

otto, everything on the site(s) in question is fine. Files are swept, checked, compared… themes checked for back doors, file CMOD status checked, etc.

As a side note, I don’t use image uploads (it is a sin to have a directory set to 777… ). I have no additional users on these blogs that have permission to do anything (they cannot log in and post, therefore they should not be allowed to do it with XMLRPC either). As with Pearable, the first post on the site was attacked, defaced with a hidden link, and reposted, but only to the more tag. This is a clear indication that they don’t have access and aren’t actually editing the post, but rather using an exploit (because a full edit would re-include the entire text of the message).

At the end of the day, all the preventative measures in the world cannot make up for software with a security hole or exploit – it is always better to have a secure door rather than trying to use digital duct tape to cover over the holes.

I’m a little confused…

First of all, KVANTSERVICE.COM seems like a fairly established (I don’t mean to imply legitimate) business. Their website has been around since 2002 and for the record was designed by ebpw.net who have been around since 1988.

If all of these WP sites are pointing towards that domain wouldn’t the risk of being dropped by Google’s index outweigh the benefit of some extra page views – especially when most of those page views aren’t coming from Bulgaria?

And speaking of Google – can’t we get them to un-index KVANTSERVICE.COM? Isn’t that the ultimate penalty and disinsentive?

Also, thanks everyone for the tips!

And don’t know if this is an issue, but I read somewhere else on the forums recently (and correct me if I’m wrong, but I believe that user Whooami brought it up), even if you have a plugin deactivated, there’s still a risk that a hacker can enter your site via the unused/deactivated plugin. So if you have a bunch of plugins in your plugin folder and they aren’t being used, the best practice is to delete them? One less open (or at least unlocked) door? ??

This is a clear indication that they don’t have access and aren’t actually editing the post, but rather using an exploit (because a full edit would re-include the entire text of the message).

I’m sorry, but that’s simply not a clear indication of anything whatsoever.

Unless you have details about what was done to make that edit, then you simply can not know any such thing as you are claiming.

If you don’t know that it was hacked via a hole in WordPress, then you should not claim that it was. Heck, give me the contents of your wp-config.php file, and I can make your posts say anything at all.

And if you *do* know (because you have details, or logs, or something proving it), then you should not post here at all, and should send those details to [email protected]. Then it will be fixed. In fact, if there is a legitimate hole that is found/fixed, then they’ll do an emergency release and get 2.5.2 out the door immediately.

Otto42: if they were editing the post in the editor (logged on as a user) the rest of the post would not disappear after the MORE tag. However, if they are just doing a page source to get the content of the post (and the post ID number) to blindly blast at it through XMLRPC, then it is very likely that all that would get reposted would be the part before the more tag.

Additionally, I have the POST to XMLRPC logged in the apache logs, but it does not show the passed variables of the post command so there is no way to know.

If I give you the passwords to an FBI system, I am sure you can read some stuff over there too. That isn’t the point. They don’t have the content of the config file (unless wordpress is so unsecure), so what’s the point?

If I had the exact method, the exact passed POST command, I would have long hit security with it. I am posting here because I don’t have it, and want to see if I am the only one seeing it (and I am not). That alone should be enough to get the programmers at least looking. Further, that it has been reported on a brand new fresh from the box 2.5.1 install without plugins, it is pretty clear there is some sort of issue.

jonimueller: For plug ins, it is true if a plug in doesn’t work (or you aren’t using it) you should never leave code on your system. However, it would require first that someone is scanning your blogs for these files, and then applying any hack that might match to them. It would be important for me if I had a ton of plugins, but I don’t. You should never have excess executable code on your system at any time.

itsrainingtonight: Linking to kvantservice may just be a test of sorts, a proof of concept. I saw a couple of blogs on the yahoo list with hundreds of hidden links in their posts, so it isn’t clear that this would be a hack or process limited to any one website. Google won’t act, unless a number of people point out how the links are being obtained… then they might either sandbox / delist them, or just ignore the incoming hidden links.

Otto42: if they were editing the post in the editor (logged on as a user) the rest of the post would not disappear after the MORE tag. However, if they are just doing a page source to get the content of the post (and the post ID number) to blindly blast at it through XMLRPC, then it is very likely that all that would get reposted would be the part before the more tag.

Seems like a pretty thin argument. For one thing, if I personally edit a post through XML-RPC, it does not cut off at the more tag. I use ScribeFire through the XML-RPC door all the time, it works just fine.

Not saying that you’re wrong, just saying that the two things that you’re saying connect… don’t. All that the cut-off at the more tag indicates is that they likely got your post content via your feed.

That alone should be enough to get the programmers at least looking.

Needle in a haystack, friend.

However, it would require first that someone is scanning your blogs for these files, and then applying any hack that might match to them.

Hacks are automated. They don’t “scan” for vulnerable code. They take known attacks, plug them into their attacking engines, and then spam that attack on every site they can find, automatically. If they get a 404, then they don’t care. The program simply moves on to the next one.

You don’t think there’s somebody actually sitting behind a keyboard attacking blogs one at a time, do you?

Additionally, I have the POST to XMLRPC logged in the apache logs, but it does not show the passed variables of the post command so there is no way to know.

a method of capturing those variables was already provided, in fact 2.

I can only speak for myself, but if I were experiencing repeat attacks to my web site(s), I would employ whatever methods it took to locate the entry point