14 Sep

WordPress Plugin Security Review: Regenerate Thumbnails

For our nineteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Regenerate Thumbnails.

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 tool for doing limited automated security checks of plugins  (now accessible through a WordPress plugin of its own) 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 3.0.2 of Regenerate Thumbnails. 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 the plugin
  • 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
  • Any additional possible issues identified by our Plugin Security Checker

Results

We found one really minor issue.

Lack of Protection Against Direct Access to PHP Files

Two .php file in the plugin are not intended to be directly accessed but do not contain protection against direct access. The files only define classes, so there is nothing exploitable if they are accessed and adding a restriction has limited value.

13 Jul

WordPress Plugin Security Review: Stagehand Events

We were recently hired to do a security review of the WordPress plugin Stagehand Events.

The review was done on version 1.0.5 of Stagehand Events. 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 the plugin
  • 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
  • Any additional possible issues identified by our Plugin Security Checker

Results

We found no issues with any of the checked items in version 1.0.5 of Stagehand Events.

19 Jan

WordPress Plugin Security Review: Simple 301 Redirects

For our nineteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Simple 301 Redirects.

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 tool for doing limited automated security checks of plugins  (now accessible through a WordPress plugin of its own) 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.07 of Simple 301 Redirects. 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

We found one really minor issue.

Lack of Protection Against Direct Access to PHP Files

The only .php file in the plugin is not intended to be directly accessed but does not contain protection against direct access. When the plugin is active the file will run whenever WordPress is loading, so the lack of protection against direct access doesn’t matter. If the plugin is not active then accessing the file will cause its code to run, but it will hit fatal error before anything of importance is run, so there doesn’t look to be any security issue that could be caused by this.

18 Jan

WordPress Plugin Security Review: HTTP Headers

For our eighteenth security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin HTTP Headers.

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 tool for doing limited automated security checks of plugins  (now accessible through a WordPress plugin of its own) 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.8.0 of HTTP Headers. 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

We found several issues during our review.

Admin_init

We recently added a number of new checks to our reviews. One of those is to check any functions that are registered to run during “admin_init”. There are a couple of connected reasons for that. The first being that functions that are set to run then can even run when request is coming from someone that is not logged in, which is something that some of the developers using it seem to not be aware of. Even if that wasn’t true, since they run for anyone logged in, there could still be issues if something was only meant to be accessible to higher level users. The second is that because of those things, functions running then have been the source of vulnerabilities, including a zero-day vulnerability that was exploited in August in a plugin’s code to save its settings.

This plugin registers the function http_headers_admin() to run during admin_init:

813
add_action('admin_init', 'http_headers_admin');

That function first registers quite a few settings, starting with this one:

480
register_setting('http-headers-mtd', 'hh_method');

That is fine. The rest of the code is where there was a problem, as a number of actions can be taken by anyone since the only thing needed to cause them to run is including several URL parameters with a request:

565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
# When method is changed
if (isset($_GET['settings-updated'], $_GET['tab']) && $_GET['settings-updated'] == 'true' && $_GET['tab'] == 'advanced') {
	update_headers_directives();
 
	update_auth_credentials();
	update_auth_directives();
 
	update_content_encoding_directives();
 
	update_expires_directives();
 
	update_cookie_security_directives();
 
	update_timing_directives();
}
 
# When particular header is changed
if (isset($_GET['settings-updated'], $_GET['header'])
	&& $_GET['settings-updated'] == 'true'
	&& get_option('hh_method') == 'htaccess') {
 
	switch ($_GET['header']) {
		case 'www-authenticate':
			update_auth_credentials();
			update_auth_directives();
			break;
		case 'content-encoding':
		case 'vary':
			update_content_encoding_directives();
			break;
		case 'expires':
			update_expires_directives();
			break;
		case 'cookie-security':
			update_cookie_security_directives();
			break;
		case 'timing-allow-origin':
			update_timing_directives();
			break;
		default:
			update_headers_directives();
	}
}

What was interesting about this code is that it didn’t appear to be used.

Server Side Request Forgery (SSRF)

One the things that we have checked for since the first of these reviews is for a lack of protection against cross-site request forgery (CSRF) in the admin portion of plugins. CSRF is a type of vulnerability in which an attacker can cause someone else to take an action they are allowed to, but didn’t intend to. In looking into instances where the protection is missing or broken we sometimes run into larger issues. In the case of the plugin we found the “Inspect headers” tool on the plugin’s admin page not only lacked protection against CSRF, but also was accessible to anyone by making a request directly to the file, /views/ajax.php, the results for the tool come from.

With that tool you can make a request to other websites through the server, the only limit that you can only make request to URLs that begin http:// or https:// (so you couldn’t say make a request to a FTP address):

10
if (!(isset($_POST['url']) && preg_match('|^https?://|', $_POST['url'])))

That is referred to as server side request forgery (SSRF) vulnerability. Part of the risk of that is that it would allow an attacker to make requests to URLs that are accessible to the server, but not directly to the attacker, say another system that the server connects locally.

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.  Beyond the SSRF issue, we didn’t see anything that could be exploited in the files without the restriction in place.

Security Issues Now Mostly Resolved

While reviewing plugins is usually fairly easy if you have experience with what is being checked on, getting the developer to properly fix the issue isn’t necessarily. In this case it took a couple of releases for the issues to be mostly resolved.

For the issue involving admin_init, in version 1.9.2 the relevant code was moved to a new function http_headers_option() that runs when the actions “added_option” and “updated_option” occur. In version 1.9.4 protection against CSRF was added for that.

For the SSRF issue the code in file /views/ajax.php was removed in version 1.9.4. In version 1.9.2 the code had been copied to a new /views/ajax-inspect.php, which can be accessed through WordPress’ AJAX functionality. In version 1.9.2 when accessing it through AJAX there was protection against CSRF added and in version 1.9.4 a capabilities check was added. The file /views/ajax-inspect.php can be accessed directly for some reason, but that file includes a file /includes/config.inc.php, which first runs code that is intended to block direct access to the file and has the additional impact of causing /views/ajax-inspect.php to stop running before getting to anything of importance.

With the exception of the file just mentioned related to the SSRF vulnerability and the related /includes/http.class.php, the plugin’s files received protection against direct access in version 1.9.2.

Proof of Concept for SSRF

The following proof concept will make a request to the homepage of our website.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/http-headers/views/ajax.php" method="POST">
<input type="hidden" name="do" value="inspect" />
<input type="hidden" name="url" value="https://www.pluginvulnerabilities.com" />
<input type="submit" value="Submit" />
</form>
</body>
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.