13 Jun

Simply Closing a WordPress Plugin With a Vulnerability Likely to Be Exploited Just Leaves Websites Open to Being Hacked

As part of making sure the customers of our service are getting the best information on vulnerabilities in WordPress plugins they may be using we monitor for hackers probing for usage of plugins on our website and then try to figure out what the hackers might be looking to exploit. A week ago that led to us running across two plugins with unfixed vulnerabilities. One of those plugins was closed on the WordPress Plugin Directory on May 9. In the past day we had saw a hacker probing for another plugin that was closed on the same day, Real Estate Manager – Property Listing and Agent Management.

What we found when went to look to see if there were any vulnerabilities in this plugin was nearly identical to what we found with the previous one, making it seem likely that they were both closed due to security issues discovered by the same party. Closing them and doing nothing else isn’t a solution, as what has happened with these plugin is yet another reminder of. This is a solvable problem, but the people currently running the WordPress Plugin Directory seem to be incapable of handling or even acknowledging the problem. One of the six people on the team running it, for example has claimed there is never a need to remove closed plugins:

To everybody else: most of the time when a plugin is delisted, it is not for a security issue. Taking pre-emptive measures like removing the plugin just because it was delisted is never really necessary.

Removing this plugin would have actually protected websites.

What might explain in part that is that person seems to be detached from reality, believing, strange things like that “magic wizards” find vulnerabilities:

Yes, not releasing exploits to the public protects people because *that’s actually true*. This isn’t complicated. Hackers are not magic wizards. They mostly exploit publically released things because they are given the means to do so. Look at the history. It’s very simple and obvious.

In this situation we can’t find the public disclosure of the vulnerabilities in this plugin and yet hackers would seem to be aware of them, so what is simple and obvious to that person is disputed by reality, for far from the first time.

One solution for this type of situation would be for the Plugin Directory to release a fixed version of the plugin when it has a vulnerability likely to be exploited if the developer isn’t fixing it in a timely manner. We have repeatedly offered to provide those fixes, so it would take minimal effort on their part, but that isn’t happening because of the people in charge.

Authenticated Settings Change

There is lot of insecure code in the plugin, but one obvious instance is like the vulnerability we mentioned last week and is a kind that hackers have been exploiting recently.

The plugin register for a function named save_admin_settings(), which is located in the file /classes/setup.class.php, to be accessible to anyone logged in to WordPress:

add_action( 'wp_ajax_wcp_rem_save_settings', array($this, 'save_admin_settings' ) );

As you can probably guess from the function’s name that will save the plugin’s settings. The problem is that there are no security restrictions on doing that:

function save_admin_settings(){
	if (isset($_REQUEST)) {
		$resp = array('status' => '', 'title' => '', 'message' => '');
		if (update_option( 'rem_all_settings', $_REQUEST )) {

There should be a capabilities check to limit low level users from being able to change the settings, a nonce check to prevent cross-site request forgery (CSRF), and sanitization for the new values for the settings.

Looking at the settings, one immediately stands out as to what hacker might use this for as it sets custom CSS, as has been the case with so many other similar vulnerabilities that isn’t escaped when output either, so you the authenticated settings change vulnerabilities leads to persistent cross-site scripting (XSS). That occurs in the files /assets/front/css/styles.php where the settings are first brought in:

$rem_settings = get_option( 'rem_all_settings' );

and then that setting is output:

<?php echo (isset($custom_css)) ? stripcslashes($custom_css) : '' ; ?>

That file is loaded when accessing front end pages of the website.

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 cause an alert box with the message “XSS” to be shown on frontend pages of the plugin, when logged in to WordPress.

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

http://[path to WordPress]/wp-admin/admin-ajax.php?action=wcp_rem_save_settings&custom_css=</style><script>alert("XSS");</script>

Concerned About The Security of the Plugins You Use?

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

Leave a Reply

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