23 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in moreAds SE

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

18 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Event Notifier

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

17 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Stop User Enumeration

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

17 Jan

Reflected Cross-Site Scripting (XSS) Vulnerability in WangGuard

We recently introduced a new feature where we do security reviews of plugins that are selected by our customers. The first review was of WangGuard. The most serious issue we found in that reviews is a reflected cross-site scripting (XSS) vulnerability.

In the file /wangguard-user-info.php the value of the GET input “userIP” is set as the value of the variable $userIP without any sanitization:

11
$userIP = $_GET["userIP"];

That value is then printed without it being escaped:

33
printf( __('User IP: %s <br />'), $userIP);

Proof of Concept

The following proof of concept will cause any available cookies to 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=wangguard_users_info&userIP=<script>alert(document.cookie);</script>

Timeline

  • January 2, 2017 – Developer notified.
  • January 17, 2017 – WordPress.org Plugin Directory notified.
  • January 18, 2017 – Version 1.7.3 released, which fixes vulnerability.
12 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Super Socializer

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

28 Nov

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP Whois Domain

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

12 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP Editor

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

13 Sep

Reflected Cross-Site Scripting (XSS) Vulnerability in Quotes Collection

One of the things we do to provide the best data on vulnerabilities in WordPress plugins is to monitor the wordpress.org Support Forum for threads related to those. Yesterday we ran across a thread asking if the Quotes Collection plugin that had been removed from the Plugin Directory, had a security vulnerability. The people running the Plugin Directory are choosing to keep people in the dark about removed plugins with security vulnerabilities, so people are left wondering like this. If you use our service though many of the vulnerabilities that caused plugins to be removed are listed, you can also use our No Longer in Directory plugin to see if plugins you use have been removed from the Plugin Directory, whether for a security issue or another reason.

After running across the thread we attempted to see if we could find any vulnerabilities in the most recent version of the plugin. While going through our standard checks we found that the plugin has a reflected cross-site scripting (XSS) vulnerability. That isn’t a major threat, since we don’t see much evidence of that type of vulnerability being targeted. One reason for that is that all the major web browsers other than Firefox has XSS filtering, which an attacker would need to figure a way to evade to exploit the vulnerability in the other web browsers.

The reflected cross-site scripting occurs on the page /wp-admin/admin.php?page=quotes-collection, due to the line 221 /inc/class-quotes-collection-admin.php:

<input type="hidden" name="page" value="<?php echo $_REQUEST['page']; ?>" />

Once we saw that it seemed likely that someone else had already identified that issue, as it was the same type issue as several identified by Yorick Koster as part of the Summer of Pwnage. Here is how he described the issue in one of his advisories:

Normally, the page URL parameter is validated by WordPress, which prevents Cross-Site Scripting. However in this case the value of page is obtained from $_REQUEST, not from $_GET. This allows for parameter pollution where the attacker puts a benign page value in the URL and simultaneously submits a malicious page value as POST parameter.

A listing that seems to match the vulnerability is on the list of vulnerabilities discovered during that event, but without any details for us to link to for out data:

Reflected XSS in Quotes plugin (CSRF against admin)

July 2016 | Installs: 20K+ | Yorick Koster | OVE-20160712-0015 | Status: reporting

Proof of Concept

The following proof of concept will cause any available cookies to shown in alert box when logged in to WordPress. 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-admin/admin.php?page=quotes-collection" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>
28 Jul

Protecting You Against Wordfence’s Bad Practices: Reflected Cross-Site Scripting (XSS) Vulnerability in Easy Forms for MailChimp

Wordfence is putting WordPress website at risk by disclosing vulnerabilities in plugins with critical details needed to double check their work missing, in what appears to be an attempt to profit off of these vulnerabilities. We are releasing those details so that others can review the vulnerabilities to try to limit the damage Wordfence’s practice could cause.

Wordfence didn’t provide any description of the vulnerability beyond that it was a reflected cross-site scripting (XSS) vulnerability in Easy Forms for MailChimp version 6.1.2, but it was easy to spot with just that information.

Before we get in to the details of the vulnerability we wanted to highlight something we noticed in their post that seems to speak to them trying present themselves as being more professional than they really are, that also has the (intended?) impact of misleading public as to the severity of the vulnerability discussed.

In the post Wordfence included a severity score for the vulnerability, on a scale of 0-10, with 10 being the highest. The score they gave this vulnerability was “8.8(High)”. The reality is that based on our dealing with lots of hacked website, this vulnerability is very unlikely to be exploited on the average website and all of the major web browsers other than Firefox have long included XSS filtering that would limit the ability to successfully exploit this type of vulnerability if someone were actually to try. If this is high severity vulnerability, it is hard to image what type of vulnerability they would consider even to be of medium severity. Inflating low severity vulnerabilities isn’t helpful to improving the security of WordPress, since if the public doesn’t have a good understanding of what the real risks are they can’t make informed decisions on how to best protect themselves from them.

Strangely Wordfence gave it such a high score despite having mentioned in the paragraph preceding the severity score one of the major limitations of this type of vulnerability:

It is important to note that many modern browsers, such as Chrome and Safari, protect against these types of scripts running on the client side, which diminishes the odds that this vulnerability will be exploited in the wild.

Getting back to the details of the vulnerability, when looking at the changes made in the version that fixed this, 6.1.3, the vulnerability is easy spot.

In the file /admin/partials/menu/options.php in version 6.1.2 the GET input “error_message” is echoed out without escaping it first:

79
<p><?php _e( urldecode( $_GET['error_message'] ) , 'yikes-inc-easy-mailchimp-extender' ); ?></p>

In version 6.1.3 it is now escaped through esc_attr:

79
<p><?php echo esc_attr( urldecode( $_GET['error_message'] ) , 'yikes-inc-easy-mailchimp-extender' ); ?></p>

 

Proof of Concept

The following proof of concept will cause any available cookies to shown in alert box when logged in to WordPress. 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=yikes-inc-easy-mailchimp-settings&error_log_created=false&error_message=<script>alert(document.cookie);</script>
27 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in WP Security Audit Log

When it comes to the poor state web security a big culprit is security companies, who don’t seem to either know or care that that much about security in many cases. So it isn’t wasn’t that surprising that we found a security company would have a WordPress plugin with a security vulnerability due to failure to take a basic security measure the other day, but the situation is a good reminder that services you get from security companies are not also honestly sold.

We recently did a quick security check of security plugins that generate a log of activity in admin area of WordPress. One of the ones we found a security issue with is WP Security Audit Log, which is developed by WP White Security.

The reflected cross-site scripting (XSS) vulnerability we found in the plugin is relatively minor, due to the fact that type isn’t something that we see hacker attempting to exploit much and all the major web browsers other than Firefox providing XSS filtering, which will prevent many exploitation attempts. Of more concern when seeing this type of vulnerability is that indicates the developer is failing do security basics as this type of vulnerability involves not properly handling user input.

The vulnerability was in the AJAX accessible function AjaxDisableCustomField() in the file /wp-security-audit-log.php, which you can see echo’s out the variable POST variable “notice” without escaping it:

181
182
183
184
185
186
187
188
189
190
191
192
public function AjaxDisableCustomField(){ 
	$fields = $this->GetGlobalOption('excluded-custom');
	if ( isset($fields) && $fields != "") {
		$fields .= ",".$_POST['notice'];
	} else {
		$fields = $_POST['notice'];
	}
	$this->SetGlobalOption('excluded-custom', $fields);
	echo 'Custom Field '.$_POST['notice'].' is no longer being monitored.
Enable the monitoring of this custom field again from the <a href="admin.php?page=wsal-settings#tab-exclude"> Excluded Objects </a> tab in the plugin settings';
	die;
}

That function is only accessible to logged in users.

The vulnerable code had been in the plugin over a year, as it was introduced in version 1.5 that was release on March 18, 2015.

What really got us was we went to the developer’s website to see how to contact them we found that the company offers is a security code review service for plugins, which they describe in part by saying:

WP WhiteSecurity specializes in WordPress plugins and themes security code reviews. Our team of experienced developers and penetration testers will identify security issues in your code and help you fix them by providing you practical coding solutions.

For a company that “specializes” in this sort of thing (it is on one of only four services they offer), they don’t seem to be very good at when it comes to their own plugin.

The vulnerability was at least promptly fixed, which often ins’t the case.

Proof of Concept

The following proof of concept will cause any available cookies to shown in alert box when logged in to WordPress. 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-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="AjaxDisableCustomField" />
<input type="hidden" name="notice" value="<script>alert(document.cookie);</script>" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 6/24/2016 – Developer notified.
  • 6/27/2016- Version 2.4.4 released, which fixes the vulnerability.