Support » Miscellaneous » Exploits in the Wild

Exploits in the Wild

  • I’ve noticed a couple exploits on more than one of my websites. I don’t see them well-documented and I don’t think this forum is a good place to post details, or code that I have extracted.

    I think I can safely say:

    I have noticed two distinct vectors: one seems to involve an attacker creating a new user account on my site, even though this functionality has been administratively disabled. I think this is a “foot in the door” exploit that I don’t well understand.

    The second vector seems to use a maliciously crafted url that tricks the rewrite engine into decoding a base64 string, creating a new function that contacts a remote server. The remote server then exploits WordPress’s access privileges to download new php files that alter how WordPress serves content, and additionally, downloads to the WordPress site a binary file which, presumably, is some kind of payload. I first saw this vector years ago, and have recently seen a more sophisticated version of it that additionally modifies .htaccess to “allow from all.”

    Here is an example of what it looks like when a remote server issues commands to a compromised WordPress installation under this exploit:

    xx.xx.xx.xx – – [28/Mar/2012:09:38:29 -0700] “GET http://www.mysite.com/wp-xrmu.php?f_del_name=master HTTP/1.0″ 404 12715 “-” “-“
    xx.xx.xx.xx – – [28/Mar/2012:09:38:35 -0700] “GET http://www.mysite.com/wp-xrmu.php?f_del_name=slave HTTP/1.0″ 404 12715 “-” “-“

    Could somebody official WordPress please contact me about this?

Viewing 15 replies - 1 through 15 (of 15 total)
  • WPyogi


    Forum Moderator

    There are no “officials” at WordPress.ORG, and support is only offered on these forums. This is recent:




    Forum Moderator

    I’d also suggest that you review FAQ_Security and Hardening_WordPress.

    I don’t think it’s a brute force attack. I’ve noticed both of these exploits on a site that uses a login locker that kicks in after 5 failed access attempts.

    Are they really hitting wp-xrmu.php ?


    There were several additional php files that this attack created, but the server log entries I posted above represent actual commands the attacker issued to a compromised install.

    I also have the maliciously crafted URL that includes the base64 code, but I don’t think it would be appropriate to post that here.

    No, don’t post the base64 please 🙂

    The reason I asked about the file is that it’s not a real WP file. It’s like wp-mai1.php you know? So if they’re aiming at fake WP files, then it drastically alters the vector to ‘already infected installs.’


    Yes, correct, the same WordPress access privileges on my server that allows WordPress to upload content also allowed these hackers to add new PHP files.

    The server log excerpt I posted above lists the response code as 404 because I removed the malicious files and later observed a remote server issue a command to my site. The files did not exist and returned a 404 because I removed them, but I do have the files.

    I might add too that in addition to the .htaccess hacks, index.php was hacked to include the following code:

    [Code moderated. Please do not post hack code blocks in the forums]

    In a way it seems that my site was hacked to ruin its Google rating, by identifying itself as compromised.

    Okay, so lets change this report to “My server was compromised, and the hackers added in fake WP files, which they then called to ruin my Google Rating,”

    Yeah, I work for a Webhost and see that daily 🙂 Not to knock it, but rarely is it WP that’s the vector here. IP logs generally show it’s bad passwords, insecure behavior, or crappy plugins.

    On reviewing the server logs, I should clarify that the exploit appears to be a maliciously crafted http referrer, not url, that contained the base64 string.

    I can decode the string from the referrer and see that it is executable PHP that includes a chmod, so this would seem to be an escalation of privileges attack. I also want to reiterate that there is a binary payload.

    This seems like a really novel delivery mechanism that wouldn’t be necessary if the issue was a bad password.



    Forum Moderator

    Have you reviewed the Security_FAQ?


    Thanks, I’ll look through the Security FAQ in more detail.

    The Security FAQ was not particularly helpful.

    I don’t think the exploit was a weak password.

    When my site was attacked, I was notified that a new user signed up — even through new registrations are disabled.

    I am the only administrator, and if the new account was created from my compromised administrator account, I would not have been notified of a new user. This is evidence that the vector was a WordPress exploit that allows new users to sign up even if new registrations are disabled. I just tested this by creating a new user account with my administrator account, and I did not receive an email notification.

    The Joomla .htaccess file seems to address the specific Base64 technique I observed in WordPress:

    ## Mod_rewrite in use.
    RewriteEngine On
    ## Begin - Rewrite rules to block out some common exploits.
    # If you experience problems on your site block out the operations listed below
    # This attempts to block the most common type of exploit <code>attempts</code> to Joomla!
    # Block out any script trying to base64_encode data within the URL.
    RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
    # Block out any script that includes a <script> tag in URL.
    RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
    # Block out any script trying to set a PHP GLOBALS variable via URL.
    RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
    # Block out any script trying to modify a _REQUEST variable via URL.
    RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
    # Return 403 Forbidden header and show the content of the root homepage
    RewriteRule .* index.php [F]
    ## End - Rewrite rules to block out some common exploits.

    Does a WordPress have a similar mechanism to prevent a maliciously crafted URL from tricking the system into decoding a Base64 string?



    Forum Moderator

    This is evidence that the vector was a WordPress exploit that allows new users to sign up even if new registrations are disabled.

    I’m sorry but that is not evidence of anything. For example, if your database was compromised, the hacker could have simply added the new user directly to the database. There are many ways that a hacker can add a new user once the database or server has been compromised and none are specific WordPress exploits.

    The new user was added as a subscriber, the default role, and WordPress sent my email address a notification of a new registration, which I am not sure would happen if the database was edited directly. I’m also not sure why, if the database was edited directly, the editor would use the lowest-privilege default role.

    And, again, the malicious code was added to my site using a maliciously crafted http referrer, which was a php script encoded in Base64. WordPress was tricked into decoding the Base64 string and executed the php. I have the server log entries that document this, and the live Base64, which I have decoded and inspected.

    Just above, I posted an excerpt from Joomla’s htaccess file, which seems to contain entries that block Base64 code in the URL. Something like this might have prevented my WordPress site from being infected, as this was the delivery mechanism for the malicious code.

    Again: Does WordPress have a similar mechanism to prevent a maliciously crafted URL from tricking the system into decoding a Base64 string?

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Exploits in the Wild’ is closed to new replies.
Skip to toolbar