26 Jun

Information Disclosure Vulnerability in UpiCRM

When it comes to areas where there is lot of room for better security in WordPress plugins, two that come to mind are the security of plugins that handle business related task and the security of personal information stored in plugins. Those came together in a vulnerability we happened to run run across in the plugin UpiCRM while looking into the possibility of a different vulnerability.

The plugin features the ability export lead information (names, email addresses, phone numbers, etc) to a file. When that occurs the file is saved to the directory /wp-content/uploads/upicrm/ with the name leads.csv or leads.xlsx depending on the format requested. Access to files in the directory is not restricted, so anyone can later request the files at that location and will be served them if an export was previously done that generated them.

We contacted the developer of the plugin about the issue a week ago, but we have not heard back from them and the vulnerability has yet to be fixed.

Proof of Concept

  1. Visit the Exports page and click “Export all leads data to Excel”.
  2. Log out of WordPress.
  3. Now when requesting the URL http://[path to WordPress]/wp-content/uploads/upicrm/leads.xlsx (make sure to replace “[path to WordPress]” with the location of WordPress) you will be served the export.

Timeline

  • June 19, 2017 – Developer notified.
08 Jun

Information Disclosure Vulnerability in Save Contact Form 7

While looking into a recent security fix for a SQL injection vulnerability in version 2.0 of the plugin Save Contact Form 7 we noticed a much larger issue in the relevant code, all the contact form submissions saved by the plugin are publicly accessible.

Normally the submissions saved by the plugin are viewed through the plugin’s admin page which is only accessible to those logged in to WordPress with as a user with the “manage_options” capability, which normally only Administrator level users have. The submissions shown to those users are served through an AJAX request, but the handling of AJAX request is configured to allow those not even logged in to access it (in the file /save-contact-form-7.php):

472
473
add_action('wp_ajax_nimble_ajax_datatable', 'nimble_populate_datatable'); // ajax for logged in users
add_action('wp_ajax_nopriv_nimble_ajax_datatable', 'nimble_populate_datatable'); // ajax for not logged in users

The comment in the second line that it is “for not logged in users” is not something we added, so the developer should have been aware that they were making the function available to those not logged in.

The requests causes the function nimble_populate_datatable(), which is located in the same file, to execute. That function doesn’t check to see if the request is coming from a user with “manage_options” capability, so anyone can make a request to it and view the submissions of a specified contact form.

The contact form whose results will be shown is specified by the plugin’s ID number for the contact form, which is set a 1 for the first contact form with a saved submission and subsequent integers for additional contact forms. So someone could easily enumerate through all of the contact form IDs to view all results.

We contacted the developer about the vulnerability over a month ago but have not heard back from them and the vulnerability has not been fixed.

Proof of Concept

The following proof of concept will cause all the contact form submissions for the first contact form that the plugin saved submissions to be shown.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="nimble_ajax_datatable" />
<input type="hidden" name="id" value="1" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 3, 2017 – Developer notified.
31 Mar

Information Disclosure Vulnerability in Easy Digital Downloads

One of the features of our service is that our customers get to suggest and vote for plugins to get a security review done by us. Last month we did a review of the plugin Easy Digital Downloads and one of the issues we found through that was an 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 is intended to return the title of the plugin’s downloads, but as can be seen below it lacks any restriction as to what it will return the tile of:

396
397
398
399
400
401
402
403
404
405
406
function edd_ajax_get_download_title() {
	if ( isset( $_POST['download_id'] ) ) {
		$title = get_the_title( $_POST['download_id'] );
		if ( $title ) {
			echo $title;
		} else {
			echo 'fail';
		}
	}
	edd_die();
}

Since the function will return the title of any post (not just downloads), 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.

We notified the developer of the issue on February 27 and they responded, but the issue has not been resolved as of our posting this.

Proof of Concept

The following proof of concept will return the title of the post specified.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="edd_get_download_title" />
<input type="hidden" name="download_id" value="[post ID]" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 27, 2017 – Developer notified.
  • February 27, 2017 – Developer responds.
  • July 25, 2017 – Version 2.8 release, which fixes vulnerability.
19 Jan

Vulnerability Details: Information Disclosure Vulnerability in W3 Total Cache

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in ...


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 free for the first month (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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

02 Jan

Information Disclosure Vulnerability in Pike Firewall

In our testing of WordPress security plugins to see what, if any, protection they provide against the exploitation of actual vulnerabilities in other plugins the results haven’t been good so far. Most of the plugins tested haven’t provided any protection against those vulnerabilities. That hasn’t really surprised us, as much of what these plugins do doesn’t have any impact on what hackers actually try to do. One example is that many of these plugins check if you have change the database prefix to something other than the default “wp_”, but knowing the database prefix is rarely needed for vulnerabilities we see being exploited. If knowing the database prefix was a big deal then the vulnerability we recently found in a security plugin would be a big deal, as the vulnerability exposes that.

While doing a few quick security checks over the plugin Pike Firewall we noticed that it has the capability to log login attempts. We and others have found that capability in plugins has introduced security vulnerabilities into plugins due to improper handling of user input that comes through that. One of things that has been an issue with other plugins is that malicious JavaScript code placed in the HTTP header field X-Forwarded-For will get displayed on the plugin’s pages unsanitized or unescaped leading to cross-site scripting (XSS). In this case we found it caused another issue when tried logging in with it set to malicious code we got this error:

WordPress database error: []
SHOW FULL COLUMNS FROM `wp_pike_firewall_login`

The database prefix is being shown in that error message.

In looking at the underling code the cause of this is (in the file /pikefirewall.php):

2756
2757
2758
2759
if ( !$wpdb->insert($pike_tables['login'], array('username' => $username, 'user_address' =>; $pike_ip, 'user_agent' => $pike_agent, 'type' => $type, 'success' =&gt; $success), array('%s', '%s', '%s'))) {
	$wpdb>show_errors();
	wp_die($wpdb->print_error());
}

You can see that error reporting is enabled and if there is an error it gets printed, which shouldn’t be happening in a non-development environment since as our example shows it is disclosing non-public information.

We contacted the developer about the issue on December 19, but we have not heard back from them and the vulnerability has not been fixed.

Proof of Concept

With login attempt logging turned on, set the X-Forwarded-For HTTP header to

<script>alert(document.cookie);</script>

and attempt to log in to WordPress (the username/password doesn’t matter).

Timeline

  • December 19, 2016 – Developer notified.
11 May

Information Disclosure Vulnerability in Yoast SEO

Recently the security company Wordfence released an advisory for the Yoast SEO plugin for what seems to be a rather minor issue. Logged in users could access several functions of Yoast SEO that they were not normally intended to have access to, including exporting the plugin’s settings. While reviewing that to include in to our service’s data we noticed that the related to this there was also a problem with cross-site request forgery (CSRF) protection in the export function of the plugin.

The fact the plugin now restricts the export function to Administrator level users (by restricting it to user who can manage_options) and there was supposed to be CSRF protection for it would indicate the result of that export should not be available to public. Though in normal circumstances it doesn’t look like sensitive data so the publics access to it seems to not to be a major issue at this point, but that could change, so making sure it is not easily accessible to the public seems like a good idea. Currently that isn’t the case.

When doing an export of the settings this month the file saved at:

/wp-content/uploads/2016/05/settings.zip

Last month it was saved at:

/wp-content/uploads/2016/04/settings.zip

Not only are files in that location normally accessible by the public, it would very easy for someone to request all of the possible file locations by making requests for all of the possible year and month combinations.

We notified the developer about this issue along side the CSRF issue on Friday, yesterday the indicated that it would be a month before they fixed the CSRF issue, but made no mention of this issue, so who knows if they are interested in fixing it. That would be fairly easy to do by simply adding a unique value to the name of the file.

Timeline

  • 5/6/2016 – Developer notified.
  • 5/10/2016 – Response from developer with no reply on this issue.
  • 6/21/2016 – Version 3.3.2 released, which fixes vulnerability.
04 Mar

Information Disclosure Vulnerability in WP Ultimate Exporter

There are certain kind of plugins you would hope that anyone developing one would be very careful when doing so, one of those being a plugin that allows you to export non-public data from WordPress. That unfortunately isn’t always case, as the following vulnerability shows (and another vulnerability we will release the details of on a later date).

WP Ultimate Exporter is a plugin that allows you to export posts, pages, and custom posts as CSV files. While reviewing a report of a SQL injection vulnerability in the plugin we noticed that there was another connected issue, the plugin allows anyone to perform an export operation and get the resulting file. That clearly is not the intent as the plugin’s page in the WordPress admin area is only available to users with the Admin role. Unfortunately none of the code run when the actual request for an export is made actually checks to make sure that the request comes from an admin user.

For a lot of sites this probably wouldn’t be a big deal since all of their pages and post are public. But for those were it isn’t the case this would be a big issue. The plugin even allows you select the type of content you want to export, so for example you could just export the password protected posts:

wp-ultimate-exporter-protected-posts

Proof Of Concept

The following proof of concept page will cause all posts to be exported.

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

<html>
<head>
</head>
<body>
<form method="post" enctype="multipart/form-data" action="http://[path to WordPress]/wp-admin/admin.php?page=wp_ultimate_exporter&step=exportposttype">
 <input type="hidden" value="post" name="export_type_name">
 <input type="hidden" name="post_withdelimiter" value="," >
 <input type="submit" name="proceed_to_exclusion" value="Export">
</form>
</body>
</html>

Timeline

  • 2/29/2016 – Notified Developer
  • 3/4/2016 – Notified WordPress.org Plugin Directory
  • 3/7/2016 – Plugin Removed from WordPress.org Plugin Directory