16 May

dxw Overstating Risk of Vulnerabilities in WordPress Plugins

When it comes to improving the security of websites among the many problems is that the public doesn’t have a good understanding of how much risk various security issues pose. That leads to among other things, people believing that websites must have been hacked due to software on a website that contained a known vulnerability despite no evidence to support that and it being very unlikely that the vulnerability would be exploited, much less that it could have lead to the website being hacked. Unfortunately we often find those involved in security are the ones overstating the risk posed by vulnerabilities.

On Monday we detailed a vulnerability that had been fixed in the plugin Metronet Tag Manager, where the changelog entry for the version it was fixed in was “Fixed serious security issue. Please Update.” A possible explanation why it was labeled as such despite not being anywhere near a “serious” issue came yesterday, as on Tuesday the finder of the vulnerability, dxw, released a report on the vulnerability with the title “CSRF in Metronet Tag Manager allows anybody to do almost anything an admin can”. The third sentence of the description seems to explain that claim:

As this vulnerability allows adding arbitrary JavaScript, the attacker can use it to control an admin user’s browser to do almost anything an admin user can do.

That all makes it sounds like it would be likely to be used to hack websites, but in reality there is about zero chance that the vulnerability would be exploited average website at this time. The chances of exploitation of that type of vulnerability could change at some point and it could be of more interest in a targeted attack, but it isn’t something of major concern for the average website at this time. The reason for that isn’t all that complicated and it also explains why that title is so misleading.

With a cross-site request forgery (CSRF) vulnerability an attacker could cause someone else to take an action they didn’t intend to take. In this case, for the vulnerability to be exploited, an attacker would need to get someone logged in as Administrator user on a WordPress installation to access a page the attacker controls. That is something that we don’t see hackers trying to do against the average website whether with this type of vulnerability or others that rely on that same type of action. Nowhere in their report did dxw mention the need to be logged in at all to exploit this, much less as an Administrator to have been able to exploit this, despite that clearly being a requirement.

What makes dxw claim more problematic to us is that to us saying anybody can do something would imply that anyone could take the action, whereas you would need to get one of a limited amount of people to take an action. This isn’t one time claim, for example with another recent CSRF vulnerability they titled their report “CSRF in WP User Groups allows anybody to modify user groups and types”.

Details Matter

In looking at another of their recent discovered vulnerabilities to add it to our data set we found another overstated claim. The title for a report on that vulnerability is “WP ULike allows anybody to delete any row in any WordPress table”. One of the claims made in it is:

The plugin contains a wp_ajax action which allows any authenticated user (it doesn’t check permissions) to delete any row of almost any table in the database (the table must begin with $wpdb->prefix).

Another is this (emphasis ours):

In a real attack, the form could be made to auto-submit on page load, and submit the form multiple times with different table and id values meaning that a single user falling for a phish could wipe the whole database.

The line of code that handles the deletion referred to in those statements is this:

$wpdb->delete( $wpdb->prefix.$table ,array( 'id' => $id ));

The critical part of that is “array( ‘id’ => $id )” as that defines what gets deleted from the table. That will delete a row from table where the “id” columns value is the value specified by $id, which comes from user input. If a table doesn’t contain an “id” column then nothing can be deleted. While two important WordPress tables, posts and users, have an “ID” column, which unless case sensitivity is in place their entries can be deleted, the others do not, so this could not be used to “wipe the whole database”.

dxw is at least aware of the column limitation as the last steps of their proof of concept states:

The value of id or table can be changed allowing deleting any row in any table with the WordPress prefix at the start of its name, and having an id column

So either they didn’t fully checks things over before making a sensational claim or they knew better and included that claim anyway.

10 May

How Free Data Sources for WordPress Plugin Vulnerabilities Compare To Us with Possibly Targeted Vulnerable Plugin

One of the reasons why security is in such bad shape despite the enormous amount of money spent on it is that there is a failed market when it comes to security products and services. In simple terms it isn’t currently possible for consumers to make well informed decisions between different products and services due to rampant falsehoods and outright lies about them as well as a lack of watchdogs to limit those or independent entities that provides accurate information needed to be able to make informed decisions. What sticks out to us is how widespread these falsehoods and outright lies are. We often see them in just the somewhat obscure area we deal in, data on vulnerabilities in WordPress plugins.

Just last week we discussed how the makers of the very popular WordPress security plugin, Wordfence Security, were lying by claiming that the data source they use is “official” and only contains “confirmed/validated” vulnerabilities. In reality neither of those claims is true, there is no official source of WordPress plugin vulnerability data and their data source doesn’t actually confirm or validate vulnerabilities before including them. What they didn’t mention nor are we aware of them disclosing elsewhere is what the data source used is, which is the WPScan Vulnerability Database. They are hardly alone in using that source and they are certainly not alone in not being upfront about using that data source, which is its own problem because we have seen people believe that multiple organizations were confirming a vulnerability when all of them were simply repeating an unconfirmed claim from that data source.

Even in an instance where a service was being upfront about using their data, they were falsely claiming that it providing better quality data than it truly does. Three months ago we discussed MainWP promoting their usage of WPScan’s data with the claim that:

The Vulnerability database updates itself real-time so you don’t miss out on any vulnerabilities.

The reality here is that something updating in real-time does not say anything about the completeness of its data, just how much time it takes for new data to propagate and WPScan’s data is far from the most complete.

The WPScan Vulnerability Database is Not Listing any Vulnerabilities in This Plugin

As we mentioned earlier today, yesterday we had a request probably from a hacker on this website for a file from the plugin Google Drive for WordPress (wp-google-drive), which contains a vulnerability that was disclosed a month ago. As we discussed at the time of disclosure, the vulnerability was incorrectly labeled as being a remote code execution (RCE) vulnerability when disclosed. The actual type of vulnerability, arbitrary file deletion vulnerability, is a type that based on past experience is not something that hackers have been very interested in, so the interest from a hacker may be due to them believing the plugin actually contains a RCE vulnerability, since those are much more likely to be exploited, at least based on past experience.

Whether something in the plugin is actually going to be exploited or not, it would seem that letting people know that this plugin has publicly disclosed unfixed vulnerability would be even more important considering there is what looks to be targeting of the plugin. If you are relying on WPScan’s data though you wouldn’t know about it. If they had any vulnerability for the plugin in their data set it should be listed between the following two plugins, but nothing is listed:

By comparison we have listed the vulnerability in our data set since April 13. Considering that the vulnerability is unfixed and was listed on a prominent general data source since shortly before that, there isn’t a good reason for WPScan’s data to not contain it. At the same time WPScan’s data is available for free for non-commercial software, so the quality may be in line with what should be expected in that instance. The problem though is that often times it is promoted like MainWP promotes it, leading people to believe they are getting access to data at the same quality level as ours, without the cost of ours.

Other Free Sources Do Better, But Still Get It Wrong

WPScan isn’t the only free accessible source of vulnerability data and others do better when it comes to this plugin.

With the companion plugin for this service we include free data on vulnerabilities that look to be being exploited. Due to noticing the request for this plugin we added the previously disclosed vulnerability to it today, along with another vulnerability we found while looking over things.

In looking at other free data sources we found they included the vulnerability, though inaccurately labeled.

The plugin WebDefender, which contains its own vulnerability data, added the vulnerability on April 16, but labeled it as “Remote CE”, which seems to indicate they didn’t actually check over the report before adding it. Two days later the data source ThreatPress added the vulnerability and also incorrectly labeled it as a “Remote Code Execution (RCE) vulnerability”. When vulnerabilities are not checked over this can lead to a number other issues, including incorrectly stating that a vulnerability has been fixed when it hasn’t, which is rather common occurrence.

The closest we found to an accurate labeling was in spreadsheet linked to from an April 16 blog post on WPCampus that labeled it as “Authenticated Arbitrary File deletion” vulnerability. We are not sure where the idea that it required being logged in to exploit it, but at least the general type is correct.

03 May

We Wouldn’t Call WP Engine A Good Web Host for Providing Inaccurate Data on WordPress Plugin Vulnerabilities to Their Customers

When it comes to getting information on the security issues in WordPress plugins, developers of plugins are not always the best source. That is the case with a persistent cross-site scripting (XSS) vulnerability discovered by Federico Scalco that was in the plugin Caldera Forms. While that was claimed by the discoverer of the vulnerability, the developer of the plugin, and all of the other data sources of vulnerabilities in WordPress plugins we are aware of, to have been fixed in version 1.6.0 of the plugin, it actually wasn’t, as testing out the claimed vulnerability would have show any of them (the ease of testing that would will be something we will go into in another post). If you were using our service you would have been correctly notified that it hadn’t been fixed.

That has now been fixed in version 1.6.1.1. Here what the developer wrote about that:

This release is an additional fix for CVE-2018-7747 . I was alerted earlier today that there was one remaining problem that did not get fixed. The security issue that we disclosed two weeks ago is called a stored XSS vulnerability. In simpler terms that means that there was a way to use Caldera Forms to store some JavaScript that could be triggered to run later.

In Caldera Forms 1.6.0 I used a function that removes all JavaScript on the output that was previously exploitable. That prevented the stored JavaScript from running. Since exploiting a stored XSS vulnerabilities is a two step processes — store and then retrieve later — this update prevents the issue from being exploited in the future.

Caldera Forms 1.6.1.1 adds the same protection in one more location and prevents the behaviour that was shown to me today.

While we are not mentioned there for some reason, we were the ones that notified the developer of it not being fixed. The reality of the situation is that 1.6.0 had not removed “all JavaScript on the output that was previously exploitable” and the location which was claimed to be shown to them was part of the original advisory on the issue.

While we are not mentioned in that, they did link to one of the data sources, the WPScan Vulnerability Database, that falsely claimed that the vulnerability had been fixed before. That isn’t the only time that the developer of that plugin has recently promoted that data source, despite the developer now knowing that they provide inaccurate data.

The other example we ran across popped up in our monitoring of the wordpress.org Support Forum to keep track of vulnerabilities in WordPress plugins. In response to someone asking about a message from the WPScan Vulnerability Database about the vulnerability the developer wrote this:

Yes, there are security fixes in 1.6.0. I worked with the developer who found and responsibilities disclosed the issues. A part of that process is registering it with the database. That documents the issue.

More importantly, it triggers alerts that plugins need to be updated on good hosts. I got a notice from WPEngine about my own site. That’s the best system available to us for getting the word out about vuldrabilites that are not severe.

We don’t think a good web host would be spreading WPScan’s inaccurate data without at least having a disclaimer that the data has serious quality issues, which might have been a reminder to the developer that they shouldn’t be promoting it. By promoting data sources that are not responsible with their data, developers are actually hurting users of their plugins, since if we didn’t exist then the vulnerability likely would have remained in the plugin for the foreseeable future. If more people knew the truth about what different data sources provided it would likely mean more customers for our service, which would mean we could be doing even more to improve the security of WordPress plugins (and therefore WordPress in general), which is already probably more than every other security company out there.

Something else we noticed that seems worth noting it terms of improving the security of plugins was something mentioned in the post announcing the release of version 1.6.0 of the plugin:

In order to ensure that this fix does prevent these potential XSS vulnerabilities, and also that we do not re-introduce the vulnerability, we have created new automated tests. These tests, which are in a private git repository, will be run on future releases and we will add additional security checks in the future.

Clearly those automated tests didn’t actually accomplish that. Just in general, our experience is that automated testing is useful as additional tool for knowledgeable professionals when checking over the security of a WordPress plugin or other software, but they have some serious limitations and their abilities are often overstated.

02 May

Wordfence Falsely Claims Their Data Source on WordPress Plugin Vulnerabilities is “Official” and “Confirmed/Validated”

When it comes to getting data on vulnerabilities in WordPress plugins there appear to be a lot of sources, but in reality most of the time it is really comes from the WPScan Vulnerability Database. While we think that that data source is a good option for a lot of people since it is available for free, you do get what you pay for. And anyone reusing that data should be upfront about the real source of the data and alert people to the serious quality control issues that come along with it.

Considering that people behind the Wordfence Security plugin don’t seem to have any qualms about lying no matter how blatant the lies, it wasn’t surprising to see they have gone beyond not providing the proper disclosure of their use of WPScan’s data to making false claims that make it sound like it much better than it really is. We just ran across them giving their usage an imprimatur as being from an “official” source and falsely claiming that the data is “confirmed/validated” when neither of those things are true about the WPScan’s data.

In a recent thread on the wordpress.org Support Forum, which we ran across in our monitoring to keep track of vulnerabilities in plugins for our service, someone wrote:

Hello,

We’re noticing an increase in the amount of plugin updates that are not being marked as “Security Fix” in our wordfence emails (“Problems found on http://www.example.co.uk“).

The most recent occurrence of this was the uk-cookie-consent plugin.
This updated from 2.3.9 to 2.3.10 after a security vulnerability was patched.

Changelog:
2.3.10
Fixed: fixed security vulnerability identified by James Boughey

We maintain a large client base and rely on these emails to quickly determine if the update needs to be applied immediately (Security related) or if it can be put on hold temporarily (Feature update).

Kind regards

First, we should note that trying to decide whether to update a plugin based on data about what plugin vulnerabilities is a very bad idea, since even if you are using a better data source that the WPScan Vulnerability Database it isn’t going to provide the level of coverage of vulnerabilities needed to try to pick and choose what plugins to update. That is why in addition to providing a service with better data, we also have a plugin that will turn on WordPress built-in ability for plugins to automatically update.

Update 5/4: We should also note that one reason why someone might think that trying to choose when to update plugins based on claims that they have a security issue is something that is not a bad idea is Wordfence’s postings about vulnerabilities in plugins.

In this case it actually would have been correct for Wordfence to not mark this as a “Security Fix” since, as we discussed last week, the claimed vulnerability that was supposed to be fixed in that version didn’t actually exist.

The response from a Wordfence employee was this:

We do mark plugins as being vulnerable when we know for certain they are.

Unfortunately we can’t rely on authors’ changelogs for detecting vulnerabilities, because there are too many inconsistencies (for example, they might mention “security hardening”, which isn’t necessarily a vulnerability fix) and some authors maintain changelogs outside of wordpress.org or commit changelogs in a non-standard way.

Once a vulnerability is officially confirmed we update our servers’ list of known vulnerabilities which then allows scans to accurately report the issue.

I confirmed the “UK Cookie Consent” plugin now shows a critical scan result with a link about the security fixes for version 2.3.9 -> 2.3.10.

Contrary what is written there, Wordfence doesn’t actually have any idea if a vulnerability actually exists when they mark them as such. By “officially confirmed” they are actually referring to a vulnerability being listed in WPScan’s data, which isn’t official in any way, nor is there any official confirmation out there. (We confirmed that is their source by comparing WPScan’s data to what Wordfence is marking as including security fixes and we have also previously seen more obvious usage of WPScan’s faulty data by Wordfence.)

The ease that Wordfence lies about things continues to be stunning to us. That they not only get away with it, but that public comes up with excuses for them doing that, is a good example of why security is in such bad shape.

What makes this worse is that if you actually look at WPScan’s data for that claimed vulnerability they specifically note that it isn’t verified:

So the vulnerability isn’t actually confirmed even unofficially.

In a follow up reply the Wordfence employee had made further claims:

It’s not that we perform specific checks on our side, rather we update our list of known vulnerabilities by pulling information from an official source; our servers are updated at least once a day.

Sometimes a plugin author fixes a vulnerability that hasn’t been reported yet and in such case official sources for vulnerabilities do not report the issue.
Regarding the time frame; again it all depends on when the security issue gets confirmed/validated. We have no control over that.

Again, there is no official source. It obviously sounds impressive though, which seems to be the point, and they rightly assume that most people wouldn’t bother to question something like that.

Also, contrary what is claimed there, there is no reason that Wordfence couldn’t have control over confirming/validating vulnerabilities in WordPress plugins, but that would require doing some actual work. And why would they when they can get away with claiming to provide the “best security available” for WordPress websites while failing to even do the things actually claim to do.

That WPScan’s data include vulnerabilities that don’t exist is much less of issue than other problems including incorrectly claiming that vulnerabilities have been fixed when they haven’t (which we will be discussing a couple of examples of in an upcoming post), but also that they are missing a lot of vulnerabilities that are being exploited (including ones where there isn’t a fix), which you would be warned about by us even if you don’t use our service (through use of the service’s companion plugin).

If you are actually interested in getting the most complete data on vulnerabilities in WordPress plugins, with all of the vulnerabilities actually confirmed/validated, that is exactly what our service provides. We have been told that Wordfence doesn’t admit to people that our service or any like it exists if they contact them looking fro that, despite them admitting they were aware of us after someone called them out on the claim that no service like ours exists.

27 Apr

Wordfence Security Didn’t Actually Stop Exploitation of Vulnerability That Isn’t Really a Vulnerability

When it comes to security products and services one of the many problems is that the public often is making claims about them that are not true. Oftentimes people will claim that a product or service has successfully protected a website when they don’t know that is true. Instead they are assuming that is true because the website was not hacked while using it (that they know of), but considering that most websites don’t get hacked, that correlation does not indicate causation. We have also often seen people repeating claims that products can provide some particular type of protection which seem to be based entirely on an unsupported claim made by the makers of the product or service. Considering the many times we have seen security companies lying (in addition to many falsehoods that we can’t say whether they know what they are saying is true or not) those claims being repeated are often not true.

While looking into a report of a claimed vulnerability in a WordPress plugin the other day we ran into another example of that sort of thing. Someone going by the handle B0UG had claimed that the plugin UK Cookie Consent had contained a persistent cross-site scripting (XSS) vulnerability. A new version of the plugin was released, which indicated that this had been a vulnerability:

  • Fixed: fixed security vulnerability identified by James Boughey

As we discussed in more detail in our weekly post on claims of vulnerabilities in WordPress plugins that are not really vulnerabilities, there really wasn’t a vulnerability here since the supposed vulnerability involved a situation where WordPress users are specifically permitted to use the equivalent of XSS.

In the remediation of section of the report there is the following information:

Update to the latest version available. Implement a web application such as Wordfence.

Considering that this wasn’t really a vulnerability we wondering if the plugin Wordfence Security would truly stop this as claimed. It seemed unlikely, since, as we just mentioned the supposed vulnerability involved action that is actually permitted to be happening.

To test things out, we created a fresh install of WordPress 4.9.5, and then installed version 2.3.9 of Cookie Consent, and version 7.1.3 of Wordfence Security. We then did the first three steps of the proof of concept for the supposed vulnerability using an Editor-level user (since that would be the lowest level user that would normally have the ability to take those steps):

1) Access WordPress control panel.
2) Navigate to the ‘Pages’.
3) Add a new page and insert the script you wish to inject into the page title.

Wordfence didn’t stop doing any of those steps. We set the script in step 3 to show an alert box that reads “Wordfence Security was supposed to stop this.”

Then logged in as Administrator-level user we completed the steps that could only be taken by them:

4) Now navigate to ‘Settings’ and select ‘Cookie Consent’.
5) Now click on the ‘Content’ tab.
6) Your injected script will now be executed.

If Wordfence Security didn’t prevent this from happening the message “Wordfence Security was supposed to stop this.” would be shown at step 5 and that is exactly what happened:

That is actually the correct result, but it wasn’t what someone that thinks they have some security knowledge believed and was telling others, which is a good reminder of the poor state of security recommendations out there. What makes it more striking is that it would have been easy to test this out, unlike so many other inaccurate claims that are made. If a claim is being made regarding security products and services without supporting evidence (which is true about almost all of them) it would probably be best to assume that it is false based on everything we have seen.

02 Mar

This Isn’t Great Information on What Are Supposed to be the Most Attacked WordPress Plugins

When it comes to better understanding security surrounding WordPress there is dearth of useful data. For example, despite millions of websites using various security plugins and numerous claims of the effectiveness of them, the few test we have done of them to see if they could protect against the exploitation of real vulnerabilities in other plugins are almost the only testing that has every been done. Considering that that the results showed that they provide almost no protection, it isn’t like a lack of testing is due to a lack of need for that information. Most of the data that you might run across is of little value and often is distorted even further when repeated by others.

Recently while we were looking for information on something else we ran across a recent post on the website, jeffbullas.com, titled “The Top 50 Most Attacked WordPress Plugins Making Your Site Vulnerable to Hackers” (http://www.jeffbullas.com/attacked-wordpress-plugins/). A few paragraphs in, things already looked really bad, as there is this claim:

One study revealed that almost 98% of WordPress blogs were easily exploited because they were running outdated versions of the software, or outdated plugins.

There is no link to this supposed original study or any other information in the post about it (despite plenty of other links in it), so who knows if it really exists. But it if did, it must have come from someone that has no idea what they are talking about, since the number is absurd.

Moving on, here is the explanation of the information provided:

This post will highlight the 50 most attacked WordPress Plugins in 2017. The report will showcase:

  • The number of total attacks. This will determine the total number of attacks that were reported by the particular plugin.
  • The type of the attack. This will reflect the “Location File Inclusion” (LFI) attack that allows exploiters to download any file they want, or the “Unrestricted File Upload” that allows exploiters to upload a “shell” that gives them full remote access to target the site.
  • The exploit database link. This will determine the language used by the penetration testers and vulnerability researchers.
  • The WordPress plugin website.This will provide you details and information about the plugin and a link to download.

There is no explanation as to where the total number of attacks is supposed to have come from, which seems like it would be rather important to note. It looks like for portions of the list the plugins are ranked by the number of attacks, but occasionally the number of attacks changes dramatically from one plugin to the next, which makes us more suspicious as to whether the numbers are even real.

In an indication of the lack of understanding of the topic by the author, they confuse a local file inclusion (LFI) vulnerability with an arbitrary file viewing (or arbitrary file download) vulnerability despite linking to a page that accurately describes what a LFI vulnerability is.

We can’t even decipher what “This will determine the language used by the penetration testers and vulnerability researchers.” is supposed to mean (we also haven’t seen evidence that penetration tester discover a measurable amount of vulnerabilities in WordPress plugins).

Right after that is this statement:

If you use any of these attacked WordPress plugins on your website, you may want to look into ways to improve your security.

That’s not all that helpful.

At the bottom of the post they give better advice, though the post doesn’t indicate if the vulnerabilities have been fixed and therefore is upgrading will do any good:

If you use any of the above plugins, ensure you upgrade to the latest version, and adopt Wordfence with Firewall enabled to protect your WordPress sites from unexpected brute force attacks in the future.

Also notable here, is that brute force attacks are hot happening, so installing a plugin to protect against them would not be good advice since it would also add additional security risk (that isn’t a hypothetical risk).

To see the questionable value of this type data (if it was even accurate) just look at the first entry:

#1. Recent Backups (Backup for your website)

Total attacks: 2,159,725

Type: LFI

Exploit database:https://www.exploit-db.com/exploits/37752/

Website link: https://wordpress.org/plugins/recent-backups/

First this vulnerability was disclosed on August 10, 2015, so there is a good chance that if it would have lead to a website being hacked it likely would have occurred before 2017. What is important to note is that the type of vulnerability, arbitrary file viewing, is one of the most targeted types of vulnerabilities, but it doesn’t appear to usually lead to websites being hacked. What the vulnerability is normally exploited to do on a WordPress website is to view the contents of the WordPress configuration file, wp-config.php. The main piece of information that can be gathered from doing that are the database credentials for the website. As best we can tell hackers don’t try much to utilize that, the only time we can recall that leading a lot of WordPress websites being exploited due to that type of vulnerability was when GoDaddy had screwed up and starting making databases remotely accessible that were configured to not allow that.

The other thing that seems rather important about this, is that plugin is only used on 100+ websites according to wordpress.org, so the impact its exploitation could theoretically have is rather limited.

If the attack number is accurate, the main take away here is that hackers will try to exploit vulnerabilities that are used on very few websites and where the chance of successfully exploiting them is limited. That doesn’t require a list of 50 plugins and the post doesn’t provide any insight like that or useful information like if the vulnerabilities were fixed.

A far simpler way to check if you are using versions of plugins that hackers appear to exploiting would be to install the companion plugin to our service, as that will automatically check all the plugins installed against the free data on just that type of vulnerability that comes with that plugin.

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>

21 Feb

The Failure to Update Vulnerable Plugin is Reminder of Security Industry’s Apparent Lack of Interest in Making Sure Websites Are Secure

Something we have recently been thinking might be a helpful way to explain why security is in such bad shape despite the amount of money being spent on it, is to think of the security industry not as the “security industry” but as the “insecurity industry”. By that we mean that most of the security industry seems to not be focused not trying to make things secure, but on selling people on the idea that insecurity is very much the natural state of things, that you are under constant attack, and that while they can offer you the best security, you shouldn’t expect that the protection provide by that is actually all that effective.

As an example of that, take something from Wordfence recently, where they seem be describing a situation where some web hosts had failed at doing a basic of security for their service and allowed customers to access to other customers’ files. Not only is that a failure at a basic level for a web host, what they seem to be  describing is something that was huge issue with web hosts a number of years ago, so there would be even less excuse for that still happening in 2018. To Wordfence though the situation was very different:

It’s important to note that vulnerabilities are a fact of life in any service, system or software. Finding, confidentially disclosing and fixing vulnerabilities is how industry works with the information security community to improve the products and services we use and keep the public safe. The process that we use is well established and is widely used by organizations that include Google’s “Project Zero” and Cisco’s “Talos” security group.

When vulnerabilities are found and vendors are responsive, you benefit as a customer of those vendors and can know that your vendor reacts quickly to fix security problems and will likely do so long term, keeping you and your data safe.

A disclosure like this is not an opportunity for “vendor shaming” or a witch hunt. All developers who write enough code write vulnerabilities at some point in their career. It is in fact a moment to celebrate responsive vendors and a well handled incident that left customers and the online community safer.

At Wordfence, we are excited when a vendor works closely with us to fix a vulnerability and responsive vendors garner the greatest respect from our engineering team.

If you read over the whole post and the comments it seems pretty clear that Wordfence doesn’t even know what the underlying cause of the issue was, so the idea they worked closely with the web hosts to fix it seems to be something we see fairly common with them, a hyperbolic statement overstating what they are doing.

What makes this worse is that it is likely that Wordfence’s keeping quiet on this allowed the problem to fester when if it had publicly disclosed promptly there would have been more pressure on the web hosts to promptly fix this. By not doing that there was an upside for Wordfence though, as they could get more people to pay them to clean websites, when the web host really should have been handling cleaning them up since they caused the problem in the first place.  You also have to wonder about Wordfence not seeming to understand that disclosing something is being exploited already is not the same as discovering something that hackers don’t appear to know off yet, where a limited delay of disclosure can make a lot more sense.

Also notable, one of the comments doesn’t paint such a great picture of Wordfence’s handling of this:

My client got hacked several times on Hostway and neither Hostway or Wordfence’s cleaning team figured out this was the issue at the time. We changed hosting providers and have been safe ever since. I’m glad you found this both to validate my diagnosis that the weak link was Hostway and so that Hostway’s customers will now be safer.

60 Percent Insecure

If we are wrong about this and the most of the security industry is in fact concerned about security, they don’t seem to be acting in a way that matches that. To show how even the basics of security are still failing to happen, while security companies don’t seem to acting as if there is a crisis  and instead trying to sell people on more advanced solutions (for which there is little to no evidence are actually more effective or effective at all) takes something we just ran across.

Several days ago we had a request at one of our other websites for a file that would be located at /wp-content/plugins/smart-google-code-inserter/smartgooglecode.php, which is a file from the plugin Smart Google Code Inserter. That was likely a request probing for usage of that plugin before trying to exploit a vulnerability in it. After noticing that we went to try to figure out what a hacker might be interested in trying to exploit in the plugin.

In looking over the current version we didn’t see anything that looked like it might be targeted by a hacker.

On January 1 Benjamin Lim had disclosed a persistent cross-site scripting (XSS) and a SQL injection vulnerability had existed in earlier versions of the plugin. The persistent cross-site scripting XSS vulnerability seems like it could be something that a hacker might be interested in since that would allow a hacker to get malicious code to be served up on the frontend pages of vulnerable websites and just that type of issue has been something that has been exploited before.

Those vulnerabilities were fixed on November 29, so if people were doing the security basic step of keeping software up to date, attempts to exploit this shouldn’t be of much concern since it shouldn’t impact many of the 9,000+ active installations of the plugin (according to wordpress.org). Unfortunately, if the wordpress.org data is accurate, about 60 percent of the installs of this plugin are still not using the fixed version, 3.5:

The Wrong Focus

To bring this back around to Wordfence, also in November, we wrote about how their behavior relates to just this issue:

When it comes to improving the poor state of security, what can be seen over and over is that the focus needs to be on the basics. Take for instance the widely covered breach of Equifax, which was a situation where simply keeping their software up to date would have prevented the breach from happening. But the security industry isn’t focused on that and doesn’t seem to ever consider that what they are doing is far too often part of the problem, even when it impacts them.

That type of issue applies with WordPress plugins, where many hacks involve exploitation of vulnerabilities that have already been fixed. So what is probably going to provide you better protection then any security product or service would be to simply keep your plugins update at all times (many of the security plugins don’t seem to provide any protection against those vulnerabilities), which can be done with things like our Automatic Plugin Updates plugin. But telling you that doesn’t help the security industry to sell their products and services, so you don’t often here that from them.

As example let’s take a look at a post from yesterday from Wordfence about vulnerabilities in several plugins, which ends:

We encourage you to share these vulnerabilities with the larger WordPress community to help keep site owners safe from exploitation.

If you read through the rest of the post they don’t ever say that you should be keeping your plugins up to date at all times, which is actually the best advice when it comes to the vulnerabilities mentioned there. Instead they tell you the plugins they are mentioning now should be updated “immediately”, which for one of the plugins is well after a hacker had started trying to exploit one of the vulnerabilities that had been in it. The three plugins they mention are far from the only recent updated plugins that had updates that fixed security vulnerabilities, so only mentioning that people should update those isn’t all that helpful.

The rest of the post is like so much from Wordfence, mainly an ad for their services, which seems to be the real reason they want people to share it. As well get to in a moment one of the vulnerabilities in the plugins they mention is an example of the poor quality of what Wordfence paid service provides over doing the basics and the post shows again that Wordfence has very limited security knowledge, despite claims to the contrary.

A couple weeks later we wrote something along the same lines involving another well known name in WordPress security, Sucuri.

To see another indication of the lack of understanding of the important of keeping software up to date at all times from the security industry, checkout a comment from another posts of ours from someone that describes themselves as a “Web application security and accessibility evangelist.”

By comparison, well before we ever created this service, we had introduced the aforementioned Automatic Plugin Updates plugin, which turns on WordPress’ abiltiy to automatically update plugins.

15 Feb

A Doubly Bad Way to Check if Your WordPress Website Uses Plugins With Known Vulnerabilities

One of the many problems with the security industry is the use of ineffective solutions to tackle various tasks when much more effective solutions are readily available. While some of the usage of those less effective solutions may be necessary due the particulars of a situation, it seems that most usage is due to people providing security products and services despite not having a great grasp of security and the ability to make more money using those less effective solutions (at the expense of the customer getting a bad result). The way that leads to more money can come from getting sales for a product a service over others by making them sound more impressive than the more effective solution, which we will get to an example of in a bit, or by promoting the less effective solution as being a cheaper, but equally effective solution, when it really isn’t even close to being as effective.

When it comes to checking if a WordPress website is using plugins that contain known vulnerabilities the method used for our service is very effective. When we come across a report of a vulnerability (or in many cases become aware of one without a report having been released) in a plugin, we test things out to make sure that the vulnerability has existed and determine which versions of the plugin are impacted. We then add that info to our data set that can then be accessed through an API by the companion plugin for our service.

The companion plugin collects information on the plugins that are installed on the website along with the versions numbers of those plugins. That information is then sent to our website and any vulnerabilities that are in the current version or in other versions can be returned and then displayed or emailed by the companion plugin. That means that in seconds a check can be done and it can be easily repeated over and over (you can have the check done as often as every hour).

Live Testing

As example of a less effective solution that we would imagine sounds more impressive than that, take the Detectify service that we mentioned back in September, which was promoted with the following:

Detectify is a web security service that simulates automated hacker attacks on your website, detecting critical security issues before real hackers do.

While that may sound impressive, in reality it seems like really ineffective way to check for known vulnerabilities in WordPress plugins. Many WordPress plugin vulnerabilities being disclosed involve an action being taken by an Administrator, so to test for those things the service would need to have full access to the website, introducing additional security risk. Plenty of vulnerabilities have a persistent impact, so it seems like you wouldn’t want to have them tested for on a live website. For example, the other day we detailed an authenticated arbitrary file deletion vulnerability. To test that out, the service would have try to delete a file, so either the service is going to be delete a file intended to be on the website or it will need the ability to create a new file to delete.

Doing that testing on the website is going to take a lot more time then what is done with our service and it doesn’t look like that service is designed for continuous checking.

Another limitation of that service is that it has a fairly limited number of WordPress vulnerabilities it checks for, in fact it looks like we have more vulnerabilities in our data set than they check for in all types of software.

Making all that worse, if you are only interested in checking a WordPress website then that the service is going to cost you a lot more than ours. If you want to scan for things that require authentification the price is 10 and half times more than our service (and six times as much without authenticated checking).

WPScan and Burp WP

Recently we came across someone suggesting another route for checking a WordPress website for known plugin vulnerabilities, which lead to us writing this post:

I recently came across Burp WP, a WordPress scanning plugin for Burp Suite. It’s similar to WPScan, and uses the WPScan Vulnerability Database as its source of vulnerabilities. If you already use Burp for vulnerability scanning, then it’s nice to be able to include Burp WP to deep-dive into a WordPress site, without having to run WPScan separately.  I’ll be installing it on Monday to give it a test shortly after updating my sites to WordPress 4.9.3.

Neither of those tools will actually do a deep-dive into a WordPress website, since they work from the outside. That is one the two reasons they are bad for checking the plugins for known vulnerabilities.

One way those types of tools can check what plugins are in use is to look for references to them in frontend pages on the website. That approach is going to miss a lot of plugins since many don’t have anything that shows up there. The other would be to request the readme.txt files for each plugin (or some other file or maybe a directory) to see what ones are installed. So either you are likely to be missing a lot of plugins or you are going to making 100s or 1,000s of requests (depending on how many plugins there are in the data set of known vulnerabilities). In some cases one of those approaches could get you the version number of the plugin, but it won’t always, so you are not always going to be sure without further checking if the vulnerability impacts the version being used. Like the other solution, continuous checking is going to be difficult.

The second problem is the data source that is being checked against with those tools, the WPScan Vulnerability Database. That data source has one big positive, its data is accessible for free, but it also has a lot of negatives. Seeing as tools like that are promoted as being used by security professionals, you would expect that a lot times they are being used in instances where fees are being charged that would allow for using higher quality data than what is available for free.

You can look back at our past posts discussing the negatives aspects of that data, but to give you a quick idea let’s give you two recent example of the issues that we have found.

Just a couple of days ago in the context of a false claim that you won’t miss out vulnerabilities if you rely on WPScan Vulnerability Database, we noted a couple of recent examples of it missing vulnerabilities it really shouldn’t have. One of them was a vulnerability that was disclosed in early January, which had been being exploited before it was fixed. The other was a vulnerability we disclosed in late November that likely is being exploited and that has yet to be fixed. Those both seem like the kinds of vulnerabilities you would want to know about, but if you relying on that data source you wouldn’t (those are far from the only ones).

A very recent example involves a vulnerability disclosed in the plugin Bookly Lite less than a week ago. Here is the WPScan Vulnerability Database entry for that:

The problem with that is that not only was the vulnerability not fixed in version 14.5, it wasn’t even fixed as of the when that entry was added and last updated.

Before that vulnerability was even in that data set we had already tested out the vulnerability, determined the vulnerable versions, determined that it hadn’t been fixed, added it to our data set, and contacted the developer to let them know it wasn’t fixed. We have yet to hear back from them, but earlier today the vulnerability was fixed (though in a less than ideal way).

So with that data source you really need to double check to see if the vulnerabilities have been fixed since the data isn’t reliable in that regard, which with our service we have already done for you.