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>