2.8.5 Injection Exploit

[bradyk]

2.8.5 has a security hole that somehow allows files to be uploaded, code to be changed/removed, and generally hijack the site for malware and porn purposes - full details:  http://www.kyle-brady.com/2009/11/07/wordpress-mediatemple-and-an-injection-attack/

I contacted security@…, but have heard nothing and I want to make sure this get handled ASAP.

--Kyle

I have found the same log lately (POST /wp-admin/upload.php) from different sources in many of my wordpress-based sites but as of the moment no security issues like this one has been encountered...
I seriously doubt from the pointed evidence that is a WP issue, seems more like a server security problem itself.
As of the moment seems to be a MediaTemple customers-only issue...

Except that the gateway to all of this is via Wordpress.

The only exception to that is one instance of Drupal (that I've seen), and even then it's not a huge stretch to write one for Wordpress and another for Drupal.

--Kyle

Ok...
But also, there is  another MediaTemple customer, who recently suffer the same kinda of injection but using ExpressionEngine.
Unless is a shared bug across wordpress, drupal and expressionengine... it is starting to really look as MediaTemple security pitfall.

I have seen in the kyle blog that he states that...
"Wordpress, and MediaTemple, seem to agree with me that this is a Wordpress issue"
Can this be confirmed with a dev?
ryan is it really a wordpress issue?

Hi, I recently discovered a vulnerability in WordPress 2.8.5. It allows php code execution in case of an authenticated user. I have already shared this information with the wordpress security team along with temporary patches. I guess this discovery could be relevant. I assume that wordpress team will comment on this soon and release an official patch.

Regards, Dawid

It wouldn't have to be a shared bug... the attack could be modified to exploit various holes in different software with the same end result.

I also feel like if it was a (mt) issue, which I had expressed the possibility of to them at one point, they'd be more interested in finding a solution. I have a hard time believing that it's a server software config issue that allows this - if an attacker knew of a way to get software onto the server, with direct access to Apache, they wouldn't be worrying about Wordpress or other relatively meaningless software.

--Kyle

One of the first things upload.php does is die if the user isn't logged in and doesn't have the right capabilities. Every time I see upload.php being used for ill it is after the attacker has gained access via another means. upload.php isn't the entry. You might still have remnants from an attack against an older version of WP lingering. Check for extra admin users and evals in the permalink_structure option. Exploit Scanner will do these checks for you.

 http://wordpress.org/extend/plugins/exploit-scanner/

bradyk, I replied to your security email a few days ago saying we would add checks for what you discovered to the exploit scanner. Thanks for the detailed post. Until we can track things down further, that's all we can do right now.

2.8.5 could possibly help if you host is configured such that uploaded files with a .php.jpg extension (or .php.gig, .php.png, etc.) are served as php files. Check your upload directories for such files. We'll be adding checks for that to exploit scanner as well.

ryan: I saw that, thanks. I'm trying to work with MediaTemple, because they seem to be appearing as a common factor in all of this.

As a side note, I did run the exploit scanner after cleaning things up (including checking for users) and it didn't produce anything worrisome.

--Kyle

I just got hit, AGAIN, this time using 2.8.6.

Either fix this, or make a definitive decision on whether or not it's your fault.

--Kyle

bradyk: Do you have ANY logs which show what has happened?

I'm strongly thinking this is a server issue, As you've seen, some people with static php files are getting hit as well.

Have you run a local antivirus scan? There was recently a item that went around harvesting ftp credentials from your computer and infecting our remote sites like that..

Until some log files become available showing what is being POST'd to any of the affected files, Its impossible to say if its WordPress's fault or not.

This plugin:  http://www.village-idiot.org/archives/2008/04/16/postlogger-for-wordpress/ logs all POST requests, It might give us some form of explanation of the entry point?

dd32: I don't know why there's such an aversion to my claims by the Wordpress team. I've already explained, in detail, what happened, and said that it uploaded a file to /wp-admin/upload.php without having the permissions (or even a user account) to do so.

What is so hard to understand about that?

I've downloaded all the logs from the last 24 hours before they disappear, but I'll have to go through them later... if it happened before that, I can't "prove" anything to you, because (mt) only gives me 24-hour logs and I'm not exactly sure when this happened.

--Kyle

Kyle: What is the name of the uploaded file? Where did the file end up on your server? What are the rights of the directory the file ended up in?

It's not hard to understand what you are saying the thing is that the checks if a user is logged in is used all over in the admin section. There are two checks before the upload.php really start doing it's job. 1. It checks if the user is logged using a cookie, if the checks fails the user is redirected to the login page. 2. If the user passes the 1st check, the 2nd check is if that user has upload privileges.

if what you say is true, and I'm not saying you are wrong, the attacker has found a way to create a cookie with your or the admin's information.

Like dd32 saidm having the POST in a log would help a lot.

Replying to bradyk:

dd32: I don't know why there's such an aversion to my claims by the Wordpress team. I've already explained, in detail, what happened, and said that it uploaded a file to /wp-admin/upload.php without having the permissions (or even a user account) to do so. What is so hard to understand about that?

The POST to upload.php was almost certainly made with proper permissions. We're saying that is a red herring and that we need log files for what happened before that. Your post, although detailed, is simply showing us the aftermath.

peter: I handled almost all of those answers in my post about what file, to where, etc.

ryan: This has become irrelevant, because (mt) is now taking ownership of it as a server config problem, and they're going to make public statements about it once patches are sent out from whatever software was at fault.

--Kyle