10 Aug

Our Plugin Security Checker Identified Another Reflected XSS Vulnerability in WordPress Plugin with 100,000+ Active Installs

In a reminder of the rather poor state of security of WordPress plugins and how our Plugin Security Checker tool (which is accessible through a WordPress plugin of its own) can help you to get a better idea if they are in need of additional security scrutiny recently the plugin Ultimate Member, which has 100,000+ active installs according to wordpress.org, was run through the tool and it identified a possible reflected cross-site scripting (XSS) vulnerability in the plugin.

Looking at the details of the issue identified, which are available to users of our service through the tool’s Developer Mode, it certainly looked like there was that type of vulnerability as user input was being output without being escaped:

A quick check confirmed that this was an exploitable vulnerability (though far from a serious issue for the average website), as can be seen with the proof of concept below.

The vulnerability has been in the plugin since April without anyone noticing it, despite the fact that an automated tool was able to spot it. While the vulnerability isn’t a serious issue, it is due to a failure to do a security basic and shouldn’t be something that should be in a plugin developed by an “experienced plugin developer” and has generated over a million dollars worth of revenue. Maybe, not all that surprisingly the plugin also contained a much more serious vulnerability that was being widely exploited before being belated fixed by the developer in same release that fixed this one.

A “Reputable” Plugin Isn’t a Secure Plugin

There is no shortage of advice when it comes to the security of WordPress websites, though much of it is quite bad. That is unfortunately true of so much coming from security companies that people incorrectly trust not just to get accurate information but also to provide them security. We often find that suggestions are made on how to choose plugins that are secure where there is no supporting evidence being provided for the suggestions and that those with even a cursory understanding of the security issues surrounding WordPress plugins would likely find questionable at best.

This plugin is a good example of where a plugin that would meet many common suggestions is at the same time contains an easily spottable vulnerability. Here for example, were suggestions made by Wordfence last November:

Choose Reputable Plugins

The WordPress.org plugin directory makes it really easy to evaluate plugins by providing a nice summary that gives you almost everything you need. Here’s what we suggest you pay attention to:

  • The more recent the last update, the better.
  • Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers, but you should still examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.
  • It should be compatible with the current version of WordPress, though please note that immediately after a WordPress core release, a lot of reputable plugins will show a “Test up to:” value that is behind, as authors finish testing their plugin with the latest WordPress version.
  • The average plugin rating should be high enough to instill confidence. The higher the rating, the better, obviously.

You should also periodically review your installed plugins to make sure they have maintained their good standing.

This plugin meet all of those at the time we looked in to the issue:

A plugin being recently updated, popular, maintained, and highly rated doesn’t mean in any way it is secure. While this vulnerability was fixed after a month we have found that security vulnerabilities in other popular and recently updated plugins are not always fixed in a timely or ever.

Proof of Concept

The following proof of concept will cause an alert box with the message “XSS” to be shown when logged in WordPress as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

http://[path to WordPress]/wp-admin/admin.php?page=um_options&tab=email&section=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3Eylo

Timeline

  • July 12, 2018 – Developer notified.
  • July 13, 2018 – Developer responds.
  • August 9, 2018 – Version 2.0.22 released, which fixes vulnerability.
02 Jul

When A Security Vulnerability Is Only One of the Issues With a WordPress Security Plugin

We don’t think too highly of the security industry and we are often reminded of why that is, as was the case when we did a quick check of the plugin Sitesassure WP Malware Scanner. We had run across the plugin on the website of a company, 911websiterepair.com, which offers to clean up hacked websites, where it was listed as their plugin. The plugin didn’t mention anything about that website instead it was connected to another website and the look of that website didn’t exactly give us a good feeling about the potential quality of the plugin:

We then did a quick check of the plugin. What we found was poor security and a minor security vulnerability in the plugin. We will get to those in a moment, but first we want to bring up a couple of questionable items.

In looking over the code one thing that we quickly noticed was that there was a significant amount of code in the plugin for accessing a scanner from a company named Quttera. Oddly, nowhere in the description of the plugin or in the plugin is there any mention of that company. As far as we can tell that is actually who is doing the scanning. Considering that Quttera provides their own plugin (which we also recently found contained a vulnerability) it looks like Sitesassure’s plugin mainly serves as advertisement for them and to collect information on people using it, rather than providing a capability that isn’t available elsewhere.

As to the data collection, when you take various actions not only does the plugin connect to the Sitesassure website but it also sends out an email to someone. That seems like it might be a violation of one of the developer guidelines for WordPress plugins, but what seems odder is that the current email address doesn’t have an obvious connection with the plugin. As an example of that is the code run when the plugin is deactivated:

function swms_sitesassureDeactivate()
{
	$site_domain = get_bloginfo('url');
	$req_url = SWMS_REQUEST_URL;
	$response = wp_remote_post( $req_url, array(
	'method' => 'POST',
	'timeout' => 45,
	'redirection' => 5,
	'httpversion' => '1.0',
	'blocking' =>; true,
	'headers' => array(),
	'body' => array("action" => SWMS_UPDATE_REQUEST, 'domain' => $site_domain, "status" => SWMS_INACTIVE_STATUS),
	'cookies' => array()
    )
	);
	if ( is_wp_error( $response ) ) {
	   $error_message = $response->get_error_message();
	   _e("Something went wrong: $error_message","swms");
	} else {
	   if($response['response']['code'] == 200 && $response['response']['message'] == "OK")
	   {
	   		$message = 'Hi SA Admin,
'.$site_domain.' is deactivated the WPSASCANNER plugin';
	   		swms_sendEmail(array('to' => 'nagaraj@spinzsoft.com','subject' => $site_domain.' Deactivated Message','message' => $message));
 
	}
}

That code first sends a request to the Sitesassure website and if that request is successful an email is sent to nagaraj@spinzsoft.com. The website at spinzsoft.com doesn’t seem to be connected to the Sitesassure website. Up until June 13, when version 2.0 of the plugin was released, emails were instead sent to support@sitesassure.com. Prior to release of 2.0, the last update made to the plugin was in December of 2015.

One common area of security issues in plugins is functionality accessed through WordPress’ AJAX functionality. Often due to allowing those not logged in to WordPress to access functionality only intended for those logged in or due to allowing low level users access to functionality they are not intended to have access to. In the case of this plugin both of those issues occur.

In one of the functions that is accessible to anyone logged in WordPress despite only being intended to be accessed by Administrators there was a security issue not related to allowing lower level users to access it. Instead the issue was that user input is output without being sanitized or escaped, which could allow reflected cross-site scripting (XSS) to occur. That occurred in the function swms_get_admin_url(), which is located in the file /sitesassure-wp-malware-scanner.php:

494
495
496
497
498
499
function swms_get_admin_url(){
	$swms_scanned_url = $_POST['data'];
	$swms_admin_url = admin_url("admin.php?page=swms_scanner_report_page&swms_url=$swms_scanned_url");
	echo $swms_admin_url;
	exit;
}

Two days after we notified the developer of the issue a change was to fix it, but the version number was not changed, so no one already using version 2.0 will be prompted to update. We had also notified of the developer of the more general lack of security in the plugin, lack of restriction on who can access AJAX accessible functions and lack of protection against cross-site request forgery (CSRF), but no changes have been made related to those yet. We have yet to receive any response from the developer.

The vulnerability was fixed by passing the user input through the esc_url() function:

494
495
496
497
498
499
500
function swms_get_admin_url(){
	$swms_scanned_url = $_POST['data'];
	$swms_scanned_url = esc_url($swms_scanned_url);
	$swms_admin_url = admin_url("admin.php?page=swms_scanner_report_page&swms_url=$swms_scanned_url");
	echo $swms_admin_url;
	exit;
}

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in to WordPress. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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?action=swms_get_admin_url" method="POST">
<input type="hidden" name="data" value="<script>alert(document.cookie);</script>" />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • June 25, 2018 – Developer notified.
  • June 27, 2018 – Change made to version 2.0 to fix vulnerability.
04 Jun

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Form Maker

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

We often find that the various things that we do come to together to help improve each other and that ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

21 May

Our Plugin Security Checker Found a Reflected XSS Vulnerability in WordPress Plugin with 100,000+ Active Installs

In a reminder of the rather poor state of security of WordPress plugins and how our Plugin Security Checker tool (which is accessible through a WordPress plugin of its own) can help you to get a better idea if they are in need of additional security scrutiny when we ran the plugin WP Google Map Plugin through the tool to check to see if it would have spotted a recently fixed reflected cross-site scripting (XSS) vulnerability in the plugin we found that the plugin still contained another vulnerability of the same type (it also would have identified the possibility of the previous vulnerability if it had been checked).

In the file /core/class.initiate-core.php the function fc_geocoding() outputs the value of the variable $_POST, which contains any POST inputs sent with a request, without escaping that:

32
33
34
35
function fc_geocoding() {
	print_r($_POST);
	exit;
}

That would lead to a reflected cross-site (XSS) vulnerability depending on if and how it can be accessed. The function is registered to be accessible through WordPress’ AJAX functionality to anyone logged in to WordPress:

23
add_action( 'wp_ajax_fc_geocoding',array( $this, 'fc_geocoding' ) );

So it would be exploitable, though that isn’t a type of vulnerability that hackers are likely to exploit on the average website and therefore there isn’t a lot of risk due to it.

We notified the developer of the issue a week ago. We haven’t heard back from them (other than an automated response that they received our form submission) and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in to WordPress. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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?action=fc_geocoding" method="POST">
<input type="hidden" name="test" value="<script>alert(document.cookie);</script>" />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • May 14, 2018 – Developer notified.
21 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Open Graph for Facebook, Google+ and Twitter Card Tags

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

The changelog entry for version 2.2.41 of the plugin Open Graph for Facebook, Google+ and Twitter Card Tags is ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

21 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Custom css-js-php

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

A week and a half ago we detailed a reflected cross-site scripting (XSS) vulnerability that had been fixed in ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

18 May

When Will WordPress Finally Understand That Burying Heads in The Sand Doesn’t Improve Security?

When it comes to improving the security of WordPress plugins what continues to amaze us is the extent that people that should be part of the solution are instead part of the problem. We got a reminder of that not too long ago with a question on the wordpress.org Support Forum about a possible security issue in the plugin WP Booking.

On February 5 someone created a new topic in the support forum for the plugin with the following message:

Hi,

i found this vulnerability info –> https://php-grinder.com/vulns/view/6726087

Is this a relevant problem for me (plugin user)?
–> Vulnerability: #6726087 (2017-11-24 16:01:31)

Best Regards
Frank

That led to this response from one of the forum moderators:

@fraver I’ve archived your topic. Do not disclose vulnerabilities that way here. Please contact the plugins team with the details via plugins@wordpress.org.

There are a number of problems with that.

First, that person wasn’t disclosing a vulnerability, they were linking to another web page. If what they linked to had actually been a disclosure of a vulnerability, then it would have already been disclosed. We would say that the moderator doesn’t understand the basics of how the Internet works, but it turns out that position isn’t only theirs. In the current version of the page on reporting vulnerabilities in plugins it states that:

Even if there’s a report filed on one of the official security tracking sites, bringing more awareness to the security issue tends to increase people being hacked, and rarely speeds up the fixing.

That is downright bizarre. We are not sure what “official security tracking sites” is supposed to refer to, official in what capacity? Assuming they are referring to something like CVE, hackers can easily search for vulnerabilities there. The idea that mentioning something from one of those on the Support Forum is going to have much negative impact is something that we highly doubt somebody could provide any evidence to back up.

A further problem in this situation is that suggestion from the moderator contradicts another of the reporting instructions, as it states:

It greatly helps if you can provide us with how you verified this is an exploit (links to the plugin listing on sites like secunia.com are perfect).

If the moderator had followed the link they would have seen this message:

The person asking about that pretty clearly didn’t have any idea if there was actually a vulnerability, so if they reported this to the Plugin Directory then nothing would likely to be done. For several weeks after that, nothing happened.

What removing the message does is to limit the ability for those more knowledgeable to check on the claim. We only had access to those posts because we have an email alert set that picked them up (a hacker could do the same thing, making the deletion all the more questionable). Due to the fact that we able to see them, we were able to look further into this and confirm that there was a vulnerability.

The original claim indicates that the function get() in the file /wp-booking-management-system/shinetheme/libraries/input.php returns the value of user input without it being sanitized. Depending on where that is then is used it could lead various vulnerabilities. We did a quick look at the plugin to see if we could find an example of it leading to a vulnerability and found that in the file /shinetheme/views/admin/taxonomy/edit.php it was output without being escaped, which could leading to reflected cross-site scripting (XSS) on line 100:

<input type="search" name="keyword" value="<?php echo WPBooking_Input::get('keyword') ?>" placeholder="<?php echo esc_html__('ID','wpbooking') ?>">

We notified the developer of all of this on February 14th and then on February 27th they released version 1.5, which fixes the vulnerability. That was done by escaping the value using esc_attr():

<input type="search" name="keyword" value="<?php echo esc_attr(WPBooking_Input::get('keyword')) ?>" placeholder="<?php echo esc_html__('ID','wpbooking') ?>">

The same escaping was added to another instance of usage of that function in a different file.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

http://[path to WordPress]/wp-admin/admin.php?page=wpbooking_page_orders&wpbooking_apply_changes=Apply&order_service_type&status&payment_method&keyword="><script>alert(document.cookie)%3B<%2Fscript>

Timeline

  • February 14, 2018 – Developer notified.
  • February 27, 2018 – Version 1.5 released, which fixes vulnerability.
17 May

Reflected Cross-Site Scripting (XSS) Vulnerability in CF7 Invisible reCAPTCHA

In the monitoring we do to keep track of vulnerabilities in WordPress plugins for this service one thing we have noticed is that developers are not always providing full or consistent information on new version of plugins. For version 1.3.1 of the plugin CF7 Invisible reCAPTCHA the changelog entry is “Minor bug fix: Resolved the caching issue.”. The development log entry for that version indicates something different, “Security Update in Cf7 Invisible reCAPTCHA”. In looking over the new version to see if there was a vulnerability being fixed in that version what we saw was there was a significant amount of changes that were made, which seems out of line with the changelog entry description of the change being made.

Due to the amount of changes it makes it a bit hard to figure out if there was a vulnerability fixed and we didn’t find something in our look over it. But we did see a reflected cross-site scripting (XSS) vulnerability that was introduced in that version.

At the beginning of the function that generates the plugin’s admin page, vsz_cf7_invisible_recaptcha_page(), which is located in the file /cf7-Invisible-recaptcha.php, the new version added code to set the value of the GET input “tab” to the variable $tab without sanitizing or validating it:

54
55
function vsz_cf7_invisible_recaptcha_page(){
	$tab = isset($_GET["tab"]) ? $_GET["tab"] : "settings";

Further into the function the value is output without being escaped, which would permit reflected cross-site scripting (XSS) to occur:

277
jQuery("#<?php echo $tab; ?>").show();

We have yet to hear back from the developer since we notified them of the issue, but yesterday they released version 1.3.2, which fixes the vulnerability by sanitizing the input when setting it to the value of $tab:

55
$tab = isset($_GET["tab"]) ? sanitize_text_field($_GET["tab"]) : "settings";

And escaping it when being output:

277
jQuery("#<?php echo esc_attr($tab); ?>").show();

After running across this vulnerability we updated our Plugin Security Checker (which is now accessible through a WordPress plugin of its own) to detect vulnerabilities using code similar to this one.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

http://[path to WordPress]/wp-admin/admin.php?page=cf7-Invisible-recaptcha&tab=</script><script>alert(document.cookie);</script>

Timeline

  • May 14, 2018 – Developer notified.
  • May 16, 2018 – Version 1.3.2 released, which fixes vulnerability.
10 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP Google Map Plugin

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

In discussing Wordfence lying about the quality of the data they provide on if a new version of a ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

09 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in PixelYourSite

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

The changelog for version 5.3.0 of the plugin PixelYourSite is “Fixing potential security issue”. In looking at the changes ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.