Earlier this week we discussed an incorrect belief that WordPress plugins that are monetized will have any discovered security issues quickly fixed, which led to the suggestion that you should only use monetized plugins. That is far from the only time we have seen advice on choosing plugins to use with an emphasis on security that doesn’t hold up to scrutiny. Another one out there is that popular plugins are somehow more secure. The reality is that we haven’t seen any evidence presented that would back up there is a correlation between popularity and security. About the closest we can think of is that it does appear that people looking for vulnerabilities for non-malicious purposes (whether they be security researchers or security companies interested in publicity) are more likely to look at more popular plugins. That seems to be at least partly due to the fact that security journalist are more likely to cover very minor vulnerabilities that have been fixed in popular plugins than unfixed vulnerabilities that are being exploited in less popular plugins, despite the latter being much more important to cover.

That brings us to a very popular plugin we recently took a look into after a vulnerability was vaguely disclosed in it. The plugin Duplicate Page has 300,000+ active installations according to wordpress.org. That plugin allows duplicating pages and posts. Recently the security scanner service Detectify disclosed that the plugin has or had contained an “Authenticated XSS” vulnerability. As we have done with other vulnerabilities they have been vaguely disclosing, but usually not bothering to notify the developer of, we went to try to determine what the issue was and then notify the developer. Once we started looking into this we found five vulnerabilities in the plugin due to multiple security failures, most of which involve failing to do security basics.

In looking at the code we first found the value of the GET or POST input “post” is set to the variable “$post_id ” in the file /duplicatepage.php without being validated or sanitized:

93

$post_id = (isset($_GET['post']) ? $_GET['post'] : $_POST['post']);

Later in the file the value of the variable is output with being escaped:

169

wp_die('Error! Post creation failed, could not find original post: ' . $post_id);

That is a reflected cross-site scripting (XSS) vulnerability and appears to be what Detectify was referring to as it occurs it can be exploited when logged in to WordPress.

A basic rule of security, put a number of different ways, is to not trust user input, but that hasn’t been applied in this plugin based on that.

The value of the variable is also used in the following SQL statement:

143

$post_meta_infos = $wpdb->get_results("SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id=$post_id");

That could lead to SQL injection, which involves additional code running in database query that comes from user input. SQL statements that involve user input should be parametrized to prevent that occurring, which hadn’t been done with this code. Since the value of $post_id should an integer limiting its value to that would have also prevented that as well. That SQL injection vulnerability is exploitable directly by anyone logged in to WordPress and it can also be exploited through the next security failure.

When making a request to duplicate a post or page the URL looks like this:

/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1

What is missing from that is a nonce, which is a unique value used to prevent cross-site request forgery (CSRF). CSRF allows an attacker to cause someone that is allowed to take an action to take it when they are not intending to. In this case getting someone logged in to WordPress to click a link to a URL like that would cause a duplication to occur. That doesn’t really seem like a major issue here since the duplicate is saved as a draft. It could be used combined with the SQL injection vulnerability, though the usefulness of that is limited as well.

One of the things that we bring to the table that there probably isn’t another company comes close to with when it comes to vulnerabilities in WordPress, is a store house of knowledge from reviewing well over a thousand vulnerabilities. So when it came to this plugin we had previously looked at the details of a CSRF vulnerability in very similar plugin, Duplicate Post, which has 2+ million active installs. That led us to noticing the final issue with this plugin.

The plugin allows anyone logged in to WordPress to duplicate any post or page. For publicly viewable content that doesn’t really matter, but it could allow a lower level user without access to a password protected post to duplicate it and then view the contents of the post. That could be prevented by checking if a user is allowed to edit the post or page before doing the duplication.

We notified the developer of all but the last issue on October 4 through the contact form on their website. We then sent an email to the email address listed on the plugin’s page on wordpress.org that included all of the issues a week ago. We have yet to receive any response and a new version of the plugin has not been released.

Development Standards

The developer of the plugin, Webdesi9, presents their capabilities with WordPress plugins differently than the security of this plugin would seem to indicate.

They claim to “follow best quality standards”, which seems to not be the case:

Conferring you with fully functional plugins, our WordPress plugin development follow best quality standards. Get powerful and versatile WordPress plugins developed at Webdesi9.

They also claim to have “expert” WordPress plugin developers, which if true, doesn’t say good things about the handling of security in WordPress plugins in general:

Our experienced and expert set of WordPress Plugin developers provide power packed features and custom plug-ins to augment the performance and productivity of your website.

While the vulnerabilities in Duplicate Page have a limited impact, in another of the developer’s plugins the poor security was more serious. For about the first ten months that their plugin, WP File Manager existed, it would have allowed an attacker to view arbitrary files on a website and also allowed arbitrary files to be uploaded. Those are two of the top types of vulnerabilities in terms of exploit attempts (the vulnerabilities in Duplicate Page are unlikely to be exploited on the average website). When a security change was made that fixed those (but didn’t properly secure things) the developer didn’t change the version for two months, leading to probably 10s of thousands of websites to remain vulnerable. We contacted the developer shortly after the security fix was made to let them know about the incomplete fix and the lack of a version number bump, but we received no response. When the version number was changed you wouldn’t have known there even was security update based on the changelog:

• fix some Bug in 1.6 – Minor Update
• System Properties Menu – Added(New)

Making Sure the Plugins You are Using Are Secure

While there are a lot of suggestions out there on how to determine if plugins are secure, we can only think of a couple that might be useful. The first is to look at how the developer has handled any previously disclosed vulnerabilities, which could give you some indication of how they handle security of the plugin. Beyond that, the only way to directly check on the security of the plugin is to have a security review done.

For both of this developer’s plugins a good review should have caught most of the issues in them.

With our service you can suggest/vote for plugins to receive a security review from us, so that any issues like in these plugin can be found and fixed or if they don’t get fixed, you are aware that the developer isn’t properly handling security. You can also order a review of plugin separately from the service.