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.

22 Feb

SiteGround Caused 300,000+ of Their Customers Websites to be Insecure Due to Their Plugin SG Optimizer

When it comes to blame for the poor state of web security one of the parties that should get more blame than they seem to get are web hosts. Not only do they often poorly handle security themselves, but increasingly they have been partnering with really bad security companies, allowing those security companies to cause even more problems. SiteGround is one of those web hosts, with their partnership with Sucuri (which in turns is owned by another web host, GoDaddy, with a horrible security record of their own). Sucuri is a  company that among too many issues to go through, tries to scare people in to hiring them to do unneeded work, lacks a basic understanding of security, and causes their customers websites to remain insecure when they were easily fixed by people not claiming to have the level expertise that Sucuri claims to have.

Considering that SiteGround would have so low regard for their customers to partner with Sucuri, it probably isn’t all that surprising that they have also caused 300,000+ of their customers’ websites (according to wordpress.org) that use their plugin SG Optimizer, to be insecure due to really poor security handling in the plugin.

What stands out about this is how long it took them to fix this. What lead us to look into their plugin and find vulnerabilities in it was SiteGround’s claim about quickly providing protection against a vulnerability in another plugin. In that case they touted how they had provided protection the same day a vulnerability was disclosed. That vulnerability was already fixed several days before the disclosure and was unlikely to have been exploited, so the claimed provided protection wasn’t all that meaningful. When it came to unfixed vulnerabilities in their own plugin though it took them nearly three weeks to fix it, when it could have reasonably done in days at the most.

What we found when we started to look at their plugin three weeks ago was that there was a lack of protection against cross-site request forgery (CSRF) when taking actions permitted by the plugin, due to a lack of a nonce sent with the request to take those (and also a lack of check to make sure a valid nonce was sent when processing the request). That could allow an attacker to cause a logged in Administrator to take actions provided through the plugin, without intending it. The plugin allows changing the website’s caching settings, HTTPS enablement, and what is seems like the most likely to cause issues, it’s PHP version.

When we went to look closer at that we found there was a larger issue related to that, anyone logged in to WordPress would be able to change all those things as well. As an example of that, let’s look at the code that handles changing the URLs that get excluded from caching. That is handled through a function named update_blacklist(), which the plugins register to be available through WordPress’ AJAX functionality:

79
add_action( 'wp_ajax_sg-cachepress-blacklist-update', array( $this, 'update_blacklist' ) );

The way that is registered allows anyone logged in to access the function. The function, located in the file /class-sg-cachepress-admin.php, didn’t do a check to make sure the requests is from a user that should have access to it (or check for a valid nonce to prevent CSRF) before updating the excluded URLS:

260
261
262
public function update_blacklist() {
	die((int)$this->options_handler->update_option('blacklist',$_POST['blacklist']));
}

That has now been fixed adding by adding those checks:

375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
public function update_blacklist() {
	if (!current_user_can( 'manage_options' )) {
		return;
	}
 
	if (!isset($_POST['nonce'])) {
		return;
	}
 
	if (!wp_verify_nonce( $_POST['nonce'], 'sg-cachepress-blacklist-update' )) {
		return;
	}
 
	die((int)$this->options_handler->update_option('blacklist',$_POST['blacklist']));
}

After that we ran the plugin through our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own),  and it identified another possible issue in one of those AJAX functions:

A quick test of that showed that in fact the plugin contained a reflected cross-site scripting (XSS) vulnerability since it outputs user input without escaping it first.

That was fixed by restricting access to the relevant function and escaping the input using strip_tags():

62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
function message_hide()
{
	if (!current_user_can( 'manage_options' )) {
		die();
	}
 
	if (!isset($_POST['nonce'])) {
		die();
	}
 
	if (!wp_verify_nonce($_POST['nonce'], 'ajax-notification-nonce')) {
		die();
	}
 
	$id = $_POST['notice_id'];
	$this->options_handler->disable_option('show_notice_' . $id);
 
	echo strip_tags($id);
	wp_die();
}

It really doesn’t say good things about the security of WordPress plugins in general that you have a plugin with 300,000+ active installs that has a vulnerability that can be picked up by our tool (and its good reason to check the plugins you use over and possibly have a security review any flagged as possibly containing security issues).

The good news in all of this is that none of those security issues is the kind of thing that hackers would likely try to exploit.

Proof of Concept for Changing Excluded URLs

The following proof of concept will cause the value of the excluded URLS to be changed to “test”, when logged in to WordPress

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="sg-cachepress-blacklist-update" />
<input type="hidden" name="blacklist" value='test' />
<input type="submit" value="Submit" />
</form>
</body>

Proof of Concept for Reflected Cross-Site Scripting (XSS) Vulnerability

The following proof of concept will cause an alert box with the message “XSS” to be shown, 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" method="POST">
<input type="hidden" name="action" value="sg-cachepress-message-hide" />
<input type="hidden" name="notice_id" value='<script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • February 2, 2018 – Developer notified.
  • February 5, 2018 – Developer responds.
  • February 22, 2018 – Version 4.0 released, which fixes vulnerabilities.
21 Feb

When The Solution to a Vulnerability in a WordPress Plugin is to Have Updated It Years Ago

Earlier today we were discussing an example of the problem with WordPress plugins not being kept up to date. Recently we have also been looking in to another example of that, which also shows the type of work we do to make sure our clients have the best data on vulnerabilities in WordPress plugins and also some of what developers have to deal with when it comes to claims of them in their plugins.

One of things we do to keep track of vulnerabilities in WordPress plugins is to monitor the Support Forum on wordpress.org for topics related to those. Recently we came across a thread for the plugin Spider FAQ that indicated there might be a vulnerability in it:

Today OpenBugBounty wrote us a mail, that we have a css vulnerability problem with the searchfield from Spider-Faq.

One resolution is, to filter some Signs in the Searchfield. Can anyone tell me, where the Searchfield is located and where we should enter the Filter for the Symbols?

That sounded like it was describing a reflected cross-site scripting (XSS) vulnerability in the plugin’s search functionality on the frontend of the website. When we went to check on that though we found that things seemed relatively secure. What seemed to be the relevant code escapes what is submitted to be searched for (in the form of POST input search) to prevent XSS:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

It looks like it would be better to be using esc_attr() instead of esc_html(), but other than things seemed fine.

At that point we were not sure what was going on and we waited to see if any more information would be disclosed in the thread that might make things clearer (due to the terrible moderation of the Support Forum, we avoid participating in it at this time).

After a response from the developer, the original poster responded with additional information. What was helpful to us in that was that they listed the address where this was occurring. With that we tried to see what version of the plugin was being used on the website, since it could have been that a vulnerability had existed in older versions of the plugin.

We were quickly able to identify that the version of the plugin being used on the website was from the 1.0.x series. That series was indeed vulnerable to this issue, as there is no escaping when the search term is output:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

Version 1.1, which fixed that, was released on November 19 of 2013. So the plugin hasn’t been updated in over four years on that website.

Proof of Concept

Submitting the following proof of concept as the search term on a frontend page for the plugin will cause an alert box with the number 1 to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

“><script>alert(1);</script>