19 May

Vulnerability Details: Persistent Cross-Site Scripting (XSS) Vulnerability in WP Booking System

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

19 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in MaxButtons

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

18 May

Vulnerability Details: Remote Code Execution (RCE) Vulnerability in BibleGet I/O

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

17 May

Wordfence Spreads False Report of Vulnerability in WordPress Plugin From WPScan Vulnerability Database

When it comes to improving the security of the WordPress ecosystem one of the big problems we see is that there is so much misinformation coming from the security industry itself. A prime offender is Wordfence, which despite having the most popular WordPress security plugin, is run by people that don’t seem to know almost anything about security and don’t seem to have any concern for accuracy in the claims they make (they also are fine leaving people relying on their plugin vulnerable to being hacked despite claiming that it will protect them).

Based on that we weren’t surprised that they would be spreading false information about a claimed vulnerability in a plugin based on data from the WPScan Vulnerability Database, which we have repeatedly warned has serious accuracy issues.

They also provided advice on evaluating plugins, which not surprisingly considering their lack of security knowledge, isn’t very useful for protecting against vulnerabilities that are a real threat. But there are things that you can that will actually help to protect you from those, as well get to.

A Lack of Due Diligence

In the post 22 Abandoned WordPress Plugins with Vulnerabilities they provide the list mentioned in the title using vulnerability listings from the WPScan Vulnerability Database. You don’t have to get past the first item list to find a problem, one that should have been fairly obvious. Here is the beginning of the list:

The first plugin WP PHP widget sticks out there as it 30 times more popular than the second most popular than the second most popular. While there are certainly issues with insecure plugins not being removed from the Plugin Directory (which is likely to get worse going forward as we will get to in an upcoming post), that seems like something that should been a red flag to Wordfence.

The asterisk next to it names indicates that the vulnerability being fixed:

We also found 4 plugins (marked with asterisks in the table below) that have fixed a vulnerability, but their fix was released in such a way that existing users are not updated to the newest fixed version. In each case, the author committed a fix to trunk but did not increment the version number and tag it properly in the plugin repository, so their users remain vulnerable.

Slightly down the post there is slightly different statement about the asterisk:

If the plugin is marked with an asterisk, you can disable and remove the plugin. Then reinstall it and you should have a newer version. We have not audited individual plugins for security so we can not verify whether a vulnerability has been comprehensively fixed.

We can’t understand why a security company would on the one hand say that vulnerabilities have been fixed, but that they didn’t actually check that they were fixed. That is irresponsible at best, incredibly negligent at worst. In the case of the claimed vulnerability in WP PHP widget they don’t appeared to have check things at all.

The first clue to that is the fact that the underlying report of the claimed full path disclosure vulnerability in the plugin was released on December 21, 2012, while the last update to the plugin was on November 10, 2010. That seems like a good indication that no change was made in regards to the report.

While there were changes made to the plugin after version 1.0.2, which is the most recent version and the one listed as being vulnerable, they don’t look like they could be related to claimed vulnerability.

Looking at that report it doesn’t come across as something that looks at all that legitimate as there is no code or explanation provided as to the issue. The only information given is that the vulnerability is supposed to be a full path disclosure vulnerability and that the vulnerability is “http://localhost/wp-content/plugins/wp-php-widget/wp-php-widget.php”.

If you were to install plugin on a production server requesting the URL /wp-content/plugins/wp-php-widget/wp-php-widget.php won’t normally cause a full path disclosure (will show what that is in a second), so that may have been the extent of what Wordfence did, if they did anything. The lack of full path disclosure would be equally true if you tried this with any version of the plugin.

Where you would get the full path disclosure if you had error reporting enabled in the server’s settings, in that case visiting the URL would get the following message:

Fatal error: Class ‘WP_Widget’ not found in [redacted]/public_html/pluginvulnerabilities.com/wp-content/plugins/wp-php-widget/wp-php-widget.php on line 29

In place the portion of that we redacted you would get the rest of the path to the file on the server, hence a full path disclosure. That alone isn’t going to allow you to hack a website, but it might aid in exploiting some other vulnerability.

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

So Wordfence’s claim that that the vulnerability had existed, but had been fixed is simply false. Either there never was vulnerability or there is a vulnerability that was never even attempted to be fixed. If it is the latter, then based on Wordfence’s recommendation you should be removing WordPress as well.

Evaluating the Security of Plugins

At the end of the post they state:

Plugins can make adding functionality to your website incredibly easy and are a big part of why WordPress is such a popular platform. The plugin repository on WordPress.org is an incredible resource, but as we have shown above it contains both abandoned plugins and ones with known vulnerabilities. Every plugin you add to your site increases your security risk, and you should evaluate each one to make sure it is being properly maintained.

Prior to that they give evaluation criteria:

A large number of plugin updates are submitted to the WordPress repository every day. For this reason it is important that you gain at least a basic understanding of who is behind a particular plugin before you install it. Here are a few steps you can take to evaluate whether you should use a plugin:

  • Check the average plugin rating.
  • Check when it was last updated.
  • Check that it is compatible with the current version of WordPress.
  • Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers but you should examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.

While we certainly suggest choosing a plugin that is being supported enough to list it as being compatible with the latest version of WordPress, it is important to understand that those criteria really are not a good way of avoiding an insecure plugin. To highlight that, look at results of looking at the information for the plugin Delete All Comments as of November 15 of last year (WordPress 4.6 was the then current of WordPress):

That all seems to meet their criteria, but five days later the security company NinTechNet would discover there was vulnerability in that was already being exploited. Even though the plugin has been recently updated before that, the vulnerability has never been fixed, so a plugin being maintained up the point you install it doesn’t necessarily even insure that an exploitable vulnerability will be fixed.

Realistically there isn’t much the average WordPress webmaster can do to evaluate the security of plugins. Instead your best bet is to make sure you are keeping your plugins up to date at all times and then look at options to provide you extra protection against vulnerabilities in them.

Our testing has shown that other security plugins don’t provide much protection against vulnerabilities in other plugins. For example, the vulnerability in Delete All Comments was not stopped by any of the 16 plugins we tested.

We offer several options that can provide extra protection. First the companion plugin for our service warns you when you are using plugins with vulnerabilities we see hackers targeting. To get more complete vulnerability data you can sign up for our service. Through our service we also work with developers to get vulnerabilities fixed and if you are using a plugin that hasn’t been fixed we are always available to consult with you on how best to deal with that (including providing you with a temporary fix so you can continue to use the plugin in the short term). When you use our service you also get suggest/vote for plugins to have a security review from us, which would catch many common security vulnerabilities in the review plugins (you can see the results of those review so far here).

17 May

Did Checkmarx Make Up Claimed High-Risk Vulnerabilities in Top WordPress e-Commerce Plugins?

Security journalism has been in rather bad shape for years, but at times it manages to be worse than others.

When it comes to coverage of WordPress what was a fairly popular line of stories years ago was to repeat claims by security companies that they had found a bunch of websites that had the same hack that were all running a certain outdated version of WordPress, with the implication of this that the hack was related to the WordPress version. When we would look into this we find problems from that websites were not all running the claimed version of WordPress or even running WordPress all, to vulnerabilities being cited as being in a certain version of WordPress actually being claimed vulnerabilities in plugins, to the blog of the security company where the claims were made running an even more out of date version of WordPress.

In recent years coverage has focused on vulnerabilities in WordPress plugins, which have actually existed, but in most cases are nowhere near as severe as the coverage would lead to believe (vulnerabilities in plugins that actually were severe often don’t get covered). It doesn’t appear that this change was due to security journalist requiring more proof before covering claims, instead it just seems to be have been happenstance as something that occurred late last year shows.

Back in late November the security company Checkmarx put out a report that they had found “high-risk vulnerabilities” in four WordPress plugins for eCommerce that could lead to “users of over 135,000 websites could find their personal data threatened by malicious parties or cyber criminals”. That lead to stories at Threatpost, SC Magazine, Computerworld, and Network World. At the time we noted that there wasn’t any actual evidence present to back up the claim and that it seemed entirely possible that vulnerabilities were not really severe. As SC Magazine wrote, the details, like what the name of the plugins was, would be released later:

Additional details on the vulnerabilities will be revealed only after the affected plug-in distributors have had an opportunity to respond to the disclosure, the company noted.

Recently we came across something else related to Checkmarx and that made us recall this. At that point we went looking to see if they had released any details of the vulnerabilities, we couldn’t find anything.

Several weeks ago we contacted the company to inquire where we could find the details of those vulnerabilities, we haven’t heard back.

Considering that it has been five months since they made the claims, there has been more than enough time for responsible disclosure, so we have to wonder if the vulnerabilities ever existed.

15 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Crafty Social Buttons

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

11 May

WordPress Plugin Security Review: Contact Form by BestWebSoft

For our eighth security review of a plugin based on the voting of our customers, we reviewed the plugin Contact Form by BestWebSoft.

If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.

The review was done on version 4.0.5 of Contact Form by BestWebSoft. We checked for the following issues:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Lack of protection against unintended direct access of PHP files

Results

We found three issues during our review and notified the developers of our finding a month ago. The most serious issue we found, a reflected cross-site scripting (XSS) vulnerability, was fixed in version 4.0.6 of the plugin. There has been no change made to plugin to deal with the other two so far.

Reflected Cross-Site Scripting (XSS) Vulnerability

As we previously disclosed, we found that in the file /bws_menu/bws_menu.php the value of GET input “category” was echo’d without any sanitized or escaped, leading to reflective cross-site scripting (XSS) vulnerability. We also found that the same vulnerability was at the time in 40 other plugins by the developer.

Possible Deserialization of Untrusted Data

In several locations in the plugin requests are made to URLs on the developer’s website using the function wp_remote_post() over HTTP. That opens up the possibility of a man in the middle attack. While that isn’t a big concern, the result of those requests in some instances is run through the function maybe_unserialize(), so there is the possibility of PHP object injection if that were exploited. Seeing as the website is accessible over HTTPS, it looks like they could make these request more securely quite easily. This occurs in the files /bws_menu/bws_menu.php, /bws_menu/class-bws-settings.php, and /bws_menu/deprecated.php.

Lack of Protection Against Direct Access to Files

The plugin’s .php files lack code at the beginning of the files to restrict direct access to them.  We didn’t see anything that could be exploited in the files without the restriction in place.

08 May

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Huge IT Forms

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

05 May

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in RSS Post Importer

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

05 May

Be Aware That the Claimed Impact of Vulnerabilities is Not Always Accurate in Vulnerability Reports

When it comes to the many problems with the security industry, one of them that we see very often due to our work for this service is overstating the impact of vulnerabilities and claiming that issues that are probably not vulnerabilities are in fact ones.

The latest example of this we have come across is from DefenseCode, a company whose advisories we warned to be wary of last week. Earlier this week they put out a report (PDF) of claimed SQL injection vulnerability in the plugin Photo Gallery. The problems with it is that they are claiming an issue that we wouldn’t consider to be a vulnerability as being one, along with it looking like they overstated the potential impact, if it truly was one.

What makes us consider this to not be a vulnerability is the fact that is only accessible by Administrators, something they acknowledge in a way that seems misleading:

During the security analysis, ThunderScan discovered SQL injection vulnerability in WebDorado Gallery WordPress plugin. The easiest way to reproduce the vulnerability is to visit the provided URL while being logged in as administrator or another user that is authorized to access the plugin settings page. Any user with such privileges can obtain the valid bwg_nonce value by previously visiting the settings page.

What seems like it should be fairly obvious is that Administrators being able to do something isn’t usually a vulnerability. Normally Administrators would have the ability edit existing plugins and remove security checks or add new plugins that accomplish the same thing as the vulnerability.

So what other users would be “authorized to access the plugin settings page”? Normally none as the setting’s page and the AJAX function that are utilized to exploit this are only accessible to users with the ability to “manage_options“, which is only given to Administrators by default.

If you give a lower level user the “manage_options” capability two of the things they can do is to change whether user registration is enabled and what role that new users would have, so they would have the ability to create new Administrator users at that point and therefore you are effectively making them Administrators by giving them that capability.

That makes the next part of the claim somewhat moot as all the users who have access would effectively have full administrative privileges:

Users that to do not have full administrative privileges could abuse the database access the vulnerability provides to either escalate their privileges or obtain and modify database contents they were not supposed to be able to.

There is actually another problem with that beyond that user already being privileged because as far as we can tell the SQL injection vulnerability in this case couldn’t be used by the user to “escalate their privileges” or “modify database contents”. Looking at the relevant SQL query it looks to us that it could only be used to read data out of the database (the value $album_id is what is specified by the user):

$query = "SELECT id FROM " . $wpdb->prefix . "bwg_album WHERE published=1 AND id<>" . $album_id . " " . $where . " UNION ALL SELECT id FROM " . $wpdb->prefix . "bwg_gallery WHERE published=1 " . $where;

Maybe we are missing something here, but it seems that security companies often don’t understand that not all SQL injections have the same impact, so they repeat claims of what one could do without understanding if the one they found could do also be used to do that.