3 Mar 2020

Bad Practices by Fortinet and the WPScan Vulnerability Database Lead to False Claim of Vulnerability Being Fixed in WordPress Plugin

Years ago we recommended data from the WPScan Vulnerability Database as good alternative to our service, since while their data was of lower quality, it was available for free. Now more and more access is being charged for, while the quality of the data has gotten worse since we used to recommend it. Here is a recent example of that, which also shows bad practices from Fortinet made it hard to figure when they screwed up in disclosing a vulnerability.

Here is the current version of the entry from WPScan of a vulnerability in Testimonials:

You can see they are claiming that the vulnerability has been fixed, but they haven’t verified things, so how do they know that?

Fortinet doesn’t provide enough information even to be sure what they are referring to as this is currently the totality of the information they provide on the claimed issue:

A stored XSS vulnerability exists in the version of the plugin 2.1.6. Successful exploitation of this vulnerability would allow an authenticated low-privileged user to inject arbitrary javascript code into the plugin gallery image which is viewed by other users.

 

Users should update the plugin to the latest version (2.1.7).

When we went to try to confirm this we found no mention in the changelog of version 2.1.7 of a security fix:

  • New: Settings page added.
  • New: Custom CSS option.
  • New: Schema markup enable/disable option.
  • Fix: Schema markup issue on Google search console.
  • Improved: Client name HTML tag.

That doesn’t mean there wasn’t one, since developer don’t always mention them.

Looking at the changes made in that version we didn’t see anything that looks like it could have been a security fix that match the claim made or even a change that seemed related to a “plugin gallery image”.

In looking over the plugin we also didn’t find anything that involved “plugin gallery image”.

What might explain that description is that it matches one used for another recent report by Fortinet of a vulnerability in a photo gallery plugin:

A stored XSS vulnerability exists in the version of the plugin 1.7.6. Successful exploitation of this vulnerability would allow an authenticated low-privileged user to inject arbitrary javascript code into the plugin gallery image which is viewed by other users.

If that explains that, what explains the rest of this? Presumably there is a vulnerability, but was it fixed or not?

Further checking showed that a vulnerability, which other than the “plugin gallery image” part, matches their description still exists in the plugin right now. If Fortinet had provided more information that would have been easier to catch.

If the rest of the information Fortinet provided is accurate, the team running the Plugin Directory might also be implicated here:

Fortinet reported the vulnerability to WordPress Plugin Team on  January 28, 2020

Authenticated Persistent Cross-Site Scripting (XSS)

WordPress users down to the Contributor level are allowed to create new testimonials through the plugin’s admin Add Testimonial page. On that page the user can fill “Name” and “Identity or Position” fields. As the proof of concept below confirms the values entered in those are neither sanitized when saved or escaped when output, so malicious JavaScript can be saved and output, which is an authenticated persistent cross-site scripting (XSS) vulnerability.

WordPress Causes Full Disclosure

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for 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, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information, can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

When log in as a Contributor enter the following value as the Name field of a new testimonial and save it:

"><script>alert(document.cookie);</script>

When visiting the plugin’s Testimonials admin page and other pages, any available cookies will be shown in an alert box.


Concerned About The Security of the Plugins You Use?

When you are a paying customer of our service, you can suggest/vote for the WordPress plugins you use to receive a security review from us. You can start using the service for free when you sign up now. We also offer security reviews of WordPress plugins as a separate service.

Leave a Reply

Your email address will not be published.