High Security Risk: Privilege Escalation / Remote Password Change

[sarimkiani]

Any user can change credentials of other users including the Administrator credentials. This can allow the attacker to gain Administrator access and completely compromise the application.

Once logged in as a regular user or successfully registering as a new user, use the following URL to gain information (username) of other users: http://localhost/monstra-3.0.3/users/1

The digit '1' is of Admin or first user created in the database. By changing the digit, all registered usernames can be found.

Then by using the 'Edit Profile' option of own user account, password of any other user including the Administrator can be changed by changing the POST parameters 'user_id', 'login' and 'new_password'.

Code Flaw:

`In file monstra\plugins\box\users\users.plugin.php

Function: getProfileEdit

Line No: 233

  if (Users::$users->update(Request::post('user_id'),
        array('login' => Security::safeName(Request::post('login')),
              'firstname' => Request::post('firstname'),
              'lastname'  => Request::post('lastname'),
              'email'     => Request::post('email'),
              'skype'     => Request::post('skype'),
              'about_me'  => Request::post('about_me'),
              'twitter'   => Request::post('twitter')))) {

            // Change password
            if (trim(Request::post('new_password')) != '') {
                Users::$users->update(Request::post('user_id'), array('password' => Security::encryptPassword(trim(Request::post('new_password')))));
            }

            Notification::set('success', __('Your changes have been saved.', 'users'));
            Request::redirect(Site::url().'/users/'.$user['id']);

On editing profile user id is taken from Request::post('user_id'). An attacker can provide any user id on change password funcionality

Users::$users->update --> updates the password`

Header:

> POST /monstra-3.0.3/users/8/edit HTTP/1.1
Host: localhost
Content-Length: 152
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost/monstra-3.0.3/users/8/edit
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: COOKIE_SUPPORT=true; GUEST_LANGUAGE_ID=en_US; has_js=1; PHPSESSID=abtuklkn1r0rjbub01527gjav0; _ga=GA1.1.592562515.1457951975; login_attempts=i%3A4%3B

csrf=eb616fed8ca93d9de582a4f7d75ee3a3a0d6e3ec&user_id=8&login=user&firstname=&lastname=&email=&twitter=&skype=&about_me=&new_password=&edit_profile=Save

[mightyhaggis]

@sarimkiani The addition of a check on session variable for Admin or die should sort that?

[sarimkiani]

User ID should be taken/extracted from Session ID. I think that shall resolve the issue.