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.