11 Dec

Vulnerability Details: Restricted File Upload in Woocommerce Pay.nl Payment Methods

Our Vulnerability Details posts provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

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 start using the service for half off for the first year when you sign up now. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

10 Dec

Our Improved Proactive Monitoring Caught Another Authenticated Option Update Vulnerability in a WordPress Plugin

Our Vulnerability Details posts provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

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 start using the service for half off for the first year when you sign up now. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

10 Dec

WPScan Vulnerability Database Weeks Behind in Warning About Exploited Vulnerability in WordPress Plugin

On Friday we noted that during the month of November we not only added many more new vulnerabilities in WordPress plugins to our data set than the widely used WPScan Vulnerability Database (50 to 11), but we actually disclosed more vulnerabilities ourselves than they added in total during the month (21 to 11). Considering that all the vulnerabilities we discover are publicly disclosed and you can even access a RSS feed just of them, it doesn’t speak highly of the quality of their data set to be missing them.

The handling of one of the vulnerabilities we disclosed is of particular concern for anyone relying on their data, as it was an option update vulnerability we disclosed on November 12 that looks to have been on hackers’ radar by at least November 15. It was only added to WPScan’s data on the December 7th:

That kind of thing has wider repercussions as you have people that unknowingly rely on their data in deciding whether to update plugins and wouldn’t even know about the limits of their data since they are not being properly warned about by companies reusing the data (it gets as worse as one company not warning their customers about the quality of the data actually goes further by lying and claiming that the WPScan data is “confirmed/validated” when it explicitly isn’t).

Also noticeable in that listing is that they fail to credit us, which isn’t a one off issue.

We disclosed a remote code execution (RCE) vulnerability on November 30, which WPScan falsely claims was publicly published on December 3 and which they only got around to adding on December 6:

The last of our recently disclosed vulnerabilities they managed to add seems to be missing more important information than attribution to us, as they list a vulnerability in Ultimate Member as being a cross-site request forgery (CSRF) vulnerability:

CSRF, involves causing someone else to take an action they didn’t intend to, so what you can do with that is rather important. For example, disabling an advertising notice in a plugin wouldn’t really be something anyone would care about. In this case though it would have allowed remote code execution (RCE), which is a fairly serious issue.

07 Dec

WordPress Support Forum Moderator Thinks Hiding Security Issues is a Bad and Good at the Same Time

When it comes to the mess that is the moderation of the WordPress Support Forum a central problem is the moderators seem to be unwilling to allow people to discuss things that disagree with their beliefs. So for example last week we mentioned how at first replies were deleted and then a whole topic closed when people put forward the idea that people shouldn’t be left in the dark about closed plugins. The moderator that seems to be at the heart of that was the frequently problematic, Jan Dembowski, who doesn’t believe that even asking about closed plugins is a valid support question (which we still don’t understand).

That same moderator popped up in the email alerts we have for the forum to monitor for discussions about security issues a couple of times in the last week where they seemed to highlight that these moderators are not thinking through what they are saying and doing, which is a big problem when they stop discussions that could help to avoid the unnecessary hacks of WordPress websites due to the poorly thought out actions of the WordPress Plugin Directory team (like occurred recently with plugins WP GDPR compliance and AMP for WP).

Here was that moderator putting forward the reasonable notion that security through obscurity doesn’t work a week ago:

This is really a bad idea and always has been. Securing your site keeps you safe, hiding things like that does not accomplish anything.

As this are areas of security to protect ones site and make it less easy to finding vulnerabilities on ones site.

That’s not security and would leave your site exploitable. The boys that probe your site do not look first, they just try the exploits that’s in it’s catalog.

Based on that you think that they would understand that hiding that there are unfixed vulnerabilities in WordPress plugins that hackers are exploiting would be a bad idea seeing as the hackers are going to exploit them even if people using the plugin are not aware of it, but here they were the day before saying you should never warn people about unfixed vulnerabilities:

When a plugin is taken down there is no information on the reason why it was done. I believe it has to be mandatory.

That’s not a good idea unless it’s something that has been resolved already.

 

It does not serve anyone’s interests to inform users about the vulnerability before it is remediated.

Those two things don’t go together, yet somehow this person just a day apart stating both of them.

If exploited vulnerabilities in WordPress plugin were always promptly fixed that stance would be of limited concern, but some of them never are and you can’t even discuss doing something about that on the forum either.

07 Dec

Closures of Very Popular WordPress Plugins, Week of December 7

While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in a recent instance were a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was due to a vulnerability.

This week one of those plugins was closed and has yet to be reopened.

Modula Image Gallery

Modula Image Gallery, which has 40,000+ installations, was closed on Wednesday. We found that security changes had been made after the closure, but the plugin was still insecure.

It has yet to be reopened.

07 Dec

Not Really a WordPress Plugin Vulnerability, Week of December 7

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.

Database Disclosure Vulnerabilities in ARI Adminer, BackWPup, Batch-Move Posts wp plugin, Caldera Forms, Cart66 Lite, Contact Us Page Builder, Events Made Easy, Exports and Reports, L4 Shopping Cart, Orbis, Paid Memberships Pro, Search Engine, Shopp, WP EasyCart, and WP Editor

Related reports of claimed database disclosure vulnerabilities were released for ARI AdminerBackWPupBatch-Move Posts wp plugin, Caldera FormsCart66 Lite, Contact Us Page BuilderEvents Made EasyExports and ReportsL4 Shopping CartOrbisPaid Memberships Pro, Search EngineShoppWP EasyCart, and WP Editor. While the person behind these reports believes that the file they are listing for each of the plugins is a database backups, in reality they are files that came with the plugins. It hard to understand how they didn’t realize that as the contents are exactly the same for the same plugin file on every website they listed, but they apparently didn’t.

06 Dec

Closure of Modula Image Gallery Leads to Disclosure of Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability in It

Last week we started monitoring for closures of the 1,000 most popular WordPress plugins and that alerted to us the plugin Modula Image Gallery, which has 40,000+ active installations and was closed yesterday. There have been two new versions released since it was closed. The first 1.3.4 has a changelog entry of “wp.org review” and there are quite a few security related changes made in that version.

In a quick check over the code none of them stood as being obviously related to a vulnerability as opposed to general security improvement and no possible security issues were picked up with our Plugin Security Checker, so we moved on to installing a copy of version 1.3.3 and seeing if there were any easy to spot vulnerabilities we could see by checking things that way. We almost immediately found that the plugin has had an authenticated persistent cross-site scripting (XSS) vulnerability, but a closer look showed that part of this isn’t fixed as of version 1.3.5.

The plugin allows users with the “edit_posts” posts capability to create new photo galleries, so normally users with the Contributor and Author roles would be among those allowed to do that. Those users normally wouldn’t have the “unfiltered_html” capabilities so they shouldn’t be allowed post JavaScript code in to pages, but they are allowed to do just that due to the “Custom scripts” portion of the gallery configuration:

As of version 1.3.4 there is some sanitization done with that, which limits some JavaScript code from being entered, but as the proof of concept below shows, JavaScript code can still run.

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 only trying to notify 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).

Also we hope this type of public disclosure might teach the WordPress folks that closing plugins and then having the changes made public before they are reopened is counterproductive to their stated goal with the handling of security issues in plugins (in one recent incident it looks like it led to websites being hacked).

Proof of Concept

When you set the “Custom scripts” portion of the gallery to the following an alert box when any available cookies to be shown in an alert box on the page with the gallery’s shortcode:

alert(document.cookie);
06 Dec

Here Is Yet Another Vulnerability Spotted by Our Plugin Security Checker in the WordPress Plugin Ultimate Member

The WordPress plugin Ultimate Member was the cause of too many websites being hacked back in August, we say too many because the developer didn’t promptly fix a vulnerability that was being exploited for some inexplicable reason. It probably then isn’t surprising that as we improve our Plugin Security Checker, an automated tool that you can use to check if plugins you use have possible security issues that should be further looked into, that Ultimate Member keeps getting flagged for additional possible security issues.

So far it has already flagged a reflected cross-site scripting (XSS) vulnerability, another reflected cross-site scripting (XSS) vulnerability, and a cross-site request forgery (CSRF)/remote code execution vulnerability.

Last Monday we mentioned that we had introduced a new check to that tool that identifies the possibility of some open redirect vulnerabilities while discussing an instance of authenticated variant of that in a plugin, which like Ultimate Member has 100,000+ installations according to wordpress.org. An open redirect vulnerability allows a request to one page to be redirected to an arbitrary URL, which is something spammers have been known to abuse. As part of our work to continue to improved our tool we take a look at instances of plugins being flagged by new checks to see make sure nothing is going wrong with those checks. That led us to confirming yet another vulnerability in Ultimate Member, an authenticated open redirect vulnerability, which isn’t likely to be abused, but exists in part due to a basic security failure with the plugin, which was also part of the cause of the last vulnerability we mentioned that was in the plugin. The vulnerability has gone unnoticed for nearly four years, as it has been in the plugin since its first version.

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 only trying to notify 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).

Technical Details

The plugin registers the function logout_page() to run when redirects should occur:

22
add_action('template_redirect', array(&$this, 'logout_page'), 10000 );

When that function runs, if you are requesting the plugin’s frontend logout page, normally /logout/, and are logged in, it will logged you out and redirect you to address specified by the GET or POST input “redirect_to” using the function wp_redirect():

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
function logout_page() {
 
	$language_code 		= '';
	$current_page_ID    = get_the_ID();
	$logout_page_id 	= UM()->config()->permalinks['logout'];
	$trid 				= 0;
 
	if ( is_home() /*|| is_front_page()*/ ) {
		return;
	}
 
	if ( UM()->external_integrations()->is_wpml_active() ) {
		global $sitepress;
		$default_lang = $sitepress->get_default_language();
		$language_code = $sitepress->get_current_language();
 
		if ( function_exists( 'icl_object_id' ) ) {
			$trid = icl_object_id( $current_page_ID, 'page', true, $default_lang );
		} else {
			$trid = wpml_object_id_filter( $current_page_ID, 'page', true, $default_lang );
		}
 
		if ( $language_code == $default_lang ) {
			$language_code = '';
		}
	}
 
	if ( um_is_core_page( 'logout' ) || ( $trid > 0 && $trid == $logout_page_id )  ) {
 
		if ( is_user_logged_in() ) {
 
			if ( isset( $_REQUEST['redirect_to'] ) && $_REQUEST['redirect_to'] !== '' ) {
				wp_logout();
				session_unset();
				exit( wp_redirect( $_REQUEST['redirect_to'] ) );

If the redirected address only be to an address on the same website, so what should be used there is wp_safe_redirect(), which only allows redirects to other addresses on the same website.

What also seems to be missing there is protection against cross-site request forgery (CSRF), as if you do a logout through WordPress it requires a valid nonce to do that, which is used to prevent CSRF.

Proof of Concept

The following proof of concept will redirect you to our homepage, when logged in to WordPress.

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

http://[path to WordPress]/logout/?redirect_to=https://www.pluginvulnerabilities.com
06 Dec

WordPress Plugin Security Review: Classic Editor

Recently we mentioned we are long overdue reviewing the security of the WordPress plugins we use, so here is the start of that. We start with a plugin that we didn’t expect to have any issues, but considering how many websites have started using it recently as well, it seems like a good place to start. That plugin being the Classic Editor, which “restores the previous WordPress editor and the Edit Post screen and makes it possible to use the plugins that extend it, add old-style meta boxes, or otherwise depend on the previous editor” and now has 600,000+ installations according to wordpress.org.

If you want a security review of plugins you use, when you become a paying customer of our service you can start suggesting and voting on plugins to get security reviews from us. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service. Through the end of the year you can get a free security review of a plugin or theme when you protect 100 websites with our service.

The review was done on version 0.5 of Classic Editor. We checked for the following issues during this review:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Security issues with functions accessible through any of the plugin’s shortcodes
  • Security issues with functions accessible through the admin_action action
  • Security issues with functions accessible through the admin_init action
  • Security issues with import/export functionality
  • Security issues with usage of is_admin()
  • Security issues with usage of add_option(), delete_option(), and update_option()
  • Host header injection vulnerabilities
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites
  • Any additional possible issues identified by our Plugin Security Checker

Results

We found no issues with any of the checked items in version 0.5 of Classic Editor.