CVE-2023-36646: CVCN

Incorrect user role checking in multiple REST API endpoints in ProLion CryptoSpike 3.0.15P2 allows a remote attacker with low privileges to execute privileged functions and achieve privilege escalation via REST API endpoint invocation.

Introduction

The REST API endpoint used to modify CryptoSpike users suffers from the following vulnerabilities, which can be exploited from users with minimal privileges:

• no authorization checks on the user attributes modification, also including role assignments, leading to a privilege escalation up to the role of privileged administrator of the system;
• lacking input validation functionalities, allowing the modification of all users’ attributes (e.g. deactivate them, assigning privileged roles, etc);
• possibility to change the password of any user, including privileged ones;
• possibility to show the password hash of any user.

Additionally, the lack of accountability functionalities makes this vulnerability hard to investigate.

Steps to reproduce

For the invocation of the vulnerable REST API endpoints, a JWT Bearer Token of a user with minimum privileges will be used. In the example, a user with id 10 named “simpleuser” and only the “Monitoring” privilege set to READ (this privilege exclusively allows a user to check the status of CryptoSpike services) is created:

Invoking with PATCH http method the /users/:userId REST API endpoint under the service “AuthService” (https://hostname/api/v1/Server/auth/users/:userId) it is possible to send, as input, parameters that are not documented in API specification (for example, the attributes password, immutable). In our case, using the JWT Bearer Token of the user with id 10 and low privileges, it is possible to modify another user (with id 37 in the example). Please note that it is mandatory to include the parameter "roles":

The same endpoint has an issue with the output data, because on every successful invocation, it returns all the user data as stored in the database table. This data also includes the password hash of the modified user. It is also possible to modify other attributes not documented in the API specification: the “immutable” attribute to make a user not editable by other operators, “deletedAt” and “state” attributes do deactivate users.

With this data leakage vulnerability, it is possible to enumerate the password hashes of all users simply varying the :id parameter (for example, from 1 to 3000):

It is also possible to change the password of every other user by simply specifying the password on the JSON parameter, in clear text, including the default privileged user of CryptoSpike named “sysadm” (id equal to 1):

Invoking the same REST API endpoint specifying the current user id as parameter (in the example, using the JWT token of the user with id 10 on the /users/10 endpoint), it is possible to self-attribute the role with id 1 (“Administrator”), thus realizing a complete privilege escalation attack. It is also possible to set the parameter “immutable” to true, thus transforming itself into an immutable user against other users’ modifications.