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'] ) && 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.