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.
Yes, this does seem like a strange feature of an anti-spam plugin. I think requests like this are something that you should check for in your reviews. Especially in cases like this where the plugin doesn’t really tell the user that it does this, and it doesn’t seem to have anything to do with the plugin’s main purpose.
First, I want to say thanks for doing a security review of our plugin, WP-SpamShield. (I’m the author, and lead developer, Scott Allen.)
I appreciate it greatly when other security professionals evaluate each other’s work and provide feedback. I hope that this will be more common. That’s the beauty of open source. We especially appreciate feedback, because it challenges us to be even better.
We’ve had the plugin through a number of regular security audits throughout its life, as well as our own. It’s always good to see another one confirming its overall health. We also appreciate the critique.
I can address a couple of questions you raised.
“Why that is in an anti-spam plugin is something we don’t understand”, and JD’s comment, “Yes, this does seem like a strange feature of an anti-spam plugin”.
It’s important to remember that anti-spam is a subcategory of security. The same people/groups who are sending spam emails with malware and phishing exploits are the ones behind most website spam (comments, contact forms, registrations, etc). Website spam can even be used for DDoS attacks. We like to stay behind the scenes most of the time, we do extensive anti-spam research. As we uncover data about the groups behind spam attacks, these investigations always have a security element.
Our team has done tech support and security consulting for literally tens of thousands of websites — and specifically WordPress — for over a decade. We often see support requests come in from users with out-of-date WordPress installs. Every time we see one of these, the first thing we tell them is to upgrade WordPress, first and foremost for security. It was a logical extension of this fact to add a simple check to check if their current version of WordPress has any known vulnerabilities, and add an admin notice to remind them to upgrade.
The best anti-spam plugins/apps consider spam, and the best security plugins/apps consider spam as well. As the cybersecurity climate grows, integration will be more and more important.
The code above is based directly on the plugin update API in the WordPress core.
“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.”
On this, we agree about the unnecessary inclusion of the WordPress version and site URL in the outgoing user agent provided in the GET request to wpvulndb.com. WordPress core sets the default outgoing user agent to include this. So that isn’t there due to WP-SpamShield code. However, where we can improve on that is to override the default user agent, and remove the site URL and WP Version number. That’s already been coded and will be in place in the next plugin release.
“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.”
I do hear you on this. Keep in mind that we’re using a secure https connection, which is encrypted, so prying eyes cannot access it. The only site that would have access to it, is the site we’re requesting data from. The WPScan Vulnerability Database is a well-known and trusted resource in the WordPress security community. They don’t record, publish, or abuse the data you’re referencing, so that data is not going to be known or available to outsiders. Even so, after the next version is released, the site URL and WP ver will not be there any longer. The IP address is unavoidable as that is essential to all communication between servers.
“…without the plugin providing disclosure that this is happening.”
We do disclose this on the alerts themselves, but we can do better. We will add better documentation in the next release, as well as an option to disable the security alerts for outdated WordPress versions.
We’ll get a blog post out in the next few days that goes into a bit more detail about all this.
And yes, I definitely think requests to other sites is something you should check for in your security reviews. 🙂
You have gotten yourself convinced that it is logical for your plugin to be checking for vulnerabilities in the installed WordPress version, but nothing you have said here or elsewhere has convinced us or plenty of others. Adding extraneous code to a plugin is a negative when it comes to security since it introduces additional security risks, as can be seen with what has occurred here.
While the WPScan Vulnerability Database is certainly well known, we would worry about anyone in the security community that considers it trusted since just a perusal of some our previous posts mentioning them shows that accuracy isn’t their forte. More problematic is your claim that they don’t “record, publish, or abuse the data you’re referencing, so that data is not going to be known or available to outsiders”, as they don’t appear to even have a privacy policy. They do state they “monitor API access and we will block any IPs, without warning, who we believe are abusing it“, so they must be recording some of that data.
It isn’t reassuring that you are making a point of saying that you are going to remove the WordPress version from the user agent in the next release, considering that you obviously are going to be included in the requests to that website or what you are doing wouldn’t work.