Blog | Plugin Vulnerabilities | A service to protect your site against vulnerabilities in WordPress plugins.

23 Jun

Not Really a WordPress Plugin Vulnerability – Week of June 23, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post detailing those issues.

Authenticated Arbitrary File Viewing Vulnerability in Photo Gallery

The title of the report, “Path traversal in Photo Gallery may allow admins to read most files on the filesystem” seems to explain the issue well as only Administrators (or more accurately those with the “manage_options” capability) were able to take advantage of the issue and normally not only could they edit the plugin to remove protection against the issue, but they also could just install another plugin that could do what the issue in this plugin would have allowed.

Reflected Cross-Site Scripting (XSS) in Facebook Members

The claimed reflected cross-site scripting (XSS) vulnerability involves the value of the variable $_SERVER[“REQUEST_URI“]. That value is normally URL encoded by a web browser, so normally outputting it unescaped could not permit XSS. It would probably be more accurate to describe this type of issue as a possible vulnerability.

23 Jun

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Analytics Tracker

_{From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.}

The changelog entry for version 1.1.1 of the plugin Analytics Tracker is “Fixed XSS vulnerability on search event, thanks to Arjan ...

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.

22 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in Product Catalog

We recently have been trying to get an idea of how effective it would be to try to proactively catch some vulnerabilities when changes are made to WordPress plugins that include those vulnerabilities. In doing one of the preliminary checks we immediately came across a reflected cross-site scripting (XSS) vulnerability that exists in the plugin Product Catalog that has existed since its first version was released nearly four years ago.

Contrary the scaremongering we have seen from other web security companies this type of vulnerability isn’t a major concern as we don’t see hackers trying to exploit it on a large scale and all major web browsers other than Firefox have filtering that would need to be evaded to make it work. At the same this type of vulnerability shouldn’t be remaining in a plugin that long as it involves a failure of security at a fairly basic level and in the form it was here, easy to detect.

The vulnerability occurs in the file /html/CatalogueDetails.php on line 44:

<form id="nav-menu-meta" action="admin.php?page=UPCP-options&Action=UPCP_Catalogue_Details&Selected=Catalogue&Catalogue_ID=<?php echo $_GET['Catalogue_ID']; ?>#Catalogues" class="nav-menu-meta" method="post" enctype="multipart/form-data">

The value of GET input “Catalogue_ID” is output without being escaped, which could permit malicious JavaScript on to the page.

We notified the developer of the issue a week ago, we haven’t heard back from them and while the plugins has been updated since then, the vulnerability hasn’t been fixed.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

http://[path to WordPress]/wp-admin/admin.php?page=UPCP-options&Action=UPCP_Catalogue_Details&Selected=Catalogue&Catalogue_ID=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Timeline

June 15, 2017 – Developer notified.

22 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in uCare

We recently have been trying to get an idea of how effective it would be to try to proactively catch some vulnerabilities when changes are made to WordPress plugins that include those vulnerabilities. During that preliminary checking we found that the plugin uCare contains a reflected cross-site scripting (XSS) vulnerability.

The vulnerability is an example of where one of things we check for during our security reviews of WordPress plugins selected by our customers, making sure that code is included to restrict direct access to .php files that are not intended to accessed, can be useful.

When deactivating the plugin and choosing to provide feedback the file /emails/product-feedback.php in included to generate the feedback message. That file can be accessed directly.

When accessed as intended the use of output buffering causes the content output by the file to not be displayed in the web browser. But when accessed directly that doesn’t occur and several post inputs are output without being escaped. As an example, on line 6 the POST input “reason” is output:

<p style="margin-left: 20px"><?php echo $_POST['reason']; ?></p>

That could be used to cause malicious JavaScript code to output on to the page.

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

The following proof of concept will cause any available cookies to be shown in alert box. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/ucare-support-system/emails/product-feedback.php" method="POST">
<input type="hidden" name="reason" value='<script>alert("XSS");</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

June 15, 2017 – Developer notified.

21 Jun

Free Security Reviews for Adopted WordPress Plugins

Through our main business we recently introduced a service to take over and maintain WordPress plugins that have been abandoned by their previous developers. As part of getting the plugin up to snuff when taking it over, we will do a security review of the plugin like the ones we already do as part of this service.

While putting together that service we noticed that there an unofficial system for plugin developers to identify if they are looking for someone to take over the plugin by tagging the plugin adopt-me. That seems like a good way to make sure that plugins can continue to be maintained, so to help that out, we are now offering to do free security reviews of any plugins that have been tagged and then adopted.

To take advantage, just get in touch with us.

19 Jun

Making Changes to Fix Claimed Vulnerabilities in WordPress Plugins Can Have a Negative Impact

Fairly regularly we have found that reports of vulnerabilities in WordPress plugins turn out to be false. That doesn’t always stop developers from making change to fix them as if they really existed (at the same time developers often don’t fix real vulnerabilities). In many cases the change improves the plugin as the change doesn’t fix a vulnerability, but what was allowed to occur before could be consider a bug. In other cases the change duplicates something already occurring in the plugin or WordPress, which increases resource usage slightly, but doesn’t really make a major change. But as what happened recently with WP Job Manager shows it is possible that it could have a negative impact.

As we discussed last week, in the most recent release of the plugin a change was made so that files could no longer be uploaded through the plugin’s AJAX functionality by those not logged in to WordPress. We don’t really understand what the security relevancy of that was supposed to be as those not logged in would normally still be able to upload files through the plugin and according to a report labeling it as a vulnerability, their ability to upload images was supposed to be issue. The report even stated that there were website defacements due to this, which we haven’t been able to come up with an explanation as to how that could be possible since the types of are restricted so you can’t upload directly malicious files.

As thread on the support forum for the plugin shows websites using the plugin were using that removed functionality and that its removal has impacted them doing business:

Since recent running updates for WordPress and plugins. Users are no longer able to upload images via front end form when purchasing listing package.

We’ve also ran into this issue. In fact, it cost us a sale already 🙁

This is a good reminder that reporters of vulnerabilities should be careful and make sure they are in fact reporting something that is a vulnerability (and listen when someone else lets them know that something isn’t a vulnerability). Developers should also be aware that reports of vulnerabilities are not always correct, at the same time they shouldn’t just ignore them as seems too often be the case.

This also seems like a good time remind people that we are also happy to provide free help to any developer of a WordPress plugin that is dealing with a security issue.

19 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Multi Feed Reader

Recently a report was released claiming that a SQL injection vulnerability had been fixed in the latest version of the plugin Multi Feed Reader. In checking into that we found that while the change made in that version improved security, it looked like there may not have actually been a vulnerability in the code before. While looking in to that report we found that the plugin does have a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability on the plugin’s admin page.

The CSRF portion is due to a lack on nonce included in the form submitted to create or edit one of the plugin’s feedcollections.

As example of the XSS portion, when creating a new feedcolleciton the name of it is specified by the POST input “mfr_new_feedcollection_name” and is not sanitized (/mfrsettings.php):

// CREATE action
} elseif ( isset( $_POST[ 'mfr_new_feedcollection_name' ] ) ) {
	$name = $_POST[ 'mfr_new_feedcollection_name' ];
	$existing = FeedCollection::find_one_by_name( $name );
 
	if ( ! $existing ) {
		$fc = new FeedCollection();
		$fc-&gt;name = $name;

The name is output without being escaped in a number of locations including line 393 of the same file:

<input type="text" name="feedcollection[name]" value="<?php echo $current->name ?>" class="large-text">

We notified the developer of the plugin about the vulnerability and asked if they were provided any information on how the claimed SQL injection could have been exploited, we have yet to hear back from them.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/options-general.php?page=multi_feed_reader_handle&tab=edit 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/options-general.php?page=multi_feed_reader_handle" method="POST">
<input type="hidden" name="mfr_new_feedcollection_name" value="'><script>alert(document.cookie);</script>" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

June 12, 2017 – Developer notified.

16 Jun

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WordPress Download Manager

_{From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.}

There are number of reasons we believe it is a good idea for the discoverer of a vulnerability to include ...

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.

16 Jun

Vulnerability Details: Authenticated Open Redirect in WordPress Download Manager

_{From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.}

An advisory was released by the JPCERT/CC and IPA that an open redirect vulnerability had been fixed in version 2.9.51 of ...

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.

16 Jun

How Does Uploading an Image Through WP Job Manager Lead to Website Defacement?

Earlier today we looked at how the report of a vulnerability that was supposed to have been fixed in version 1.26.2 of the plugin WP Job Manager involved something that was not actually a vulnerability. There was a change made related to what was describe in the report, but it just added additional protection over what was already in place.

The other change listed in the changelog of that version seems also to not involve something that would normally be classified as a vulnerability:

Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in. Themes should check with job_manager_user_can_upload_file_via_ajax() if using endpoint in templates. (https://github.com/Automattic/WP-Job-Manager/pull/1020)

Even with that change those that don’t already have an account would by default be able to upload images because of how the plugin works (the types of files that can be uploaded were already restricted as detailed in post we wrote about a previous false report of a vulnerability in the plugin). In one of the comments on the pull to make the change, one of the developers says as much. In relation to question about those not logged in uploading images they responded:

They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

That then brings us to a vulnerability report from the JPCERT/CC and IPA that relates to this. In that they state that prior to 1.26.2 the plugin failed “to restrict access permissions” and that “A remote unauthenticated attacker may upload an image file to the server.”. Considering as we already stated that even with the change those that didn’t already have an account can upload images by default, it’s not clear how if a vulnerability previously existed that it is now resolved.

What seems more problematic is what they list in the addendum section:

As of June 15th 2017, JPCERT/CC has received several incident reports of website defacements exploiting this issue.

We don’t understand how being able to upload an image by itself would lead to a website being defaced. The closest we could think of, without say using it with a local file inclusion (LFI) vulnerability, is that they are considering just being able to upload an arbitrary image and then link to it as a website defacement. But as we mentioned twice before, the change made doesn’t really fix that, so if that issue actually existed then it should still exist.

If this didn’t actually lead to website defacements than passing along an unfounded claim would fairly irresponsible of them.

In you have another thought that might explain the website defacement claim, please leave a comment.