13 Jul

Image Upload Capability in WordPress Plugin Being Abused

The security industry has more than its fair share of snake oil and hucksters, which seems like it can be explained in part due to the fact that people that don’t know and or care about security can make claims that those more knowledgeable would never make.  For example, somebody that has a basic understanding of security wouldn’t claim their WordPress security plugin “stops you from getting hacked” because a WordPress plugin would not have any chance of stopping certain types of attacks (yet somehow the most popular plugin makes this claim). Not only is security extremely complicated, but things are frequently changing, so you need to keep adjusting as new threats come about and existing ones change. Along those lines we thought it important to share something we ran across yesterday about the abuse of a popular plugin’s intended functionality.

One of the ways we keep track of plugin vulnerabilities out there is by monitoring the WordPress Support Forum for threads that might be relevant. Through that, this week have added three newly disclosed vulnerabilities that exist in the most recent version of their respective plugins, including one in a plugin with 1+ million active installs, to our data set,. Those are vulnerabilities you won’t find in any other source of WordPress plugin vulnerabilities data due to no one else doing the kind of extensive monitoring we do. Through that monitoring we also came across a report of abuse of the image upload capability in the plugin WP Job Manager.

That relates to a post we wrote just about a month ago looking in to a claim that a vulnerability in the plugin had been fixed that had allowed website defacements due to those not logged in to WordPress being able to upload images through the plugin’s AJAX functionally. The claim didn’t really make a lot of sense for two reasons. First we didn’t understand how uploading an image could allow a website to be defaced in normal circumstances. But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

The thread we ran across indicates the abuse of that image upload capability, but not for website defacement, at least in any way we have heard the term used before. Here is how an impacted user explained it in a series of posts:

We have seven websites running WP JOB MANAGER plugin and all have been infected and one even blocked by the domain registrar!!

Please, we need an urgent solution to this.

How were the websites “infected”:

In all cases it was either gif or jpg.

This triggered some strange security warning from some security company and one domain even got blocked based on this (until I removed the file).

Also my host was warned.

So what were the images being used for:

The uploaded file is a phishing/spam use and our site gets the responsibility.

Very dangerous! I hope there is a solution for this.

Or a way to turn off image upload? Not like many employers are even using it.

The plugin is developed by Automattic, the company closely associated with WordPress, and the response from one of the developers doesn’t seem to reassuring about their ability to handle complex issues:

@gstar@rogier1988@etheos sorry for the slow response here. Yes, there was a vulnerability reported and we updated the plugin immediately after some discussion. The update was release 29 days ago. Here is the changelog with a link to the issue:

https://github.com/Automattic/WP-Job-Manager/blob/master/changelog.txt

I added an announcement and sticky post about this on the forum which can be found here: https://wordpress.org/support/topic/wp-job-manager-1-26-2-released/

Can you please check the version of WPJM you are running and confirm to us which version you are using. If you are using 1.26.2 and there is a new vulnerability we need to get that sorted out.

As we mentioned before, the change made in that version didn’t seem to resolve an issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin. This seems like a good time to remind people that we are always available to provide free help to developers dealing with security issues in their plugins, seeing as if we were contacted about the issue we would have pointed this out at the time.

The problem with this type of issue is that the activity of uploading image is intended, so ideally you would try to stop it from being abused without hindering its intended use. In the case of this plugin, one plausible solution that sounds like it could limit the abuse is to resize large images to the smaller size they are actually shown by the plugin, but for other plugins it might be more difficult.

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.

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.

16 Jun

False Vulnerability Report: Cross Site Scripting Vulnerability in WP Job Manager

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.

Recently several security related changes were made to the plugin WP Job Manager, while reviewing the changes we didn’t see anything that looked like it would relate to something that would be classified as a vulnerability and needed to be detailed and added to our data set. The cause for one of the changes clarifies that there really wasn’t a vulnerability in that case.

A report was released within the last day claiming that a persistent (also referred to as stored) cross-site scripting (XSS) vulnerability had been fixed in version of 1.26.2 of the plugin.

The first instruction in the proof of concept starts to point that this report might be false:

1.From 'Job Listings' menu select 'Add New'
  http://localhost/wordpress/wp-admin/post-new.php?post_type=job_listing

To exploit this you need to be logged in, which if you had to be logged in as an Editor or Administrator level user to access the page wouldn’t be a vulnerability normally since they have the unfiltered_html capability that allows them to do the equivalent of XSS.

We found the page is only accessible to Administrator level users, which beyond the unfiltered_html capability, normally have the ability to do almost anything, so for example, they would normally be able to modify a plugin’s code to remove any security checks.

The second instruction in the proof of concept is:

2.Enter this payload for title of job
  <script>alert('Ehsan Hosseini - Xss Stored')</script>

When adding a job, the page that comes up looks like the page that comes up when editing a post or page:

That gives a visual indication that plugin is likely using standard WordPress functionality for creating jobs, which would also indicate that it is probably using the standard WordPress security handling and therefore properly secured already.

After noticing that, we removed the unfiltered_html capability from Administrators in the install of WordPress we were using to test this out and found that if we tried the proof of concept the JavaScript code seen in instruction 2 was properly sanitized, so the plugin was already properly obeying the WordPress security model.

The change made to plugin related to this was to escape the job title using esc_html() in several locations,  which isn’t necessary, but doesn’t hurt to do.

15 Aug

False Vulnerability Report: WP Job Manager Arbitrary File Upload Vulnerability

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.

Sometimes false reports of vulnerabilities are fairly easy to identify as likely being false without having to dig in to things, when the supposed proof of the vulnerability doesn’t match with what you should see with exploitation of a vulnerability. That was the case with a recent claim of an arbitrary file upload vulnerability in the WP Job Manager plugin. While an arbitrary file upload vulnerability allows any type of file to be uploaded, hence the name, hackers would normally use it to upload .php files. In this case those examples involved uploading .txt files. Also missing from the advisory was any information on the underlying code handling uploads, which if shown would have shown that the report was false.

The vulnerability was supposed to exist in the ability to upload a logo when creating a job posting through the plugin. If you try to upload a .php file through that you will get back error message that says:

Invalid file type. Accepted types: jpg|jpeg|gif|png

This is due to the JavaScript code that restricts the type of files that can be uploaded to the ones listing defined in the data-file_types attribute of the input (the JavaScript code that causes this is located in the file /assets/js/ajax-file-upload.min.js):

<input type="file" class="input-text wp-job-manager-file-upload" data-file_types="jpg|jpeg|gif|png"  name="company_logo" id="company_logo" placeholder="" />

So you are only intended to be able to upload jpg, jpeg, gif, or png files through that. Since the checking is done in JavaScript, which runs on the client side, an attacker could just disable that code, so it doesn’t provide actual protection.

With that code disabled, uploading a .php file will cause the following message to be returned instead:

Uploaded files need to be one of the following file types: jpg|jpeg|jpe, gif, png, bmp, tiff|tif, ico, asf|asx, wmv, wmx, wm, avi, divx, flv, mov|qt, mpeg|mpg|mpe, mp4|m4v, ogv, webm, mkv, 3gp|3gpp, 3g2|3gp2, txt|asc|c|cc|h|srt, csv, tsv, ics, rtx, css, htm|html, vtt, dfxp, mp3|m4a|m4b, ra|ram, wav, ogg|oga, mid|midi, wma, wax, mka, rtf, js, pdf, class, tar, zip, gz|gzip, rar, 7z, psd, xcf, doc, pot|pps|ppt, wri, xla|xls|xlt|xlw, mdb, mpp, docx, docm, dotx, dotm, xlsx, xlsm, xlsb, xltx, xltm, xlam, pptx, pptm, ppsx, ppsm, potx, potm, ppam, sldx, sldm, onetoc|onetoc2|onetmp|onepkg, oxps, xps, odt, odp, ods, odg, odc, odb, odf, wp|wpd, key, numbers, pages

That message comes from the job_manager_upload_file() function in the file /wp-job-manager-functions.php. The message is due to a check to see if the file that is submitted for upload has an allowed mime type:

690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
function job_manager_upload_file( $file, $args = array() ) {
	global $job_manager_upload, $job_manager_uploading_file;
 
	include_once( ABSPATH . 'wp-admin/includes/file.php' );
	include_once( ABSPATH . 'wp-admin/includes/media.php' );
 
	$args = wp_parse_args( $args, array(
		'file_key'           =&gt; '',
		'file_label'         =&gt; '',
		'allowed_mime_types' =&gt; get_allowed_mime_types()
	) );
 
	$job_manager_upload         = true;
	$job_manager_uploading_file = $args['file_key'];
	$uploaded_file              = new stdClass();
 
	if ( ! in_array( $file['type'], $args['allowed_mime_types'] ) ) {
		if ( $args['file_label'] ) {
			return new WP_Error( 'upload', sprintf( __( '"%s" (filetype %s) needs to be one of the following file types: %s', 'wp-job-manager' ), $args['file_label'], $file['type'], implode( ', ', array_keys( $args['allowed_mime_types'] ) ) ) );
		} else {
			return new WP_Error( 'upload', sprintf( __( 'Uploaded files need to be one of the following file types: %s', 'wp-job-manager' ), implode( ', ', array_keys( $args['allowed_mime_types'] ) ) ) );

The allowed mime types come from the WordPress function get_allowed_mime_types(), which is located in the file /wp-include/functions.php. That in turn gathers a list of mime types from the function wp_get_mime_type() in the same file, which is where the list of file types show in the message that starts “Uploaded files need to be one of the following file types:” comes from.

Since the types of files that can be upload is limited the arbitrary file upload vulnerability does not exist. That still leaves the issue that someone can upload a lot more types of files than are actually intended for the logo, so depending on what else is intended to uploadable through plugin, the developer may want to place additional restrictions in the PHP portion of the code on what can be uploaded.