06 Oct

Wordfence Doesn’t Want You to Know We Discovered the Vulnerability in Postman SMTP

We have seen a lot sleazy stuff out of the WordPress focused security company Wordfence, including claiming that they care more about security than the WordPress team as justification for creating a fake threat, so it shouldn’t be surprising to find their post about the removal of the plugin Postman SMTP from the Plugin Directory, which people assume is due to a reflected cross-site scripting (XSS) vulnerability we discovered, doesn’t mention us or link to our post despite being about the only substantive thing mentioned in their post. They clearly are aware of who the source was as the second paragraph clearly references our post:

On June 29, an unnamed security researcher published the details of the vulnerability, including a proof of concept. A proof of concept is a demonstration that shows the plugin author (and in this case the entire internet, including potential attackers) how to exploit the security vulnerability. The security researcher had apparently attempted to reach the author but had been unable to.

It is worth noting that here that this type of vulnerability is highly unlikely to be exploited on the average website (contrary to a recent claim by Wordfence that this type of  vulnerability “will be exploited by attackers“) and the proof of concept included just reiterates what is already mentioned in detailing the vulnerability, so someone that would be exploiting this type of vulnerability shouldn’t have a problem without it. Someone looking to do a targeted attack against a website using this plugin, likely could have easily found this vulnerability on their own (and who knows, they might already have).

One of the reasons we include a proof of concept on how to exploit vulnerabilities is so that others can double check our work, as among other things we often find that vulnerabilities that are being disclosed and claimed to be fixed, haven’t actually been. If there is a proof of concept it is easier to catch that vulnerability hasn’t been fixed and then we can work with the developer to get it fixed (and usually in that situation it can be fixed very fast). It also helps to check if there are other related vulnerabilities that have been missed, as has been the case with Wordfence’s discovered vulnerabilities in the past (or more recently them missing that vulnerable code still was in a plugin, though not accessible). There also was the situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it.

It is also important to note that all major web browsers other than Firefox have XSS filtering to protect against this type of vulnerability for years, which is likely plays an important role in it not being likely to be exploited.

When we have discussed things that Wordfence has written we have properly credited them.

Advertising Over Improving Security

We wouldn’t mind them not mentioning us if they had finally decided to actually help the effort to get WordPress to properly handle removed plugins, since that is so important. Instead their post is mostly just an ad for their plugin and service, which both leave people not knowing why plugins are removed.

Wordfence clearly understands there is an issue with people not knowing why plugins are removed as the first paragraph of their posts states:

We have received a number of questions regarding the Postman SMTP plugin which was removed from the WordPress.org directory this week.

We assume it was removed because it contains a publicly known reflected cross-site scripting (XSS) vulnerability that has not been fixed.

And later they write:

Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

They didn’t write anything about doing anything to resolve that situation, which is easily resolvable if WordPress wanted to take action, but here is all the advertising they had time to include in the post instead:

Both Wordfence Free and Premium users who have the firewall enabled have been protected against attempts to exploit this vulnerability from day one. In addition, we alerted all Wordfence users who have the plugin installed when it was removed from the plugin directory.

It should be noted they didn’t provide any evidence that their plugin actually can protect against this type of vulnerability (or for that matter do they provide evidence that it does for other types and our testing hasn’t shown it to provide much protection). As we mentioned before the major web browsers other than Firefox provide protection against this type of vulnerability as well, something Wordfence didn’t note.

Wordfence Firewall Includes Robust XSS Protection

The Wordfence firewall includes protection against new and emerging XSS attacks. Both Wordfence free and Premium users have been protected against this attack since (and before) it was made public. This is a great example of why using a firewall to protect your website is so important: you are immediately protected against most new threats.

In cases where we don’t already protect against a new threat, we develop a new firewall rule, deploying it to our Premium customers in real-time and free customers 30 days later. This ‘virtual patching’ by our security analysts and developers keeps your sites safe.

Wordfence Alerts You When Plugins Are Removed From WordPress.org

When plugins you have installed on your site are removed from WordPress.org, Wordfence alerts you. There is a long list of reasons why the plugin team at WordPress.org might remove a plugin from the directory. One common reason is that someone has discovered a security vulnerability that has not yet been fixed. Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

 

If you haven’t already, we suggest that you install Wordfence on all of your WordPress websites. It will alert you when your plugins have been abandoned or removed from the the WordPress directory. Its firewall will also protect you against new and emerging attacks.

Finally, consider upgrading to Wordfence Premium if you haven’t already. The real-time firewall rule updates will protect you from the latest threats. In addition, the real-time IP blacklist will stop all attacks from the most malicious IPs, regardless of what they’re up to.

Our Advertising

Since Wordfence is going to use a vulnerability we discovered to advertise their service so garishly, we will quickly plug our service, which would have not only warned you about the vulnerability in you were using the plugin back when it was disclosed in June, but we would have also have been available to help you make the best decision as to deal with.

The more customers we have the more we are able to improve the security of WordPress plugins for everyone using them. While this vulnerability has gone unfixed, this week we help get vulnerabilities fixed in plugins with 140,200+ active installs and we have contacted developers of plugins with another 500,000+ active installs about vulnerabilities in them that need to be fixed.

Fixing the Vulnerability

As we said before the vulnerability isn’t something that is a big concern, so it wouldn’t be a big risk to keep using the plugin in its current form, but fixing the vulnerability is easy.

On line 346 of the file /Postman/Postman-Email-Log/PostmanEmailLogController.php in the plugin replace this line:

346
value="<?php echo $_REQUEST['page'] ?>" />

with

346
value="<?php echo esc_attr($_REQUEST['page']) ?>" />

The esc_attr() added will escaping the value, which prevents the possibility of reflected cross-site scripting (XSS).

04 Oct

Ninja Forms Could Have Avoided Recommending and Using a Vulnerable Plugin If They Used Our Service

Back in June we disclosed a minor vulnerability in the plugin Postman SMTP that we had discovered. We were not able to contact the developer of the plugin and it hasn’t gotten fixed since we disclosed it. In the past we would have notified the Plugin Directory of the issue and the plugin would have been removed, but due to WordPress’ continued poor handling of security related matters we have suspended reporting publicly disclosed vulnerabilities in the current version of plugins until they take concrete steps to start notifying people when they are using removed plugins and improve their forum moderation (which causes problems for people trying to get vulnerabilities fixed).

Whether due to this vulnerability or something else the plugin was removed from the Plugin Directory yesterday. In looking to see if there was any information that indicated there might be some other issue with the plugin we noticed this recent tweet:

So the makers of a very popular contact, Ninja Forms, which has 900,000+ active installs, were recommending using a plugin with a known security vulnerability. It seemed possible that this wasn’t a new recommendation, just a new tweet for something they had written some time ago. But in looking at the linked post, it turned it was from September 27. It also turned out they were not just recommending the plugin, but also using it:

Postman SMTP is one of the two services that we recommend highly and use internally (the other being Mailgun). We’ll spend the next few minutes introducing them to you and covering the (very easy) setup process. Let’s look at making email easy again! 🙂

If Ninja Forms had been using our service they would have been notified back in June that they were using a plugin with a known vulnerability. We then could have helped them work out how best to handle the situation, including providing them a fix until the developer resolved the issue in a new version or they moved to another plugin. They then also could have avoided recommending something with a known vulnerability.

For those aware that there are other data sources available through plugins/services and thinking Ninja Form could have used them, think again. We just checked and found that the WPScan Vulnerability Database and ThreatPress, both of which we mentioned recently, don’t have the vulnerability in their data sets, even though it was publicly disclosed over three months ago.

The Ninja Form post also makes a claim that seems inaccurate, as one of the “three big reasons” given to use it is:

Actively supported

The plugin had not been updated in two years as of its removal yesterday and was only listed as being compatible with up to WordPress 4.4.

For those using a plugin that has been abandoned that they want to keep securely using them, we now offer a service for taking over and maintaining them, which includes us doing a security review like the ones we do for plugins suggested/voted for by the customers of our service.

29 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in Postman SMTP

We recently found the the plugin Postman SMTP contains a reflected cross-site scripting (XSS) vulnerability.

On line 346 of the file /Postman/Postman-Email-Log/PostmanEmailLogController.php the value of GET or POST input “page” is output without being escaped:

value="<?php echo $_REQUEST['page'] ?>" />

While the GET input “page” needs to be set to “postman_email_log” for that code to run, the POST input can be set to another value and depending on the configuration of PHP will be the one chosen to be output.

The website of the developer is down and we couldn’t find any other method to contact them directly. The plugin was last updated 16 months ago and is only listed as being compatible up to WordPress 4.4, so it doesn’t look like it is being maintained at this time.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box. 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/tools.php?page=postman_email_log" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>