In the past we recommended the data on vulnerabilities in WordPress plugins from the WPScan Vulnerability Database as a good free alternative to our service, as while the quality of data was much lower, it was available for the right price for a lot of websites. More recently things have gotten worse, without a workaround for those relying on their data, so if you need access to this type of data our service is really the only good option.

One problem we have long seen with their data is that they would claim vulnerabilities had been fixed when they hadn’t. In the past you could double check if the vulnerability was fixed with a proof of concept included in their data or linked to, but often that now isn’t possible. Take this entry from yesterday for the plugin Ads for WP. Here is the totality of the details:

There isn’t anything there you can test out.

Looking at the changes made in the version that was supposed to fix that, this nonce check was added:

46
47
48
49
50
51
52

if ( ! isset( $_GET['wpnonce_'] ) ){
	return;		
}
 
if ( !wp_verify_nonce( $_GET['wpnonce_'], 'wpnonce_data' ) ){
	return;
}

That would be used to prevent cross-site request forgery (CSRF), but whether it does that would depend on the other code that surrounds it.

While it used to be that all of WPScan’s entries had attribution like this:

This entry and many other similar ones lack that:

Perhaps the person behind these is wishing to avoid attribution because they are aware of the low quality of what they are providing?

Breaking the Plugin

Through monitoring we do we got alerted that there might be a security fix in that version of the plugin, but unlike the WPScan Vulnerability Database, we actually check into things before adding them to our data set and we found that this doesn’t appear to have fixed a CSRF vulnerability, but instead broke one of the plugin’s admin pages.

The CSRF code was added to the function adsforwp_admin_analytics_interface_render():

39
40
41
42
43
44
45
46
47
48
49
50
51
52

public function adsforwp_admin_analytics_interface_render(){
 
	// Authentication
            if ( ! current_user_can( 'manage_options' ) ) {
                    return;
            }   
 
            if ( ! isset( $_GET['wpnonce_'] ) ){
                return;		
            }
 
            if ( !wp_verify_nonce( $_GET['wpnonce_'], 'wpnonce_data' ) ){
                return;
            }

That code runs when accessing the plugin’s “Analytics” admin page if a Google token exists:

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

$adsforwp_google_token = get_option( 'adsforwp_google_token' );
 
if (! $adsforwp_google_token ) {
 
	$settingsLink = 'edit.php?post_type=adsforwp';  
 
}else{
 
	 add_submenu_page( 'edit.php?post_type=adsforwp',
		esc_html__( 'Ads for wp', 'ads-for-wp' ),
		esc_html__( 'Analytics', 'ads-for-wp' ),
		'manage_options',
		'analytics',
		array($this, 'adsforwp_admin_analytics_interface_render')); 
	}

It is out of keeping with the way the core WordPress software works that accessing an admin page requires a valid nonce. The larger issue there is that a valid nonce is not provided, so you get a blank page when you access that page when the function adsforwp_admin_analytics_interface_render() is run.

That breaking doesn’t even stop what looks like what should actually have a nonce check related to that page.

Not “Official” or “Confirmed/Validated”

If people knew that WPScan Vulnerability Database is of low quality they could make an informed decision when relying on it, but we have found that there data is often reused without attribution. Making things worse it is promoted as being something it isn’t, for example we ran across the makers of the Wordfence Security plugin, which has 3+ million installs claiming that the data they use, which is from the WPScan Vulnerability Database, is “official” and “confirmed/validated”, despite those claim be completely false.

CSRF Vulnerability

The plugin registers the function adsforwp_instantiate_analytics_class() run when “plugins_loaded” is fired by WordPress:

274

add_action( 'plugins_loaded', 'adsforwp_instantiate_analytics_class' );

That function will create a new instance of the class Adsforwp_analyticsSettings when an admin page is accessed by a logged in Administrator:

275
276
277
278

function adsforwp_instantiate_analytics_class(){
if(is_admin() && current_user_can( 'manage_options' ) ){	
	$GLOBALS['ADSFORWP'] = new Adsforwp_analyticsSettings();
}

That class, which is located in the same file /admin/inc/analytics-settings.php, has a __construct() function that will cause the function postCalls() to run

15

function __construct(){

52

$this->postCalls();

Among other things, that function will allow deleting the Google token mentioned previously.

54

function postCalls(){

70
71
72
73
74

if(isset($_POST['wp_adsforwp_analytics_log_out'])){
 
	 delete_option( 'adsforwp_google_token' );
	 delete_option( 'adsforwp_analytics' );
}

What is missing there is a nonce check to prevent cross-site request forgery (CSRF) protection, so an attacker could cause a logged in Administrator to send a request that deletes that Google token.

Update (6/28/2019): The WPScan Vulnerability Database entry for this has been wiped of their claims that a CSRF had been fixed in that version:

WordPress Causes Full Disclosure

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information, can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will delete the “adsforwp_google_token” WordPress option.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/" method="POST">
<input type="submit" name="wp_adsforwp_analytics_log_out" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?