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.

31 Mar

WordPress Plugin Security Review: Easy Digital Downloads

For our fifth security review of a plugin based on the voting of our customers, we reviewed the plugin Easy Digital Downloads.

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.7.4 of Easy Digital Downloads. 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 several issues detailed below.

We notified the developer of the issues on February 27. The developer responded, but didn’t seem to have the best grasp of their own code when it came to one of the issues. Subsequent to that, two new versions of the plugin have been released, but no changes have been made related to the issues so far.

Information Disclosure Vulnerability

The function edd_ajax_get_download_title in the file /includes/ajax-functions.php is accessible via AJAX by those logged in and out, despite stating that it is “used only in WordPress Admin”. The function’s code will return the title for any post (not just downloads), so there is the possibility that the title of unpublished posts, private posts, or other private content stored in a post could be exposed through that. It looks like that function isn’t actually used anymore, at least we couldn’t find where it was used in the plugin.

Lack of web.config File

The plugin restricts access to files in the directory where uploaded files that are used by the plugin are stored, /wp-content/uploads/edd/, using a .htaccess file. WordPress is supported officially supported on the IIS web server, so generating a web.config file to provide the same functionality as the .htaccess file created on Apache servers by the plugin, could provide additional security.

Lack of Protection Against Direct Access to Files

While many of the plugin’s .php files have code at the beginning of the files to restrict direct access to them, others do not. For example, the files in the /templates/ directory do not. We didn’t see anything that could be exploited in the files without the restriction in place.

20 Mar

WordPress Plugin Security Review: Cloudflare

For our sixth security review of a plugin based on the voting of our customers (we are still waiting to release the results of the fifth until after the developer has a chance to fix the most serious issue found), we reviewed the plugin Cloudflare.

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.2.0 of Cloudflare. 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.