It doesn’t seem like it is too much to expect that a WordPress security plugin would not make your website less secure. But that is exactly what the plugin Easy Hide Login, which has 40,000+ active installations according to wordpress.org, does. The plugin “hides” WordPress’ login page, which isn’t something that you actually need to security wise. Since this isn’t something that you need to do, it really shouldn’t be surprising that someone developing such a plugin wouldn’t have a great understanding of security and that is the case with this plugin (and others in the past, as well).

We came across this plugin while looking for code relevant to an improvement to our Plugin Security Checker tool’s ability to detect issues with SQL injection, which is insecure code related to making queries of a database. The plugin’s code that came across while doing that doesn’t really make sense, as the plugin escapes its setting using esc_sql(), which is for escaping a value being used in a SQL statement:

118
119

$slug = esc_sql($_POST['slug']);
update_option('wpseh_l01gnhdlwp',$slug);

We can’t think of a reason that escaping function shouldn’t be used there.

That shouldn’t matter if the surrounding code was doing basic security checks, which you should expect would be true of a security plugin. But, that wasn’t the case with this plugin.

The plugin adds an options (settings) page to the admin area of WordPress, which runs the function wp_hide_login_plugin_option() when accessed:

107

add_options_page( 'Hide Login Options', 'Easy Hide Login', 'manage_options', 'easy-hide-login', 'wp_hide_login_plugin_options' );

That registration limits access to those with the manage_options capability, which is a capability normally only Administrators have.

That function begins this way:

111
112
113
114
115
116
117
118
119
120
121
122
123

function wp_hide_login_plugin_options() {
        if ( !current_user_can( 'manage_options' ) )  {
                wp_die( __( 'You do not have sufficient permissions to access this page.' ) );
        } 
 
   if (isset($_POST['slug'])) {
 
$slug = esc_sql($_POST['slug']);
update_option('wpseh_l01gnhdlwp',$slug);
 
   }
 
   $nonce = wp_create_nonce('easy-hide-login');

The first code in that checks again if the user has the manage_options capability, which is redundant, but not harmful. Next it checks if POST input “slug” exists and if it does, it runs the code from before and updates the plugin’s setting. Missing is a check for a valid nonce, to prevent cross-site request forgery (CSRF). The next line creates a nonce, which isn’t ever checked for in the plugin.

So through CSRF, an attacker could cause a logged in Administrator to change the value of the plugin’s setting. That is a security issue on its own, but it is made worse because of a lack of restriction on what the setting can be set to. That allows for cross-site scripting (XSS) to occur when the value is then output later in that same function without being escaped:

131

<input class="slug" name="slug" type="text" value="<?php echo get_option('wpseh_l01gnhdlwp','');?>" />

Since the setting value is to be used as part of a URL then checking that it only contains valid characters for a URL would be a good idea, not just from a security perspective.

WordPress Causes Full Disclosure

Because of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory 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. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.) 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 concept will cause an alert box with any available cookies to be shown on the page /wp-admin/options-general.php?page=easy-hide-login, when logged in to WordPress as an Administrator.

Replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/options-general.php?page=easy-hide-login" method="POST">
<input type="hidden" name="slug" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?