Authentication Bypass Vulnerability Patched in User Registration Plugin

Note: To receive disclosures like this in your inbox the moment they’re published, you can subscribe to our WordPress Security Mailing List.

On September 16, 2021 the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability we discovered in “RegistrationMagic – Custom Registration Forms, User Registration and User Login”, a WordPress plugin that is installed on over 10,000 sites. 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.

On September 15, 2021, we released a firewall rule to protect Wordfence Premium customers from any attacks trying to exploit this vulnerability. This rule became available to free Wordfence users 30 days later, on October 15, 2021.

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.

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.

RegistrationMagic – Custom Registration Forms, User Registration and User Login Plugin is a WordPress plugin designed to allow for the creation of login and registration forms, facilitate user management including roles, and provide bulk emailing and integration with third parties for login. The plugin registers various AJAX actions to assist with these functionalities.

Unfortunately, one of these actions, intended to facilitate user logins via third party social providers such as Facebook, was insecurely implemented, making it possible for unauthenticated attackers to gain administrative access to an affected site on the condition that a login form created with the plugin was actively published on the site and an administrator’s email or username was known to the attacker.

Vulnerability Details

In order to exploit this vulnerability, a valid nonce was required, which could easily be obtained by accessing a login/registration page with a form generated by RegistrationMagic. On pages that had the login or signup shortcodes added, the nonce needed to exploit this vulnerability could be found in the generated source code of the page. It can reasonably be assumed that most site owners have a registration or login form enabled given the functionality of the plugin so this condition would almost always be met on sites using the plugin.

Taking a closer look, the AJAX action wp_ajax_nopriv_rm_login_social_user used for social logins is mapped to the function social_login_using_email with the following code:

public function social_login_using_email($user_email = null, $user_fname = null,$type=null) {
	$ajax_check = check_ajax_referer('rm-social-login-security', 'security'); // Check referer validity
	if($ajax_check == false) {
		$resp = array('code' => 'denied', 'msg' => __('Request denied','custom-registration-form-builder-with-submission-manager'));
		echo json_encode($resp);
		die;
	}
	if (isset($_POST['email']))
		$user_email = $_POST['email'];
	if (isset($_POST['first_name']))
		$user_fname = $_POST['first_name'];
	else
		$user_fname = null;
	$type= isset($_POST['type']) ? $_POST['type'] : '';
	$user_model= new RM_User;
	$gopts = new RM_Options;
	$resp = array('code' => 'allowed', 'msg' => '');
	$login_service= new RM_Login_Service();
	// error_log($user_email); error_log($user_fname);
	$user = $user_email;
	if ($user_email != null) {
		if (email_exists($user_email)) { // user is a member
			$user = get_user_by('email', $user_email);
			$user_id = (int) $user->data->ID;
			$is_disabled = (int) get_user_meta($user_id, 'rm_user_status', true);


			if (!$is_disabled){
				//$login_service->insert_login_log(array('email'=>$user->user_email,'ip'=> $_SERVER['REMOTE_ADDR'],'time'=> current_time('timestamp'),'status'=>1,'type'=>'social:'.$type,'result'=>'success'));
				$login_service->insert_login_log(array('email'=>$user->user_email,'username_used'=>$user_email,'ip'=> $_SERVER['REMOTE_ADDR'],'time'=> current_time('timestamp'),'status'=>1,'type'=>'social','result'=>'success','social_type'=>$type));
				wp_set_auth_cookie($user_id, true);
			}

This function accepted an email address or username as input along with a type, which was used later in the function for logging purposes. A quick nonce check was performed as a security measure and if the nonce was present in the POST request and valid, the check would pass. The lines that follow stored the email, username and type in variables for later use in the function.

If the $user_email variable was not empty, the function checked that the email address belonged to a user on the site. If the user existed, it would obtain the user’s id and ensure that the user account had not been disabled. If it wasn’t disabled, then wp_set_auth_cookie would set a cookie for that user, effectively logging in as the user identified by the provided email.

Unfortunately, there was no authentication of the user-supplied identity which made it possible for users to supply arbitrary email addresses and assume the identity of any user account present on the affected site. This included administrative user accounts which would allow attackers to completely takeover affected WordPress instances.

An attacker could therefore send a POST request to a vulnerable site, for example https://example.com/wp-admin/admin-ajax.php with the “action” parameter set to “rm_login_social_user”, the ”email” parameter set to ”admin@example.com” and the ”security” parameter containing the proper nonce and be logged in as the user identified by the email address admin@example.com, provided such a user account exists and is not disabled.

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.

Timeline

September 15, 2021 – Conclusion of the plugin analysis that led to the discovery of the authentication bypass vulnerability. A firewall rule is deployed to protect premium users.
September 16, 2021 – We initiate the responsible disclosure process. The vendor confirms the inbox for handling the discussions and the details are fully disclosed to the developer.
September 25, 2021 – The developer indicates the issue has been resolved, but after our analysis of the patch we determine the underlying security issues were not addressed properly.
September 26 – November 1, 2021 – We continue working with the developer to ensure a fix is released.
October 15, 2021 – The firewall rule becomes available to free Wordfence users.
November 1, 2021 – Version 5.0.1.6 is released, which provides a partial fix.
November 9 – November 25, 2021 – We continue to ask for updates to ensure that the developer continues to work on a patch. We involve the WordPress plugin team in our efforts.
November 25, 2021 – Version 5.0.1.8 is released and addresses the security issue.

Conclusion

In today’s post, we detailed a flaw in the “RegistrationMagic – Custom Registration Forms, User Registration and User Login Plugin” plugin that made it possible for attackers to bypass authentication and gain administrative user access. This flaw has been fully patched in version 5.0.1.8.

We recommend that WordPress site owners immediately verify that their site has been updated to the latest patched version available, which is version 5.0.1.8 at the time of this publication.

Wordfence Premium customers received a firewall rule for protection against any attacks targeting this exploit on September 15, 2021. This rule became available to free Wordfence users 30 days later, on October 15, 2021.

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.

If your site has been compromised by an attack on this or any other plugin, our Professional Site Cleaning services can help you get back in business.

*Please note that we have added AyeCode Ltd as a researcher to this post to provide them with credit for this discovery as well. They independently discovered the same vulnerability and reported it to the developers and WPScan in August of this year.