20 Oct

Just Because a WordPress Plugin is Popular, It Doesn’t Mean It is Secure

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.

20 Oct

Authenticated Information Disclosure Vulnerability in Duplicate Page

We recently went to a take a look at the details of a reflected cross-site scripting (XSS) vulnerability that had been disclosed in the plugin Duplicate Page we noticed that it also had a cross-site request forgery (CSRF) vulnerability. After that we remember that a similar plugin Duplicate Post had previously had a vulnerability that allowed lower level users to get access to password protected posts by duplicating them that was in part due to a lack of protection against CSRF and we then went to check if that was issue with that plugin as well. We found that it was possible.

With the other plugin its functionality was only intended to be used by Editor and Administrator-level users, while with this one the plugin ads links to do the duplication as long as the user has the “edit_posts” capability (in the file /duplicatepage.php):

178
179
180
if (current_user_can('edit_posts')) {
$actions['duplicate'] = '<a title="Duplicate this as '.$post_status.'" href="admin.php?action=dt_duplicate_post_as_draft&post=' . $post->ID . '" rel="permalink">'.__( "Duplicate This", "duplicate_page" ).'</a>';
}

That normally is available to contributor-level and above users.

The duplication is handled by the function dt_duplicate_post_as_draft(), which is accessible to anyone logged in because it is registered as an admin_action:

23
add_action( 'admin_action_dt_duplicate_post_as_draft', array(&$this,'dt_duplicate_post_as_draft') );

That function doesn’t perform any checks as to who is making the request, so anyone that is logged in can duplicate any post. Normally only contributor-level and above could then view the resulting post since it is stored as a draft by default. Through that they could gain access to the contents of posts they would normally not have access to, including password protected posts.

We notified the developer of other security issues in the plugin through their website on October 4 and planned to mention this once they responded, but they didn’t respond. We then notified them of this through the email address listed on the plugin’s page on wordpress.org on October 13, as well as mentioning the previous issues again. We have yet to hear back from them and a new version has not been released. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

Log in to WordPress as a contributor-level user and visiting the following URL, with the value of “[path to WordPress]” replaced with the location of WordPress and  “[post ID]” replaced with the value of a password protected post on the website:

http://[path to WordPress]/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=[post ID]

You will now be able to view the contents of the post without having to enter a password.

Timeline

  • October 13, 2017 – Developer notified.
20 Oct

Cross-Site Request Forgery (CSRF) Vulnerability in Duplicate Page

While looking into the details of a reflected cross-site scripting (XSS) vulnerability in the plugin Duplicate Page we noticed that there was no protection against cross-site request forgery (CSRF) when using the plugin’s functionality, duplicating a post or page.

As of version 2.3 the URLs for the duplication looks like this:

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

If there was protection against CSRF there would be a nonce included in that.

We notified the developer of the issue through their website on October 4 and through the email address listed on the plugin’s page on wordpress.org on October 13. We have yet to hear back from them and a new version has not been released. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

The following proof of concept will duplicate the POST with ID number 1, when logged in to WordPress.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1

Timeline

  • October 4, 2017 – Developer notified.
  • October 13, 2017 – Developer notified.
20 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Duplicate Page

Recently the security scanner service Detectify seems to have disclosed a number of unfixed reflected cross-site scripting (XSS) vulnerabilities in WordPress plugins that the developers may not have been notified of. We are still in the process of going through those, but so far we found that not only had some of the developers not been notified, but also Detectify seems to have claimed that ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.