28 Jul

We Actually Help to Get Vulnerabilities in WordPress Plugins Fixed

When it comes to the security industry surrounding WordPress one of the disheartening things we see is when companies that are doing harmful things, like making claims that WordPress is insecure in ways it isn’t, to sell their products and services are somehow praised for being focused on the community. When that happens companies are less likely to do things that would actually help everybody and instead focus on things that actual make the security situation worse. At this point it wouldn’t take much to help out improve the security of hundreds of thousands of websites.

We do rather extensive monitoring of reports of vulnerabilities in WordPress plugins to make sure we are providing the best data on WordPress plugins. One of the places we monitor is the WPScan Vulnerability Database because occasionally people will submit reports of vulnerabilities directly to them. Through that monitoring last week came across a report from another website of a reflected cross-site scripting vulnerability in the plugin WP Statistics. That is a type of vulnerability that is highly unlikely to be attempted to be exploited on the average website, but with 400,000 active installs according to wordpress.org, there is a decent chance that it might be installed on some website that would be targeted by hackers and there could be exploit attempts against those websites (the average website doesn’t face targeted attacks).

The report on the vulnerability didn’t make any mention of any attempt to contact the developer of the plugin and based on the quick response and resolution we saw when we reported a similar vulnerability we found to the developer several months ago, it seemed likely that hadn’t happened. When we contacted the developer this time we also got a quick response and several days later the vulnerability was resolved. The developer made it sound like no one else had notified them before us, despite the vulnerability already being included the WPScan’s data, which is used by numerous WordPress security products and services.

It would seem that the people behind the WPScan Vulnerability Database didn’t do notify the developer either as we received several follow up emails from the developer letting us know that the new version had been submitted to GitHub and the released on the Plugin Directory. So if the WPScan people had also notified the developer they would have known that this has been fixed. But as of now it is not listed as being fixed in their data, despite the fix being released four days ago (if it was, there would be a mention of that in the Affects section):

This isn’t a one off situation, as we have regularly found that developers have not been notified of publicly disclosed vulnerabilities in their plugins.

20 Jul

More of Planet Zuda’s Troubling Handling of Claimed Security Vulnerabilities in WordPress Plugins

Last week we looked a claim by the web security company Planet Zuda of a severe vulnerability in a popular WordPress plugin, which seemed at best to be them not fully looking into the issue before making a untrue claim as to its severity. The next day they put out another post making a similar claim of an even more popular plugin, SiteOrigin Widgets Bundle. Once again they also are selling a version of the plugin that is supposed to be patched, which possibly violates multiple laws. Also, once again there was no mention that they had notified the developer of the plugin about the vulnerabilities. This time though they didn’t provide any details of the claimed vulnerabilities, so that neither we nor anyone else could independently review their claim.

Here is how they described the claimed vulnerability:

SiteOrigin has a lot of vulnerabilities and we’ve patched the most severe one today. Based on our code review this vulnerability would allow attackers to inject malicious code into the website, deface the site and cause other damage to it. This bug among a few other bugs are patched.

When we looked over the plugin looking for a vulnerability that could match the claim we couldn’t find anything. We couldn’t even find any functionality that seemed like it could allow those things to happen if there was a vulnerability in it. We then notified the developer of the plugin, SiteOrigin, about the situation. We promptly got a response from them and we later got a follow up after they had purchased the “fixed” version of the plugin. Here is how someone from the company described the changes in that version to us:

He’s adding URL escaping for a URL that’s being passed into wp_redirect, which as far as I’m aware is already being sanitized by wp_sanitize_redirect.

He’s adding escaping to 1 variable when its defined, but we’re already escaping it on output.

The last issue he found was adding a capabilities check to an admin ajax_action. This is the one fix I agree with, but the action is already being protected by a nonce. The nonced URL is only being generated for authenticated users, but technically an attacker with access to the nonced URL would be able to enable/disable a site’s Widgets Bundle widgets until the nonce expires.

They then provided us with a copy of the “fixed” version where we saw that what they are describing there seems mostly accurate. The only difference from that we saw from what they reported is that it doesn’t look like the nonce they mentioned is actually ever created by the code, so even without the capabilities check, the code it would have protected would never run.

Overall, we would say that no actual vulnerabilities were found by Planet Zuda, much less a severe vulnerability as they described.

What makes this worse is that the developer states that Planet Zuda would not provide them any information on the claimed vulnerabilities, instead telling them they could purchase the “fixed” version like anyone else. Currently Planet Zuda is charging 19.99 for the privilege of finding out they didn’t really fix anything.

The developer, SiteOrigin, should be commended for going beyond what was necessary in trying to make sure their plugin was secure here.

20 Jul

WordPress Plugin Developers Don’t Always Have the Best Understanding of the Security of Their Plugins

Recently on a fairly regular basis we have been interacting with developers of WordPress plugins that seem to believe that they have a better understanding of security than they actually do, which has lead to them either not fixing vulnerabilities or not making security improvements to their plugins that they really should be. What makes dealing with that more irritating is when we see developers making changes to fix vulnerabilities that don’t actually exist in their plugins. So real vulnerabilities are not getting fixed, while non vulnerabilities are getting “fixed”. Usually that “fix” involves the developer duplicating security protection already being handled in the plugin or by WordPress. Other than causing the plugin to use slightly more resources than needed, this isn’t usually detrimental. If there is someone to fault for that, it is those making false claims about vulnerabilities in plugins, which occurs all too often.

As an example of an unneeded fix, let’s take a look at version 5.2.13 of bbPress. The release announcement states that the version:

adds some sanitization to anonymous user data that went missing from previous versions

and

If your site allows anonymous users (users without registered accounts) to create topics & replies in your forums, you’ll want to upgrade to 2.5.13 right away.

Looking at the changes made in that version you can see that in the file /includes/common/functions.php several values are now run through sanitization functions.

Here are how the important values looked as of version 2.5.12 (the other value is derived from one of these):

615
616
617
618
619
$r = bbp_parse_args( $args, array (
	'bbp_anonymous_name'    => !empty( $_POST['bbp_anonymous_name']    ) ? $_POST['bbp_anonymous_name']    : false,
	'bbp_anonymous_email'   => !empty( $_POST['bbp_anonymous_email']   ) ? $_POST['bbp_anonymous_email']   : false,
	'bbp_anonymous_website' => !empty( $_POST['bbp_anonymous_website'] ) ? $_POST['bbp_anonymous_website'] : false,
), 'filter_anonymous_post_data' );

There you have three POST inputs being brought in without being sanitized, but the next lines down then do the sanitization:

621
622
623
624
625
626
627
628
629
630
631
// Filter variables and add errors if necessary
$r['bbp_anonymous_name'] = apply_filters( 'bbp_pre_anonymous_post_author_name',  $r['bbp_anonymous_name']  );
if ( empty( $r['bbp_anonymous_name'] ) )
	bbp_add_error( 'bbp_anonymous_name',  __( '<strong>ERROR</strong>: Invalid author name submitted!',   'bbpress' ) );
 
$r['bbp_anonymous_email'] = apply_filters( 'bbp_pre_anonymous_post_author_email', $r['bbp_anonymous_email'] );
if ( empty( $r['bbp_anonymous_email'] ) )
	bbp_add_error( 'bbp_anonymous_email', __( '<strong>ERROR</strong>: Invalid email address submitted!', 'bbpress' ) );
 
// Website is optional
$r['bbp_anonymous_website'] = apply_filters( 'bbp_pre_anonymous_post_author_website', $r['bbp_anonymous_website'] );

That code calls filtering defined in the file /includes/core/filters.php:

214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
/**
 * Add filters to anonymous post author data
 */
// Post author name
add_filter( 'bbp_pre_anonymous_post_author_name',    'trim',                10 );
add_filter( 'bbp_pre_anonymous_post_author_name',    'sanitize_text_field', 10 );
add_filter( 'bbp_pre_anonymous_post_author_name',    'wp_filter_kses',      10 );
add_filter( 'bbp_pre_anonymous_post_author_name',    '_wp_specialchars',    30 );
 
// Save email
add_filter( 'bbp_pre_anonymous_post_author_email',   'trim',                10 );
add_filter( 'bbp_pre_anonymous_post_author_email',   'sanitize_email',      10 );
add_filter( 'bbp_pre_anonymous_post_author_email',   'wp_filter_kses',      10 );
 
// Save URL
add_filter( 'bbp_pre_anonymous_post_author_website', 'trim',                10 );
add_filter( 'bbp_pre_anonymous_post_author_website', 'wp_strip_all_tags',   10 );
add_filter( 'bbp_pre_anonymous_post_author_website', 'esc_url_raw',         10 );
add_filter( 'bbp_pre_anonymous_post_author_website', 'wp_filter_kses',      10 );

For the author name and email field one the filters applied is the same as the sanitization added in version 5.2.13, a different one is applied to the URL:

615
616
617
618
619
$r = bbp_parse_args( $args, array (
	'bbp_anonymous_name'    =&gt; !empty( $_POST['bbp_anonymous_name']    ) ? sanitize_text_field( $_POST['bbp_anonymous_name']    ) : false,
	'bbp_anonymous_email'   =&gt; !empty( $_POST['bbp_anonymous_email']   ) ? sanitize_email(      $_POST['bbp_anonymous_email']   ) : false,
	'bbp_anonymous_website' =&gt; !empty( $_POST['bbp_anonymous_website'] ) ? sanitize_text_field( $_POST['bbp_anonymous_website'] ) : false,
), 'filter_anonymous_post_data' );

One of the reasons it is important get be accurate with claims that a new version fixes a vulnerability is something else mentioned in the release announcement:

Also, remember that since bbPress 2.5.12, the minimum WordPress version allowed is 4.7. If you need to user a previous version of WordPress, you will want to continue to use 2.5.11.

If you use our service we have checked on claims that a new version fixes a vulnerability before adding it our data set, so you will know that if we are indicating that a version is vulnerable than it actually is. And if see something were not listing in the data shown on the service’s companion plugin’s page (and haven’t sent you an email if you are using an impacted version) you can get in touch with us to see why that is.

17 Jul

Malware Expert’s Post on WordPress Plugin Vulnerability Largely Copied from Ours

We don’t think too highly of the security industry, as among other issues, you have lots of people that don’t have the expertise required to be properly understand the security products/services they are providing and others that seem to have no problem engaging unethical behavior.  One of the problems that first issue causes is that you often have people simply repeating claims made by others, without knowing if what they are repeating is true (or seeming to care either). Often the original claim was made someone else that fits into at least the first of those two categories and not surprisingly the claim isn’t true. On top of that, as we have found in trying to correct misconceptions that are brought up to us when dealing with security issues on websites, this creates an echo chamber where the claims are more likely to believed because they are repeated over and over, despite being repeated by people that don’t have any idea if they are true.

While looking in to something recently, we came across a blog post by a company named Malware Expert from January 7, common.php (Object Injection Vulnerability in Backup & Restore Dropbox). When we went to make sure we had the vulnerability in our data set, we found that we did, but we also noticed that most of the ostensibly original content from the post (much of content is code from the plugin) was simply copied from our post on the vulnerability from December 15.  The content isn’t in quotes and there isn’t any mention of us in the post. At the very least this company doesn’t have a qualm about passing others content as their own, but it also raises questions as to if they have the expertise needed to understand what they are dealing with. Below is the version of relevant the text from Malware Expert’s post and then the original from our post.

Malware Expert:

In the plugin file /wp-content/plugins/dropbox-backup/dropbox-backup.php the function wpadm_full_backup_dropbox_run()gets registered to run during init (so it runs whenever WordPress loads):

Us:

In the file /dropbox-backup.php the function wpadm_full_backup_dropbox_run() gets registered to run during init (so it runs whenever WordPress loads):

Malware Expert:

That function then causes the function wpadm_run() to run:

Us:

That function then causes the function wpadm_run() to run:

Malware Expert:

When that function runs, if there is a POST input “dropbox-backup_request” included with the request to the website it will pass it to the function wpadm_unpack() (in the file /wp-content/plugins/dropbox-backup/functions/wpadm.php):

Us:

When that function runs, if there is a POST input “dropbox-backup_request” included with the request to the website it will pass it to the function wpadm_unpack() (in the file /functions/wpadm.php):

Malware Expert:

That in turns causes the POST input “dropbox-backup_request” to be run through the function unserialize,which allows the possibility of PHP object injection to occur:

Us:
That in turns causes the POST input “dropbox-backup_request” to be run through the function unserialize,which allows the possibility of PHP object injection to occur:
13 Jul

Planet Zuda and OptinMonster Handle Poor Security of OptinMonster API Plugin Extremely Badly

Through the various things we do as part our service we have a fair amount of interaction with people making claims about vulnerabilities in WordPress plugins and with the developers of WordPress plugins with vulnerabilities. From doing that we don’t currently have a very positive view of either side, which shouldn’t be all that surprising considering the poor state of security of WordPress plugins and security in general. As example of what that looks like let’s take a look at a recent claim by Planet Zuda of a vulnerability in the plugin OptinMonster API, which we found pointed to poor security in the plugin, but not the vulnerability claimed.

Before we get to the details of what is actually going on with the plugin, let’s take a look at how Planet Zuda responded to it:

This is a severe vulnerability leaving the admin side of your site vulnerable, so we have written a patch for this one vulnerability in the WordPress plugin Optinmonster, also known as Optinmonster API. You  can buy the more secure version of the WordPress optinmonster plugin [https://planetzuda.com/product/wordpress-plugin-optinmonster-aka-optinmonster-api-security-fix/] on our site. We may patch more vulnerabilities in this plugin, but we can say that our version of WordPress plugin optinmonster is currently more secure then what is available and we can continue to update it to be more secure.

Based on that it sounded like they hadn’t made any attempt to contact the developer, which is bad. Instead they are trying to sell people a version they claim is secured. Depending on what exactly they are selling they could be violating multiple laws, as the code in the plugin is GPL’d, but other parts could be copyrighted or trademarked. On Tuesday they were charging 9.99 for their version of the plugin and by Wednesday it was 19.99.

Now let’s get the security issue with the plugin. Here is how they started their explanation:

The WordPress plugin Optinmonster API has left over 500 thousand sites vulnerable to a security flaw. Thankfully we have a fix [https://planetzuda.com/product/wordpress-plugin-optinmonster-aka-optinmonster-api-security-fix/] you can buy for this one vulnerability.

During our code review we discovered that the admin area is protected by a WordPress function called is_admin, which is a misunderstood function, that allows admins and unauthenticated users alike to access the information in optinmonster API. What does this mean to you, the user? It means that you can access the admin features, but so can criminals.

The use of is_admin occurs in the function init() in the file /optin-monster-wp-api.php:

142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
public function init() {
 
	// Define necessary plugin constants.
	define( 'OPTINMONSTER_API', '//a.optnmstr.com/app/js/api.min.js' );
 
	// Load our global option.
	$this->load_option();
 
	// Load global components.
	$this->load_global();
 
	// Load admin only components.
	if ( is_admin() ) {
		$this->load_admin();
	}
 
	// Run hook once OptinMonster has been fully loaded.
	do_action( 'optin_monster_api_loaded' );
 
}

Not surprisingly that runs during init, so whenever WordPress is loading.

In looking at the code we are not sure that use of is_admin() is due to not understanding what it does, but maybe instead the way the developer decided to handle things is not really appropriate.

What does optinmonster protect using is_admin? At first glance it is just one line of code, so how bad could that actually be? It turns out that one line of code as you can tell is calling almost all of the rest of the code in the application.

Yes, the one line of code load_admin, loads everything that should be administrator only, but instead is accessible for all.

Here is the function load_admin() that is run if is_admin() is true:

201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
public function load_admin() {
 
	// Register admin components.
	$this->actions  = new OMAPI_Actions();
	$this->menu     = new OMAPI_Menu();
	$this->content  = new OMAPI_Content();
	$this->save     = new OMAPI_Save();
	$this->refresh  = new OMAPI_Refresh();
	$this->validate = new OMAPI_Validate();
	$this->welcome  = new OMAPI_Welcome();
	$this->review   = new OMAPI_Review();
 
	// Fire a hook to say that the admin classes are loaded.
	do_action( 'optin_monster_api_admin_loaded' );
 
}

As you can tell above, the administrator menu, admin actions, reviews the admin has access to, the welcome page, the site content and the ability to save content among other things are  accessible to anyone or any bot who logs onto the site.

The code shown above (the same code is shown in Planet Zuda’s post) doesn’t actually show what they are saying. It only shows that new instances of a number of classes are created. To show that those things were accessible you would then go on to show an example what happens with those new classes, but Planet Zuda doesn’t. The next piece of text in their post is what we quoted before we started discussing the details of security issue.

In looking at this the first thing that caught our eye was the class OMAPI_Save. If anyone can change the plugin’s settings that has the possibility of allowing for a number of vulnerabilities beyond just being able to change the plugin’s settings. That class is defined in the file /OMAPI/Save.php.

The construct function for that class will the cause the function maybe_save() to run:

53
54
55
56
57
58
59
60
61
public function __construct() {
 
	// Set our object.
	$this->set();
 
	// Possibly save settings.
	$this->maybe_save();
 
}

That function checks for a valid nonce, which protects against cross-site request forgery (CSRF), before saving the settings:

81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
public function maybe_save() {
 
	// If we are missing our save action, return early.
	if ( empty( $_POST['omapi_save'] ) ) {
		return;
	}
 
	// If the subkey is empty, return early.
	if ( empty( $_POST['omapi'][ $this->view ] ) ) {
		return;
	}
 
	// Verify the nonce field.
	check_admin_referer( 'omapi_nonce_' . $this->view, 'omapi_nonce_' . $this->view );
 
	// Save the settings.
	$this->save();
 
	// Provide action to save settings.
	do_action( 'optin_monster_api_save_settings', $this->view );
 
}

That nonce is only accessible on an admin page that is limited to those with the manage_option capability, which is normally only Administrators. So while the code to save the plugin’s setting is available to anyone it doesn’t mean that anyone can do that. For things to be properly secured there really should be a check to make sure that the person making the request is permitted to do that using a capabilities check. While the nonce does double duty in this instance, it should not be relied on in that way.

In looking over the classes we didn’t see anything that could be considered a vulnerability, but there other parts that don’t contain any restriction on who can run their functionality.

After looking over this we sent the following message to the developer of the plugin, OptinMonster:

A report of a security vulnerability has been released for your WordPress plugin: https://planetzuda.com/wordpress-plugin-optinmonster-popups-500-thousand-sites-allows-unauthenticated-users-admin-backend/2017/07/11/

In looking at the report it seems that the report is misleading at best, but there does seem to be room for improvement at least. It isn’t clear if your use of is_admin() is what you intended and, for example, you don’t do a capabilities check when saving the plugin’s options, which you should do in addition to checking for protection against CSRF.

There is no mention in that post of the discloser having had made any attempt to contact you about the issue, which they should have. We would appreciate if you let us know if they did or did not contact you, because if they didn’t, we would like to let people know that they are not handling things properly.

If you have any questions or need help in dealing with this issue, please feel free to get back to us.

Less than half an hour later we got this response:

The report was false and misleading – there are no security vulnerabilities. It is libelous and we have sent a Cease and Desist letter because they are using our trademarks without our permission in a defamatory way.

They did not attempt to contact us but rather went straight to our customers. It is obviously done as a scare and smear tactic to try and persuade visitors to purchase their update.

We check for capabilities plus CSRF. If you look in the code, it is there.

The response to what Planet Zuda had done seemed appropriate, but the seeming lack of concern about the poor security of the plugin was troubling. The claim that they check capabilities isn’t true, we looked at the code before we contacted them. At best they don’t actually know what they are talking about. A worse explanation is they thought they could get away with lying about this.

At that point we doubled check the code and after not seeing a capabilities check we sent the follow response:

We did look at the code for saving the plugin’s options and we didn’t see any capabilities check when saving them, where in the code does that occur?

A day later we haven’t heard anything back, which if it was there really was a capabilities check, they shouldn’t have had a problem getting back to us with where it is.

The developers seeming lack of interest in an issue raised about the security of the plugin is unfortunately an all to common occurrence.

13 Jul

Image Upload Capability in WordPress Plugin Being Abused

The security industry has more than its fair share of snake oil and hucksters, which seems like it can be explained in part due to the fact that people that don’t know and or care about security can make claims that those more knowledgeable would never make.  For example, somebody that has a basic understanding of security wouldn’t claim their WordPress security plugin “stops you from getting hacked” because a WordPress plugin would not have any chance of stopping certain types of attacks (yet somehow the most popular plugin makes this claim). Not only is security extremely complicated, but things are frequently changing, so you need to keep adjusting as new threats come about and existing ones change. Along those lines we thought it important to share something we ran across yesterday about the abuse of a popular plugin’s intended functionality.

One of the ways we keep track of plugin vulnerabilities out there is by monitoring the WordPress Support Forum for threads that might be relevant. Through that, this week have added three newly disclosed vulnerabilities that exist in the most recent version of their respective plugins, including one in a plugin with 1+ million active installs, to our data set,. Those are vulnerabilities you won’t find in any other source of WordPress plugin vulnerabilities data due to no one else doing the kind of extensive monitoring we do. Through that monitoring we also came across a report of abuse of the image upload capability in the plugin WP Job Manager.

That relates to a post we wrote just about a month ago looking in to a claim that a vulnerability in the plugin had been fixed that had allowed website defacements due to those not logged in to WordPress being able to upload images through the plugin’s AJAX functionally. The claim didn’t really make a lot of sense for two reasons. First we didn’t understand how uploading an image could allow a website to be defaced in normal circumstances. But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

The thread we ran across indicates the abuse of that image upload capability, but not for website defacement, at least in any way we have heard the term used before. Here is how an impacted user explained it in a series of posts:

We have seven websites running WP JOB MANAGER plugin and all have been infected and one even blocked by the domain registrar!!

Please, we need an urgent solution to this.

How were the websites “infected”:

In all cases it was either gif or jpg.

This triggered some strange security warning from some security company and one domain even got blocked based on this (until I removed the file).

Also my host was warned.

So what were the images being used for:

The uploaded file is a phishing/spam use and our site gets the responsibility.

Very dangerous! I hope there is a solution for this.

Or a way to turn off image upload? Not like many employers are even using it.

The plugin is developed by Automattic, the company closely associated with WordPress, and the response from one of the developers doesn’t seem to reassuring about their ability to handle complex issues:

@gstar@rogier1988@etheos sorry for the slow response here. Yes, there was a vulnerability reported and we updated the plugin immediately after some discussion. The update was release 29 days ago. Here is the changelog with a link to the issue:

https://github.com/Automattic/WP-Job-Manager/blob/master/changelog.txt

I added an announcement and sticky post about this on the forum which can be found here: https://wordpress.org/support/topic/wp-job-manager-1-26-2-released/

Can you please check the version of WPJM you are running and confirm to us which version you are using. If you are using 1.26.2 and there is a new vulnerability we need to get that sorted out.

As we mentioned before, the change made in that version didn’t seem to resolve an issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin. This seems like a good time to remind people that we are always available to provide free help to developers dealing with security issues in their plugins, seeing as if we were contacted about the issue we would have pointed this out at the time.

The problem with this type of issue is that the activity of uploading image is intended, so ideally you would try to stop it from being abused without hindering its intended use. In the case of this plugin, one plausible solution that sounds like it could limit the abuse is to resize large images to the smaller size they are actually shown by the plugin, but for other plugins it might be more difficult.

11 Jul

We Added Three Times As Many Previously Unknown Vulnerabilities as the WPScan Vulnerability Database Did Last Month

If you are getting vulnerability data on WordPress plugins from someone other than us it is likely coming from the WPScan Vulnerability Database. That this is the data source being used often isn’t disclosed and we have yet to see anyone put any proper disclaimer as to the quality of the data or that they are simply passing along unverified claims.

If you go back through previous posts we have tagged related to that data source you can see more about the issues that come with their data, but we thought another way of looking how we provide superior data (which is just one of the features of our service) and why anyone paying a security service shouldn’t be provided their data was to look at how we compared to them in adding previously unknown vulnerabilities to our data set last month. In doing that we spotted an improvement to our process to provide even better data (we have a post coming out soon about another recent improvement) and a reminder that others involved in disclosing vulnerabilities can do a better job.

The top line, which people would probably be most interested in, is that we added 43 previously unknown vulnerabilities to our data last month and WPScan Vulnerability Database only added 14. That works out to them having only added a third as many, 33%, vulnerabilities last month.

WPScan Missed the Most Serious Vulnerabilities

Quantity isn’t everything though. While much of the security industry seems to be all too willing to make minor vulnerabilities sound like big threats, the reality is that most vulnerabilities are of little threat to the average website. They would be of more concern for the small sliver of websites that are likely to be targeted by hackers, which is the kind of websites we see more as being ones that it makes sense to use our service.

In looking at the vulnerabilities added to both sources last month, two vulnerabilities, an arbitrary file upload and arbitrary file viewing vulnerability, in one plugin stand out. Both of these are ones that are likely to be targeted by hackers if they were aware of them. The vulnerabilities were fixed, but the developer didn’t change the version number when they made that change. That means that those that already updated to the latest version remain vulnerable (as well as anyone still running an older version). We notified the developer after spotting that problem, but nearly a month later the version number still hasn’t been changed. For those using our service, they were notified long ago and provided instruction to resolve this problem by uninstalling and then reinstalling the plugin. For those relying on the WPScan Vulnerability Database’s data, they are completely unaware of these vulnerabilities.

There really isn’t a good reason for WPScan Vulnerability Database to missing those vulnerabilities. While we found that the vulnerabilities had been discovered and fixed through our extensive monitoring, which we have seen no evidence that anyone else even comes close to doing, the people behind that data source (or anyone else since they accept public submissions) could have simply followed our blog and become aware of these vulnerabilities, but apparently doing that is too difficult.

Room for Improvement on Our End

Since we have pointed several major problems with WPScan’s data additions, it would be unfair not to point out where we were less than perfect. To do that let’s take a look at the vulnerabilities added to WPScan’s data last month and whether we included them.

Also Included

10 of the 14 vulnerabilities they added were also added to our data during the month:

The last vulnerability listed there though is a good reminder of one of the quality issues with WPScan’s data. While their data lists the vulnerability as having been “fixed in version 4.6.5”, in truth it wasn’t fixed in that version or even fixed at the time they listed it as having been fixed. As we noted at the time, we notified the developer of the disclosure of the unfixed vulnerability and it was fixed shortly after that. If not for us the vulnerability likely would still be in the plugin.

Not Really a Vulnerability

Two of the reported vulnerabilities they included are ones that we were aware of but did not included in our data since they really are not vulnerabilities:

For Photo Gallery by WD, we already discussed the reason for the lack of inclusion.

For WP Jobs, access to the relevant page is restricted to those with the edit_themes capability, which would normally be Administrators, so this really wouldn’t be a vulnerability since Administrators normally already have the ability to do the equivalent of this. There is the possibility of related type of vulnerability that we have started to add to our data for which that plugin should be listed, which we will be discussing in an upcoming post.

Missed Vulnerabilities

Finally two vulnerabilities that actually existed that we were aware of but had not included in our data as of last month (they are now included):

For WP-Testimonials, the vulnerability was listed by the discoverer as being exploitable by an “authenticated user”, that is, someone logged in to WordPress. What was missing and often is missing from reports is what level of access a user has to have to exploit the vulnerability. That obviously makes a big difference, since most potential vulnerabilities are really not vulnerabilities if only accessibly by Administrators since among other things, they normally can edit plugins and remove any security protection.

In the case of this vulnerability it was normally only accessible by Administrators, but what we originally missed is that the plugin allows changing what users had access to the relevant page, so we should have listed it. We normally do check for that, but in preparing this post we realized a better way to do that. Instead of trying to look through a plugin’s settings, the better way to check for that is to look at the underlying code. In this instance when we went to write up this post we noticed the relevant code registering the vulnerable page listed the variable “$sfs_admng” as the capability need to access it:

add_menu_page('Testimonials', 'Testimonials', $sfs_admng, 'sfstst_manage', 'sfstst_adminpage', plugins_url('/wp-testimonials/sfstst_icon.png'));

When we went to look at what was used to specify that value we could see that it could be set from an option (setting):

if (get_option('sfs_admng') == '') { $sfs_admng = 'update_plugins'; } else {$sfs_admng = get_option('sfs_admng'); }

For WP Live Chat Support, the reason for our lack of earlier inclusion is the discloser had not provided enough information in their report to verify the vulnerability without us doing additional work. Doing that for this particular vulnerability got overtaken by other items that we needed to deal with. In this case though WPScan’s inclusion didn’t really provide their user with a better situation since when we got a chance to look into the details of the vulnerability we found that it had only been fixed in one of two locations it occurred. After we spotted that we notified the developer and it has now been resolved, so those relying on WPScan’s data and keeping their plugins up to date are protected despite not being told of what versions were really impacted.

07 Jul

Wordfence’s Lack of Understanding of SQL Injection Vulnerabilities Leads to False Claim About WP Statistics Vulnerability

Yesterday we touched on how the web security company Sucuri and others in the security community were overstating the threat of a vulnerability recently discovered by Sucuri in the plugin WP Statistics. While looking over something else related to that vulnerability we came across the web security company Wordfence using that vulnerability basically as an ad for their products and services, while reminding people that are actually knowledgeable  about web security that Wordfence really don’t have a good grasp of it.

Their post starts out:

It’s been a tough week for the WP Statistics plugin. Last Friday, Sucuri (now owned by GoDaddy) discovered a SQL injection vulnerability in the WP Statistics plugin version 12.0.7 and older. To exploit the vulnerability, an attacker needs to register an account (or use a compromised account) with subscriber-level access. They can then exploit a weakness in a WP Statistics shortcode to launch a SQL injection attack. This allows them to, for example, create an admin-level user and sign in to your website as an admin.

The vulnerability doesn’t allow someone to create an admin-level user, which is something that Wordfence should know considering shortly after that in the post they tout their plugin will protect against SQL injection vulnerabilities. If you don’t understand the basics of them, then you are not likely to be good at protecting against them.

They certainly shouldn’t be out there making claims that are false like this, but considering this company even goes to the level of claiming they care more about security than WordPress while making up a threat, it really isn’t surprising.

This isn’t all that complicated, here are the vulnerable lines of code in the plugin (as identified by Sucuri):

737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
switch ( $time ) {
case 'today':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d' )}' AND {$search_query}" );
	break;
 
case 'yesterday':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -1 )}' AND {$search_query}" );
 
	break;
 
case 'week':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -7 )}' AND {$search_query}" );
 
	break;
 
case 'month':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -30 )}' AND {$search_query}" );
 
	break;
 
case 'year':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -365 )}' AND {$search_query}" );
 
	break;
 
case 'total':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE {$search_query}" );
 
	break;
 
default:
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', $time)}' AND {$search_query}" );
 
	break;

In that code the value of the variable $search_query, which contains user input, is used in used in multiple SQL statements without being sanitized. The important part here is that the SQL statements are SELECT statements which allow reading data from a database, they don’t allow insert anything, so you can’t add admin user or anything else (the INSERT statement would be used to insert data). What you could do is slowly read out the contents of the database, which isn’t something that we see any evidence of hackers doing against the average website (it could be used in a targeted attack).

Wordfence Fails To Mention Many Plugin Vulnerabilities

While Wordfence’s post titled a “Vulnerability Roundup” they only mentioned vulnerabilities disclosed recently in two other plugins, both of which were already fixed, while not mentioning any of the  numerous vulnerabilities in plugins that were recently disclosed that haven’t been fixed. Telling someone to update a plugin that already has been fixed is really not all that helpful, since what you really should be telling people is to keep all of their plugins up to date at all times. When vulnerabilities haven’t been fixed that is when it would be useful to make people aware of the issue. As example of Wordfence of not warning about those unfixed vulnerabilities, here are just the vulnerabilities that we disclosed last week that haven’t been fixed:

If you used our service you would know about those vulnerabilities and many others that remain unfixed, including many that are likely to be exploited.

06 Jul

Sucuri and Others in Security Community Vastly Overstate Threat of WordPress Plugin Vulnerability

When it comes to dealing with web security, one of the big problems we see if that people don’t have a good understanding of what the risk of various threats are, often that seems to be due to security companies and others in the community. At its worst security companies are peddling false threats, but with real threats often seem more interested in driving up fear instead of providing accurate information. A good example comes from a vulnerability the web security Sucuri recently found, which in reality is almost no threat to the average website. But Sucuri and others would lead you to believe otherwise.

It Is an Authenticated Vulnerability

The problems start with the title of Sucuri’s post “SQL Injection Vulnerability in WP Statistics“, which isn’t accurate as the vulnerability is in fact an authenticated SQL injection vulnerability. That makes a big difference since the vast majority of WordPress websites don’t allow untrusted individual access to accounts, so only a small portion of those using the plugin could have been vulnerable.

That is particularly important when there is incorrect emphasis on how many are using a plugin when considering the threat of a vulnerability. That can be seen in some of the top tweets for this particular vulnerability:

Popularity Isn’t a Major Factor in What Vulnerabilities Get Exploited

The focus on the amount of installs was also emphasized by Sucuri, they even bolded the amount installs in their post:

While working on the WordPress plugin WP Statistics, we discovered a SQL Injection vulnerability. This plugin is currently installed on 300,000+ websites.

Unlike Sucuri we do monitoring to try to catch zero-day vulnerabilities in WordPress plugin (vulnerabilities that hackers are exploiting before the developer is aware of them), so we are aware of what vulnerabilities are actually being targeted. SQL injection vulnerabilities in general are not a common target and what could be done with this vulnerability is something we just don’t see hackers targeting against the average website. It could used in a targeted attack, but very few website are targeted, so the there is little risk from this vulnerability.

The reasons for this are not that complicated to understand. Hackers are generally looking to gain access to as many websites as possible, so they have interest is easy to exploit vulnerabilities and don’t have an interest in gaining access to a particular website. With this vulnerability someone could slowly read out the contents of the database, which alone won’t grant access to the website, since WordPress passwords are not stored in the database. Instead a hash of the passwords is stored in it, which a hacker would then need to crack to gain access.

Sucuri doesn’t come close to accurately reflected threat. Their rating way overblown:

DREAD Score: 7/10

Then in the section on if you are at risk is quite bad:

Are You at Risk?

This vulnerability is caused by the lack of sanitization in user provided data. An attacker with at least a subscriber account could leak sensitive data and under the right circumstances/configurations compromise your WordPress installation.

If you have a vulnerable version installed and your site allows user registration, you are definitely at risk.

That second sentence seems to be written in a way that while it is accurate, way overplays things. The reality is you are only at risk if you “have a vulnerable version installed and your site allows user registration”, but even then you wouldn’t be likely have the vulnerability exploited.

There isn’t any requirement that a security company overstate the threat of a vulnerability, we disclosed a vulnerability in this plugin back in April without having to go that route.

The popularity of a plugin matters so little that we see hacker trying to exploit vulnerabilities in plugins with less 100+ active installs. One of those attempts that we looked at explain part of why that is, hackers don’t even bother testing out vulnerabilities before exploiting them, so there is a good chance they don’t even know how many websites are using them. If you see someone making a big deal of the threat based on amount installs, that is good indication they don’t know what they are talking about or they are intentionally misleading.

Telling People to Update a Particular Plugin is a Bad Idea

In looking at the tweets there was big emphasis on needing to update the plugin, which is bad. It isn’t bad to update the plugin, but you really need to be keeping all of your plugins up to date at all times. As you often will not know if a new version of a plugin is a security update. For example, just last week when a security vulnerability in a security plugin we discovered was fixed the changelog entry for that was “bugfix”. That isn’t an outlier, as in 2015 we found that in a fifth of fixed vulnerabilities in WordPress plugins were not mentioned in the changelogs.

27 Jun

Pagely Downplays Serious Problems With The Handling of Security Vulnerabilities in WordPress Plugins

Security isn’t in great shape these days and that certainly applies to WordPress plugins as some recent issues we have run across have reminded us. As we see it, one of the causes of this is that real problems with security rarely get discussed. There are probably many factors at play to cause that, but one that we see is that people will criticize you if you say anything they interpret to be negative when it comes to security (the irony of that seems lost on them). That seems to lead to a lack of honesty about what is going on and instead a focus on happy talk that doesn’t resolve the problems, even though many could be fixed without much effort if there was an interest in doing that.

An example of not discussing the real problems comes up with a post we ran across from the blog of WordPress web hosting company Pagely. The post discusses the increasing issue with PHP object injection vulnerabilities in plugins, but hidden below the surface of the post is a couple of problems that writer clearly is aware of, but doesn’t disclose. The relevant section of the post is the following:

Full disclosure: I am the reporting party for some of the above vulnerabilities. One in 2016, and so far in 2017, seven. I took a weekend to see how many insecure usages of unserialize() I could find in the plugin code base and within hours had handfuls of working vulnerabilities; I stopped only so I could start triaging and notifying plugin authors regarding how to enact fixes. Many of which were appreciative for the help.

That all sounds nice, it just isn’t true in one important way and that gets to a couple of major problems with the security of WordPress plugin that people on the WordPress side of things don’t seem to be interested in dealing with.

If you look up the vulnerabilities the author is referring to you will find that only 2 of the 8 have been fixed. For the unfixed plugins it seems unlikely they are going to be fixed considering that the plugins last updates were years ago:

The position of the people running the Plugin Directory is that people shouldn’t be warned about unfixed vulnerabilities, but as these plugins show many vulnerabilities have little chance of ever being fixed. Their continued refusal to warn people of those or to update the plugins themselves, which they have the ability to do and we would be happy to help them with, means that websites are being hacked when the hack could have been prevented.

It is unclear why Pagely’s post doesn’t mention any of this, instead only saying of their interaction with developers of the plugins, “Many of which were appreciative for the help”.

The other piece to this that isn’t mentioned is that all of those unfixed plugins still remain in the Plugin Directory. According to the listings for those vulnerabilities that isn’t due to the Plugin Directory not knowing about them, “The original researcher notified WordPress Plugins team.”. There are numerous problems with how the team behind the Plugin Directory handles security issues, but we haven’t seen any interest from them to improve what they are doing. Again, that would be something we would be happy to help them with.

It would be great if going forward Pagely would be willing to be honest about was is going on and maybe help to push WordPress to start finally warning about plugins with known vulnerabilities (something we have trying to get them to for over five years).

Vulnerabilities Left Undiscovered

Something else worth highlighting from that post is this:

There are a lot of plugins out there, and a lot of vulnerabilities – I had to cut my research short just due to time constraints. If you’re a researcher interested in picking up or helping out with this issue (hunting vulns, writing PoCs and recommending patches), get in touch.

Doing that type of work takes a lot of time, unfortunately it is something that most WordPress based security companies don’t do much, if any, of. Instead far too often they seem to be focused on making up threats and then claiming they will protect against them, then doing anything toward dealing with real threats. We do a lot to find and fix vulnerabilities in plugins, we have disclosed 18 vulnerabilities this month, and we have recently started trying to be more proactive in catching vulnerabilities as they are being introduced in plugins. If we had more customers we could do more, whereas those other companies would probably spend additional money to do things that are not all that helpful to improving the security surrounding WordPress.