Retrospective: Joomla accounts modification and other disasters.

Hi, guys!

Today I want to tell you about last Joomla vulnerabilities. Issues I want to talk about are
I guess you already know about first three CVE because of Joomla is a very popular CMS around the world and these problems found a few month ago. But I have some words about exploitation and bug itself.
Let’s start with fast bug details.
There are two methods for user registration exists — UsersControllerRegistration and UsersControllerUser. You can find it inside /components/com_users/controllers/registration.php:108 and /components/com_users/controllers/user.php:293. The first method is legal and used by Joomla itself for user registrations. Second doesn’t call from anywhere but we can call it with a custom request to a server. To build it you need to take real register POST request then change task parameter from registration.register to user.register and use user array instead of jform.

Let’s cut to the chase.
New user created
New user created
Send it and a new user will be created ignoring allowUserRegistration = false setting. Welcome to the CVE-2016-8870 issue. Let’s look at the response details. Be cool and use var_dump as a debugger 😉
As you can see groups array parameter of a created user is exists. You can manually set group of a new user inside POST request like that:
Groups array rewrite
Groups array rewrite
Pay attention on group id. It’s 7 — Administrator. There is CVE-2016-8869. Unfortunately, you cannot create a user with Super Administrator privileges at once because JUser class have some checks to prevent that:

Now you can log in as created administrator and try to upload a file. Thanks to Xiphos Research Labs for shell file upload bypass with .pht extension (CVE-2016-9836). Guys from Xiphos also write the exploit to automate stack of CVE-2016-8869, CVE-2016-8870, and CVE-2016-9836 bugs.

It’s all good and very useful but waits for a second. What about CVE-2016-9081? The description says: “Incorrect use of unfiltered data allows for existing user accounts to be modified; to include resetting their username, password, and user group assignments”.
That’s right, we don’t need to create an account with only Administrator privileges because we can change login, email and password of existing Superadmin account.
For that operation, I need to know the only ID of that account. Where can I take it? The simplest way is register admin (ID=7), then log in administrator panel go to “Users” page and write down super admin ID. A piece of cake.
Let’s see to the POST request for change user data of existing account.
Rewritten user parameters
Rewritten user parameters
Look at the user[groups][] value. There is an empty line. It needs for preventing script to replace group ID with the default value (ID=2 — Registred).
But we have one more problem here. After user creation, it blocked and need to be activated. Token for that will be sent to email from the request. But Joomla doesn’t allow you to change super administrator account as we can already see. Let’s see to this part of code:

Variable $useractivation is reading from Joomla settings and our newly created admin can change it. Go to user registration settings and set New User Account Activation option to None.

New user activation off
New user activation off
After that, you can add user[block] to POST request for change user data and send it for successful exploitation of CVE-2016-9081 issue.
Super admin account
Super admin account
Edited super admin
Edited super admin

Voila, account successfully created without block!

During writing this article I found another similar issue — CVE-2016-9838. But for that time problem was in real registration method. Inside UsersControllerRegistration class I mean.
Look at this part of code:

If sent registration data doesn’t pass validation then it saves inside com_users.registration.data state. Whereas raw data from sent form is saving. Look at $requestData variable.

Next, this part of code extract data from com_users.registration.data state after valid data sent to registration:

With two special crafted registration request, an attacker can update data of any user. He only needs to know his user id or brute it.

Okay. That’s all for today. Thanks for reading and have wonderful holidays. See ya.
P.S. If you keep your eye on last security news you must know about PHPMailer < 5.2.20 RCE vulnerability. Joomla was not spared from that problem. See details here.