05 Dec

WordPress Plugin Security Review: Amazon Web Services

For our sixteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Amazon Web Services.

If you are not yet a customer of the service you can currently sign up for the service for half off and then start suggesting and voting on plugins to get security reviews. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our new tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service.

The review was done on version 1.0.4 of Amazon Web Services. We checked for the following issues during this review:

  • 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
  • Security issues with functions accessible through any of the plugin’s shortcodes
  • Security issues with functions accessible through the admin_action action
  • Security issues with functions accessible through the admin_init action
  • Security issues with import/export functionality
  • Security issues with usage of is_admin()
  • Host header injection vulnerabilities
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites

Results

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. Most of the files only define classes, so there is nothing exploitable if they are accessed and adding a restriction has limited value. Other files though generate parts of admin pages and code will run when those are accessed. While in this case there was nothing that looks like a security issue due to that, in recent times we have added new vulnerabilities to our date set that were caused by files of that type where limiting access would have lessened the risk of the vulnerabilities.

20 Nov

WordPress Plugin Security Review: Nav Menu Roles

For our fifteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Nav Menu Roles.

If you are not yet a customer of the service you can currently sign up for the service for half off and then start suggesting and voting on plugins to get security reviews. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our new tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service.

The review was done on version 1.9.1 of Nav Menu Roles. It has been a few months since we last did a review and in that time we have added six additional items that we check on during the review. We checked for the following issues during this review:

  • 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
  • Security issues with functions accessible through any of the plugin’s shortcodes
  • Security issues with functions accessible through the admin_action action
  • Security issues with functions accessible through the admin_init action
  • Security issues with import/export functionality
  • Security issues with usage of is_admin()
  • Host header injection vulnerabilities
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites

Results

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Three of the five .php files in the plugin lack code at the beginning of the file to restrict direct access to the files. As those three files only define classes, there is nothing exploitable due to that.

07 Aug

WordPress Plugin Security Review: wpDataTables Lite

For our thirteenth security review of a plugin based on the voting of our customers, we reviewed the plugin wpDataTables Lite.

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 Lite 1.2.2 of wpDataTables Lite. 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
  • Insecure and unwarranted requests to third-party websites

Results

We found several vulnerabilities and an additional minor security issue. After notifying the developer of those issues, they have, for the most part, been resolved in version 1.2.3.

Cross-Site Request Forgery (CSRF) Vulnerability

The plugin functionality for deleting one of its tables lacked protection against cross-site request forgery (CRSF). That was fixed in version 1.2.3

SQL Injection Issues

That CSRF vulnerability also allowed for SQL injection. Here is how the function that does the deleting looks as of version 1.2.2:

function wpdatatables_delete_table( $id ){
    global $wpdb;
    if( empty( $id ) || !current_user_can('manage_options') ){ return false; }
 
    $wpdb->query("DELETE
									FROM {$wpdb->prefix}wpdatatables
									WHERE id={$id}");
    $wpdb->query("DELETE
									FROM {$wpdb->prefix}wpdatatables_columns
									WHERE table_id={$id}");
    $wpdb->query("DELETE
									FROM {$wpdb->prefix}wpdatacharts
									WHERE wpdatatable_id={$id}");
}

The SQL statement there lacks protection against SQL injection, either through the user of prepared statement or less ideally sanitization or validation.

The value of $id used in the statement comes from the following code:

$id = $_REQUEST['table_id'];
 
if (!is_array($id)) {
 
	wpdatatables_delete_table( $id );
} else {
	foreach ($id as $single_id) {
 
		wpdatatables_delete_table( $single_id );

Which passes user input to the function without sanitization or validation either.

There are a number of other locations in the code where the plugin has lacked proper security for SQL statements. The other one that we found vulnerable was the function wdt_get_table_by_id():

function wdt_get_table_by_id( $table_id ){
	global $wpdb;
 
	do_action( 'wpdatatables_before_get_table_metadata', $table_id );
 
	$query = "SELECT *
	  				FROM {$wpdb->prefix}wpdatatables
	  				WHERE id={$table_id}";

One of the avenues for getting to that function is through the function wpdatatable_shortcode_handler(), which as the name suggest handles the plugin’s shortcode. It is possible for any logged in user to access most shortcode’s through WordPress’ AJAX functionality, so those should be a check to make sure the user should have access as well as proper security surrounding of any user input that came come through that. In this case the code lacked either of those, passing an unsantized and unvalidated user input to the function wdt_get_table_by_id():

function wpdatatable_shortcode_handler( $atts, $content = null ) {
	global $wpdb, $wdt_var1, $wdt_var2, $wdt_var3, $wdt_export_file_name;
 
	extract( shortcode_atts( array(
		'id' => '0',
		'show_only_chart' => false,
		'no_scripts' => 0,
		'var1' => '%%no_val%%',
		'var2' => '%%no_val%%',
		'var3' => '%%no_val%%',
		'export_file_name' => '%%no_val%%',
		'table_view' => 'regular'
	), $atts ) );
 
	// Protection
	if(!$id){ return false; }
	$table_data = wdt_get_table_by_id( $id );

The SQL statement in the function wdt_get_table_by_id() was parameterized in version 1.2.3.

Lack of Protection Against Direct Access to Files

The plugin’s .php files lacked 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. Code to protect against that was added to many files in version 1.2.3.

31 Jul

WordPress Plugin Security Review: Archive Control

For our fourteenth security review of a plugin based on the voting of our customers, we reviewed the plugin Archive Control.

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 1.3.3 of Archive Control. 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
  • Insecure and unwarranted requests to third-party websites

Results

We found two very minor issues with possible security implications, but not any vulnerabilities, in our review. We notified the developer of them a week ago.

Lack of Protection Against Direct Access to Files

Three of four of the plugin’s .php files with code in them, lack a check 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.

Unwarranted Request to Third-Party Website

On the settings page of the plugin the plugin loads two hidden images from a third-party website, https://www.paypalobjects.com/en_US/i/btn/btn_paynow_LG.gif and https://www.paypalobjects.com/en_US/i/scr/pixel.gif, as part of a PayPal form. It doesn’t look like those actually need to be included in the form to make it work and therefore could be removed.

29 Jun

WordPress Plugin Security Review: Google XML Sitemaps

For our twelfth security review of a plugin based on the voting of our customers, we reviewed the plugin Google XML Sitemaps.

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.8 of Google XML Sitemaps. 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
  • Insecure and unwarranted requests to third-party websites

Results

We found several issues, though nothing major, during the review. We notified the developer of the results on June 13, but we have yet to hear back from them and the plugin hasn’t been updated since then.

Before getting into the result we should note that a widely repeated claim that there is a reflected cross-site scripting (XSS) vulnerability in the current version of the plugin is not really true. We were contacted by the person behind the claim back at the beginning March (they also mentioned another claimed vulnerability). After looking into it, we were unable to see how it could be exploited and responded to them asking if they were able to. We never received any response to our query, despite our response coming only 8 hours after they contacted us. The WPScan Vulnerability Database, which usually doesn’t bother to verify vulnerabilities, placed the claim in to their database and from there it has gotten repeated by other providers (usually without disclosing that they are sourcing their information from someone else that hasn’t actual verified the vulnerability). This issue would probably be accurately described as a potential vulnerability and more explanation of why that is can be found here. Several days after it was added to the WPScan Vulnerability Database we started seeing the claim being spread further and we notified the developer of what was going on and they said they would correct the issue, but that has yet to happen.

Broken CSRF Protection

The plugin’s setting page has a section “Recent Support Topics / News” whose results can be enabled/disabled with a link. The link looks like this:

https://www.pluginvulnerabilities.com/wp-admin/options-general.php?page=google-sitemap-generator%2Fsitemap.php&sm_disable_supportfeed=true&_wpnonce=aaa26e400b

While the URL contains nonce parameter, “_wpnonce”, the underlying code doesn’t check if a nonce is included with a request to enable/disable the results, which leaves it open to cross-site request forgery (CSRF).

Insecure Requests to Developer’s Website

For the first review since we added checking for “Insecure and unwarranted requests to third-party websites” we found a couple of issues. The contents shown as the results in the previously mentioned “Recent Support Topics / News” section of the plugin setting’s page comes from a request to the developer’s website made over HTTP. The setting’s page also includes an iframe showing recent donations that is also loaded over HTTP. The subdomain of the developer’s website where those requests are made to is accessible over HTTPS, making the requests that way would prevent any man in the middle issue with those requests.

Lack of Protection Against Direct Access to Files

Some of 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.

23 May

WordPress Plugin Security Review: WP-SpamShield

For our eleventh security review of a plugin based on the voting of our customers, we reviewed the plugin WP-SpamShield.

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 1.9.10 of WP-SpamShield. 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 no issues with any of the checked items in version 1.9.10 of WP-SpamShield.

Through our monitoring of the WordPress Support Forum for new vulnerabilities in WordPress plugins we did run across something in the plugin that is concerning and is now something that we are looking to possible incorporate some checking for in future reviews.

For a reason that doesn’t seem to be necessary to us the plugin is reporting the WordPress version in use, the address of the WordPress installation, and its IP address to a third-party website without the plugin providing disclosure that this is happening.

The cause of that is that the plugin checks if there are vulnerabilities in the installed version of WordPress by sending a request the wpvulndb.com with the following code:

$wpv		= str_replace( '.', '', WPSS_WP_VERSION );
$url		= 'https://wpvulndb.com/api/v2/wordpresses/'.$wpv;
$inf		= 'https://wpvulndb.com/wordpresses/'.$wpv;
$wps		= 'https://wpvulndb.com/';
$http_args	= array(
	'timeout'		=> 10,
	'decompress'	=> FALSE,
	'httpversion'	=> '1.1',
);
$resp		= wp_remote_get( $url, $http_args );

Why that is in an anti-spam plugin is something we don’t understand.

While we have no reason to believe the data is being misused, but for a WordPress installation that isn’t meant to access to the public it has the possibility to expose information that isn’t meant to be known outsiders.

Other requests to third-party websites could be off more concern, say if the plugins was loading a JavaScript file from another website. If you have any thoughts on adding a check for requests like this (or some other idea of something we could add to the reviews) leave a comment below or get in touch with us.

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.

01 May

WordPress Plugin Security Review: Really Simple SSL

For our tenth security review of a plugin based on the voting of our customers, we reviewed the plugin Really Simple SSL.

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 2.5.11  of Really Simple SSL. 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 no issues with any of the checked items in version 2.5.11 of Really Simple SSL.

24 Apr

WordPress Plugin Security Review: BackUpWordPress

For our seventh security review of a plugin based on the voting of our customers, we reviewed the plugin BackUpWordPress.

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 3.6.3.1 of BackUpWordPress. 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

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. In the files we looked over we only found one minor issue, one of the files causes a full path disclosure vulnerability. That provides the full path to web sites’s location on the server’s filesystem. On its own that can’t be used to do anything, but it could be combined with vulnerability that requires knowing that information or in the case of cPanel based websites it would provide an attacker with the username for cPanel.

Unlike most full path disclosure vulnerabilities in plugins, this one would occur on servers where PHP’s error reporting is not set to show them since the file in question, /vendor/ifsnop/mysqldump-php/tests/test.php, enables all error reporting (which would override the normal setting for that):

error_reporting(E_ALL);

What we also noticed about this is that the file is a testing file for a third party library, which didn’t look to be needed to be included with the plugin. It was in one of two test directories included with third party libraries that come with the plugin.

When we contacted the plugin’s maker about this we were told that the developers had been touched based with about it and “they plan to get this taken care of right away”. Several days after that an issue was started on the GitHub page for the plugin and then was closed and redacted a couple days after that. A month later the plugin hasn’t received any updates, so the issue remains in it for now.

17 Apr

WordPress Plugin Security Review: Google Analytics for WordPress by MonsterInsights

For our ninth security review of a plugin based on the voting of our customers, we reviewed the plugin Google Analytics for WordPress by MonsterInsights.

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 6.1.7 of Google Analytics for WordPress by MonsterInsights. 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

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. In the files we looked over we didn’t see anything that could be exploited due to that.