Description

When setting a password through /admin/users URI, the admin is not allowed to set their own new password through this URI. If they attempt to do so, they receive an error stating Forbidden to operate on yourself. But this is easily bypassable by interacting with the API: if you set a new password for another user, then change the user_id parameter within the request to the admin user ID.

The admin user is also able to suspend themselves by interacting with the API. This can be done by suspending a user, then changing the user_id parameter to their own user ID, such as 1 in my case.

Proof of Concept

{"password":"testingtest99","user_id":"1"}

Reproduction Steps

1. Go to /admin/users
2. Add a new user
3. Click action on the newly created user, then click Set new password
4. Open up your browser's network monitor & send the request to set a new password. The URI that the request will be made to is /answer/admin/api/user/password
5. Right-click the request, edit & resend it & modify the user_id parameter within the request to be the user ID of the admin user (in my case, it was 1)
6. Send the request

Notice that you are then logged out of the admin user account and cannot login with the old credentials again.

Not only are you able to set a new password for the user, but you are also able to suspend the admin account completely. Simply change the payload to:

{"user_id":"1","status":"suspended"}

Where user_id is the ID of the admin user

And change the API endpoint being sent the PUT request to: /answer/admin/api/user/status

Impact

By exploiting this vulnerability, an admin can bypass the web application's intended functionality and potentially lock themselves out of their account. Since the admin is also able to suspend themselves, this can also lead to a Denial of Service (DoS) attack since they will not be able to log back into their account.