16 Apr

Vulnerability Details: Arbitrary File Deletion Vulnerability in WP Pipes

From time to time a vulnerability in a plugin is disclosed without the discoverer putting out a complete 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.

At the end of January a new version, 1.29, of the plugin WP Pipes was released that included a ...


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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

16 Apr

Vulnerability Details: Authenticated Arbitrary File Deletion Vulnerability in Woo Import Export

From time to time a vulnerability in a plugin is disclosed without the discoverer putting out a complete 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.

Last week, while looking into a report of a vulnerability that turned out to be an arbitrary file deletion ...


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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

16 Apr

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in a Another Brand New Plugin

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it.

This vulnerability is in a brand new plugin, Disc Golf Manager, and should have been something that the security review that is supposed to be done before new plugins can be added to the Plugin Directory should have caught. It is something that would have been flagged by our Plugin Security Checker, so it would make sense to run plugins through that during that security review to avoid this type of situation continuing to happen. That it continues to happen speaks to the continued lack of interest in improving security by the leadership of WordPress (starting at the top with Matt Mullenweg) and the continued role we play in limiting the impact of that for everyone else. We would be happy to provide the Plugin Directory team free access to the upload and developer mode capabilities to facilitate that.

The vulnerability occurs in function flashProcess() in the file /main.php where the value of the cookie “disc_golf_flash” is passed through the unserialize() function, which can lead to PHP object injection:

4043
4044
4045
function flashProcess() {
	if(isset($_COOKIE[$this->key . '_flash'])) {
		$temp = unserialize(base64_decode($_COOKIE[$this->key . '_flash']));

That function will run anytime a WordPress page is being accessed:

3811
add_action('init', array($this, 'flashProcess'));

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. 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

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “disc_golf_flash” to “TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=” and then when you visit a page on the webiste the message “PHP object injection has occurred.” will be shown.

Timeline

  • April 9, 2018 – Developer notified.
13 Apr

Not Really a WordPress Plugin Vulnerability – Week of April 13, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerabilities in WordPress File Upload

This week there were a couple of reports of claimed persistent cross-site scripting (XSS) vulnerabilities in WordPress File Upload that were supposed to have been fixed in version 4.3.3 and 4.3.4. For both of them, the proof of concept indicated that the claimed vulnerability would be exploited when logged in to WordPress. In testing things out it looked to us that you would need to be logged in as an Administrator to access them. That was confirmed by looking at the code. The page on which the issues occurred through is only accessible in the admin area of WordPress if the user has the “manage_options” capability:

21
if ( current_user_can( 'manage_options' ) ) $page_hook_suffix = add_options_page('Wordpress File Upload', 'Wordpress File Upload', 'manage_options', 'wordpress_file_upload', 'wordpress_file_upload_manage_dashboard');

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts). Those users would normally have the “unfiltered_html” capability and therefore could do the equivalent of persistent XSS, so those issues wouldn’t really be vulnerabilities.

There also was already protection against cross-site request forgery (CSRF) in place for both of the issue, so there was not CSRF/XSS vulnerability that had existed either.

13 Apr

Vulnerability Details: Arbitrary File Deletion Vulnerability in Google Drive for WordPress (wp-google-drive)

From time to time a vulnerability in a plugin is disclosed without the discoverer putting out a complete 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 problems that we find with reports of claimed vulnerabilities in WordPress plugins is that in some ...


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 WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

05 Apr

Real World Result of RIPS Code Analysis Service Doesn’t Match Hyperbolic Marketing of It

Recently there was claim made that an authenticated SQL injection vulnerability had been fixed in the plugin Custom Permalinks. In looking into that though we found that it was only accessible to Administrators, who would already normally have the capability to do the equivalent of SQL injection, so that wouldn’t really be a vulnerability. What seems notable about this is that the claim of the vulnerability came from the maker of an automated security tool that is marketed out of line with the actual result shown by that vulnerability claim.

The tool is marketed with claims like this:

RIPS code analysis detects critical security issues in your PHP application without false positive noise.

While we wouldn’t describe that issue as a false positive, it also is far from a critical security issue. The reality is that automated tools like that tool or are Plugin Security Checker have serious limits in what they can do (something that the rest of the marketing material for RIPS doesn’t give any hint of) and are best used by knowledgeable professionals that can properly integrate the results in to a larger security process.

The rest of the marketing just on its homepage is rather over the top as well, with phrases like “unique PHP analysis”, “most accurate”, “unmatched bug detection”, “precise detection”, “no other solution can find”, “leading performance”, and “in-depth security analysis”. None of that is linked to pages that attempt to back up the claims, which is less than reassuring about the capabilities of the tool and the people behind it.

What we found when we went to look in to this claim, backs up that concern, as a rather obvious security vulnerability actually exists in the functionality they claimed contained the authenticated SQL injection vulnerability.

While only Administrators could access that claimed vulnerability directly, it was still possible that there could be a way to exploit it if two conditions were met. The first being that there wasn’t protection against cross-site request forgery (CSRF) and that the request to exploit it was a GET request. The proof of concept provided for it ruled out that possibility since it involved a POST request:

Send authenticated POST request to “URL/wp-admin/admin.php?page=custom-permalinks-post-permalinks” with parameters “action=delete&permalinks[]=1) PAYLOAD — “

But that would seem to indicate that there wasn’t protection against CSRF, which in this case would mean that if an attacker could get a logged in Administrator to visit a URL the attacker controls they could cause permalinks created by the plugin to be deleted.

We first confirmed that was the case in a web browser and then we reviewed the underlying code to see all that was going on behind the scenes.

The plugin’s admin page PostTypes Permalinks is only accessible to those with the “administrator” role and accessing it calls the posttype_permalinks() function (in the file /admin/class-custom-permalinks-admin.php):

add_submenu_page( 'cp-post-permalinks', 'PostTypes Permalinks',
	'PostTypes Permalinks', 'administrator', 'cp-post-permalinks',
	array( $this, 'posttype_permalinks' )
);

Near the top of the function it checks if several POST inputs exists and if they exist it will delete the specified permalinks:

52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public function posttype_permalinks() {
	global $wpdb;
	$filter_options   = '';
	$filter_permalink = '';
	$search_permalink = '';
	$html             = '';
	$error            = '';
 
	// Handle Bulk Operations
	if ( ( isset( $_POST['action'] ) && $_POST['action'] == 'delete' )
		|| ( isset( $_POST['action2'] ) && $_POST['action2'] == 'delete' )
		&& isset( $_POST['permalink'] ) && ! empty( $_POST['permalink'] ) ) {
		$post_ids = implode( ',', $_POST['permalink'] );
		if ( preg_match( '/^\d+(?:,\d+)*$/', $post_ids ) ) {
			$wpdb->query( "DELETE FROM $wpdb->postmeta WHERE post_id IN ($post_ids) AND meta_key = 'custom_permalink'" );

There is no check for a nonce, which would prevent cross-site request forgery (CSRF), before the deletion happens.

We notified the developer of the plugin of the issue on February 26 and they replied the next day that the issue would be fixed “ASAP”. Earlier today, for the first time since we contacted them a new version was released, but it didn’t make any change related to the vulnerability.

Proof of Concept

The following proof of concept will delete the permalinks with IDs 1 and 2, when logged in as 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=cp-post-permalinks" method="POST" >
<input type="hidden" name="action" value="delete" />
<input type="hidden" name="permalink[]" value="1" />
<input type="hidden" name="permalink[]" value="2" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 26, 2018 – Developer notified.
  • February 27, 2018 – Developer responds.
23 Mar

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in DukaPress

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it. Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our main service as well as separately).

In the plugin DukaPress, the value of a cookie was passed through the unserialize() function, which could lead to PHP object injection. That occurred in the function get_cart_cookie() (in the file /classes/dukapress-cart.php):

33
34
35
36
37
38
static function get_cart_cookie() {
 
	$cookie_id = self::$cookie_id_string . COOKIEHASH;
 
	if ( isset( $_COOKIE[ $cookie_id ] ) ) {
		$cart = unserialize( stripslashes( $_COOKIE[ $cookie_id ] ) );

The value of COOKIEHASH in that is set by WordPress with the following code:

define( 'COOKIEHASH', md5( $siteurl ) );

That function is accessible through WordPress’ AJAX functionality whether someone is logged in to WordPress or not:

12
13
add_action('wp_ajax_nopriv_dpsc_update_cart', array(__CLASS__, 'update_cart'));
add_action('wp_ajax_dpsc_update_cart', array(__CLASS__, 'update_cart'));

We contacted the developer about the vulnerability yesterday and within hours they had released version 3.2 that resolved it by replacing use of unserialize() with json_decode() (and replaces related use of serialize() with json_encode()):

38
$cart = json_decode(  $_COOKIE[ $cookie_id ] , true );

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “dpsc_cart_” plus the md5 hashed version of the website’s site URL to “O:20:”php_object_injection”:0:{}” and then when you visit the following URL  the message “PHP object injection has occurred.” will be shown if you are not logged in to WordPress.

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

http://[path to WordPress]/wp-admin/admin-ajax.php?action=wsfl_add_product_to_cart

Timeline

  • March 23, 2018 – Developer notified.
  • March 23, 2018 – Version 3.2 released, which fixes vulnerability.
  • March 23, 2018 – Developer responds.
14 Mar

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in a Another Brand New Plugin

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it.

This vulnerability is in a brand new plugin, HappyForms, and should have been something that the security review that is supposed to be done before new plugins can be added to the Plugin Directory should have caught. It is something that would have been flagged by our Plugin Security Checker, so it would make sense to run plugins through that during that security review to avoid this type of situation continuing to happen. That it continues to happen speaks to the continued lack of interest in improving security by the leadership of WordPress (starting at the top with Matt Mullenweg) and the continued role we play in limiting the impact of that for everyone else. We would be happy to provide the Plugin Directory team free access to the upload and developer mode capabilities to facilitate that.

The vulnerability occurred in function read() in the file /inc/classes/class-message-notices.php where the value of the cookie “happyforms-message-notices” was passed through the unserialize() function, which can lead to PHP object injection:

108
109
110
111
112
public function read() {
	$this->messages = array();
 
	if ( isset( $_COOKIE[ $this->cookie_name ] ) && ! empty( $_COOKIE[ $this->cookie_name ] ) ) {
		$this->messages = unserialize( stripslashes( $_COOKIE[ $this->cookie_name ] ) );

That function will run anytime a non-admin page is being accessed:

67
68
69
if ( ! is_admin() ) {
	add_action( 'send_headers', array( $this, 'read' ) );
}

After we notified the developer of the issue, they released version 1.1, which resolves the vulnerability by replacing use of unserialize() with json_decode() (and replaces related use of serialize() with json_encode()):

112
$this->messages = json_decode( stripslashes( $_COOKIE[ $this->cookie_name ] ), true );

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “happyforms-message-notices” to “O:20:”php_object_injection”:0:{}” and then when you visit a frontend page the message “PHP object injection has occurred.” will be shown.

Timeline

  • February 13, 2018 – Developer notified.
  • February 14, 2018 – Developer responds.
  • March 13, 2018 – Version 1.1 released, which fixes vulnerability.
12 Mar

Our Proactive Monitoring Caught a Authenticated PHP Object Injection Vulnerability in bbPress Move Topics

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That sometimes leads to us catching a vulnerability of a more limited variant of one of those serious vulnerability types, which isn’t as much concern for the average website, but could be utilized in a targeted attack. That happened with the authenticated PHP object injection vulnerability we found in the plugin bbPress Move Topics. This vulnerability could have allowed an attacker that had access to a WordPress account of contributor level or above to exploit a PHP object injection vulnerability. It also could have allowed an attacker that could get a user logged in as a Contributor-level or above to visit a URL the attacker controls, to exploit the vulnerability as well.

Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our service as well as separately).

The vulnerability occurred in the function aforums_move_topics_page(). That function passed the base64 decoded value of the POST input “allforums” through the unserialize() function, which could lead to PHP object injection:

54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
function forums_move_topics_page() {
	// Backward compatibility
	// Clean v1.1.2
	delete_option('bbpmt-ptot-donot-close');
 
	echo '&gt;h1&lt;Move topics Forum to Forum&gt;/h1&lt;';
	if ( !function_exists( 'bbp_list_forums' ) ) {
		require_once ABSPATH . PLUGINDIR . '/bbpress/includes/forums/template.php';
	}
 
	// Check if coming from form (POST data)
 
	// Choose topics to move
	if ( isset($_POST['goforum']) ) {
		if( empty($_POST["sourceforum"]) ) {
			echo 'No forum selected';
		} else {
			global $wpdb;
			$allforumarray = unserialize(base64_decode($_POST["allforums"]));

That function is accessed through a page in the admin area of WordPress:

514
$confHook = add_submenu_page('edit.php?post_type=forum', 'Move topics', 'Move topics', 'edit_posts', 'forums_move_topics', 'forums_move_topics_page');

The capability required to access that “edit_posts” is usually provided to Contributor-level and above users.

Since there was no nonce check that ran before that code ran, the vulnerability could be exploited through cross-site request forgery (CSRF).

After we notified the developer of the issue, it was resolved in version 1.1.5, which replaces the usage of unserialize() with a new function, bbpmt_get_forum_structure().

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, the following proof of concept will cause the message “PHP object injection has occurred.” be shown, when logged in as a Contributor-level or above user.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/edit.php?post_type=forum&page=forums_move_topics" method="POST">
<input type="hidden" name="goforum" value="test" />
<input type="hidden" name="sourceforum" value="test" />
<input type="hidden" name="allforums" value="TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=" />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 16, 2018 – Developer notified.
  • February 23, 2018 – Developer responds.
  • March 11, 2018 – Version 1.1.5 released, which fixes vulnerability.