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.

22 Feb

WordPress Plugin Security Review: Democracy Poll

For our fouth security review of a plugin based on the voting of our customers, we reviewed the plugin Democracy Poll.

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 5.3.6 of Democracy Poll. 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 in the plugin, though none of them likely to lead to a website being hacked. We notified the developer of our findings on February 8, but we have yet to here back from them and no changes have been made to the plugin since then.

Lack of CSRF Protection for Admin Actions

In a number of places in admin section of the plugin it lacks protection against cross-site request forgery (CSRF).

That includes the ability to make various status changes to polls; specifically closing polls, opening polls, activating polls, deactivating polls, and deleting polls.

On the plugin’s admin page when saving the contents of the Settings, Theme Settings, and Texts Changes there is also no protection against CSRF.

CSRF/XSS for Poll Text

The lack of CSRF protection on the Texts Changes can be used to cause cross-site scripting (XSS) because the settings on that page are not sanitized when saved and not escaped when displayed again on that page and on the frontend pages that contain poll text configured there.

Lack of Protection Against Direct Access to Files

In numerous files .php files that look like they are also 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.

23 Jan

WordPress Plugin Security Review: Crayon Syntax Highlighter

For our third security review of a plugin based on the voting of our customers, we reviewed the plugin Crayon Syntax Highlighter.

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.8.4 of Crayon Syntax Highlighter. 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 two issues, neither of them likely to lead to a website being exploited.

The plugin hasn’t been updated for 9 months and listed as only being compatible up to WordPress 4.2.0, so we didn’t try to notify the developer of the issues ahead of the release of the results of the review (if they were more serious then we likely would have), but we will open a new issue on the GitHub project for the plugin mentioning them.

Lack of CSRF Protection in AJAX Accessible Functions

The plugin makes a series of function accessible to those that can manage_options capability, which would normally be only Administrator-level users:

if (current_user_can('manage_options')) {
    add_action('wp_ajax_crayon-ajax', 'CrayonWP::ajax');
    add_action('wp_ajax_crayon-theme-editor', 'CrayonThemeEditorWP::content');
    add_action('wp_ajax_crayon-theme-editor-save', 'CrayonThemeEditorWP::save');
    add_action('wp_ajax_crayon-theme-editor-delete', 'CrayonThemeEditorWP::delete');
    add_action('wp_ajax_crayon-theme-editor-duplicate', 'CrayonThemeEditorWP::duplicate');
    add_action('wp_ajax_crayon-theme-editor-submit', 'CrayonThemeEditorWP::submit');
    add_action('wp_ajax_crayon-show-posts', 'CrayonSettingsWP::show_posts');
    add_action('wp_ajax_crayon-show-langs', 'CrayonSettingsWP::show_langs');
    add_action('wp_ajax_crayon-show-preview', 'CrayonSettingsWP::show_preview');
}

Those functions lack protection against cross-site request forgery (CSRF), which prevents an attacker from being able to cause someone else to take an action they did not intend to if they can get them to access a URL they control.

The functions there that look to have potential for security issues involve the plugin’s theme editor. In looking over the functions we couldn’t find directly exploitable issues, but it is possible through that to place arbitrary PHP code in a file on the website. The file will have a .css extension, so it can’t be executed directly, but if combined with a local file inclusion (LFI) vulnerability, it could be executed. That combination of events is very unlikely to occur.

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.

17 Jan

WordPress Plugin Security Review: WangGuard

Last week we did the first release of results from our security reviews of WordPress plugins selected by our customers. That actually involved the second the plugin we reviewed though, as we were waiting to hear back from the developer of the first plugin we reviewed, WangGuard, after notifying them of the security issues we found. It has now been two weeks without a response from the developer or fixes for the vulnerabilities (it looks like the plugin might not be supported anymore), so we will disclose the results now. One of the issues found is something that will usually cause a plugin to be removed the Plugin Directory, so the plugin will likely be removed from that shortly.

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.7.2 of WangGuard. 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 a number of security issues during the testing, though none that would likely be exploited by a hacker on the average website.

Reflected Cross-Site Scripting (XSS) Vulnerability

In the file /wangguard-user-info.php the value of $_GET[“userIP”] is printed without any sanitization or escaping, leading to reflective cross-site scripting (XSS). This impact of this issue is limited due to the fact that we don’t see much interest in hackers targeting this type of vulnerability, probably due to the combination that requires getting someone else to visit a URL you specify and the fact that all of the major web browsers other than Firefox have XSS filtering, which limits the ability for this type of vulnerability to be exploited.

Cross-site Request Forgery (CSRF) Vulnerabilities

We found that a number of activities that can be taken by an Administrator in the plugin are lacking protection against cross-site request forgery (CSRF). Specifically we found that changing the plugins settings on the WangGuard settings tab of /wp-admin/admin.php?page=wangguard_conf, cron job addition/deletion on /wp-admin/admin.php?page=wangguard_cronjobs, sign up moderation on /wp-admin/admin.php?page=wangguard_signupmod, deleting questions on the Security questions tab of /wp-admin/admin.php?page=wangguard_conf. The function wangguard_ajax_callback() also lacks CSRF protection.

To exploit this type of vulnerability you would need to get a logged in Administrator-level user to visit a URL or page you control, which like the last issue, means that isn’t something we see hackers trying to exploit. In this case we didn’t find any serious issue that could be done with the actions that lack CSRF protection.

Lack of Protection Against Direct Access to Files

In some files, including /wangguard-allow-signup-splogger-detected.php and /wangguard-block-login-moderation.php, the plugin has code at the beginning of the file to restrict direct access to the files. Lots of other .php files that look like they are also not intended to be accessed directly are lacking that protection. In the files we looked over we didn’t see anything that could exploited due to that.

Potential PHP Objection Due To Lack of Secure Connection

In the files /wangguard-addons.php and /wangguard-compatible-plugins.php the unserialize() function is run on what is returned from requests to http://api.wordpress.org. That has the potential to permit PHP object injection in the event of a man in the middle attack between the server and that domain. That isn’t a likely occurrence, but it could be made more secure by doing the request over HTTPS instead of HTTP. That could also be done with requests sent to rest.wangguard.com in the plugin.