Hack? install.php re-run

  • Hello,

    We had a client report that his blog had been compromised. All his posts were gone (just the default post was there as if it was a fresh install) and the title of his blog changed, along with email address. This was a newer blog (within the last couple of weeks) and is running WordPress 2.8.4.

    When I looked through the log files, I saw these entries, the only ones I found that were odd:

    212.95.58.87 – – [30/Sep/2009:12:50:51 -0400] “GET /blog/wp-admin/install.php HTTP/1.1” 200 2064 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”

    174.142.104.57 – – [30/Sep/2009:12:50:55 -0400] “POST /blog/wp-admin/install.php?step=2 HTTP/1.1” 200 1198 “https://www.clients-domains.com/blog/google-updated-and-sandbox/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”

    The accesses are just 4 seconds apart, different IPs (so, has the signs of a savvy hacker). The GET to /blog/wp-admin/install.php as of right now returns that the blog is already installed.

    But, that POST is the more curious one. It appears to be a direct POST to the install.php?step=2.

    Is it possible that they were successful in creating a POST that simulated the installation process? That submitted the Blog Title, Email address, and whether you wanted it to work in search engines? And then proceeded to re-install all the tables?

    That is my best guess on this, and I am not technical enough to be able to try simulating this POST. So, I don’t know if this is even possible. But, I couldn’t find anything else in the log files of any odd accesses to the /wp-admin/ area or anything along those lines.

    Thanks for any ideas on this

    David

Viewing 3 replies - 1 through 3 (of 3 total)

  • POST and GET refer to the request type..

    GET requests look like this..
    index.php?name=value

    Looks like the above request was for your install page (which in itself is harmless, no exploit attempted there). An exploit attempt would have various other bits strung onto the end..

    POST requests are values submitted by a form.

    The person attempting to create or use an exploit was obviously trying some form of remote POST request, it’s quite common. You create a basic form on your own space, have the form submit to the vunerable address.

    What concerns me (and it may be unwarranted) is that the request returned a 200 Status code.. which is basically saying “Ok”… when i believe (and i could be wrong here) it should be returning a 404 or forbidden response…

    Thread Starter host4profit

    (@host4profit)

    Hello,

    Yes, t31os_, that is my bigger concern. The POST to the install.php file. As far as I can see, the WordPress documentation doesn’t state to remove the install.php file, but it certainly makes sense to do it.

    But I am trying to confirm this is how the attacker corrupted this blog, but somehow managing to POST back to the install and make it look like it was a fresh install, in turn, wiping everything out.

    David

    I imagine you could near enough totally kill the exploit with some fancy mod_rewrite rules, but that’s a little beyond my scope of skills unfortunately, else i’d offer you something to do the job.

    I’d start by running a few test installations and capturing some information when the install procedure runs, then use that information to build some tight mod_rewrite rules that catch any invalid requests to the installer..

    In theory here, but in my mind i’m quite certain with a bit of time and effort it could be done.

    You could even create a sandbox trap, a dummy install that allows hackers to mess with it, then run a modified install.php in that installation and have it log all the requests made to it, that way you catch all or at least some of the data being used to exploit said installation.

    Just thinking out loud here. Thinking and doing are two entirely different things of course.

    My point being, without knowing specifically what’s been done to exploit the installer it’s hard to create any kind of fix for the problem.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Hack? install.php re-run’ is closed to new replies.