In a previous assessment, I identified that the application used a Gluu server for identity and access management. This was confirmed by the discovery of the /.well-known/scim-configuration endpoint. Users managed within the Gluu server had access to multiple applications, including the one assessed.

This was my first encounter with Gluu, and I spent some time reviewing its documentation. Gluu offers an API for querying users via a filter query parameter at /identity/restv1/scim/v2/Users, as outlined in the Gluu Server API Guide.

Due to a misconfiguration within the Gluu server, I was able to query user data without an active session or token.

Path to Account Takeover

While reviewing the Gluu documentation on building filters, I referenced the RFC 7644 for the supported operators.

I sent a request to /identity/restv1/scim/v2/Users?filter=userName+eq+%22admin%22&count=100&startIndex=1 and, to my surprise, no authentication was needed. The response returned an admin account.

When viewing the JSON response in the browser, I clicked the group URL (/identity/restv1/scim/v2/Groups/60A...), which exposed all users in the admin group. I then retrieved an admin user's ID and sent a PUT request to update the user.

To my surprise, the PUT request successfully updated the user’s password. I then logged into the admin account with the new password. The risk was critical, as no authentication was required for the API, and this vulnerability allowed anyone to view and potentially take over user accounts in a production environment, impacting access to various customer applications.

Remediation

The recommended remediation was to configure Gluu to require authentication for accessing the SCIM APIs. These endpoints probably should only be accessible to highly privileged users. Additionally, it may be advisable to prevent direct password changes on user accounts, enforcing updates through the dedicated password reset functionality—if Gluu provides an option to disable direct password changes.