julien-f
commented
3 years ago Hello,
Sorry for the delay.
From what I understand, it's not a new issue and it's not a privilege escalation per se: API users can see all objects regardless of their permissions, the filtering is only done by the UI at the moment, but they cannot do any actions on objects they don't have the right to.
This is something we are actively working on fixing for the next major iteration of XO (v6).
Please see #502 for more information.
Context
Validated still vulnerable on version:
Expected behavior
Permissions enforcement through websockets is not thoroughly checked and can lead to an unprivileged 'user' to obtain data only accessible by 'admin'. VMs, Backups, Audit, Users, Groups, etc.
Current behavior
The websockets that control the application API are allowing access to certain elements based purely on the response (which can be manipulated). This would be similar to an ecommerce application taking the price of a shopping cart from the DOM (can be manipulated by the user) and starting the checkout process using this value).
In this POC, the method ‘resourceSet.getAll’ [Figure 1] responds with
"permission":"none"[Figure 2]. If an attacker changes the value of‘none’to‘admin’[Figure 3], the API opens up with further data and UI points [Figure 4]. This change in permission level persists through other API calls until theresourceSet.getAllmethod calls for permissions again (which should respond with “none”) unless the attacker changes it back to admin. Interestingly, the API limits some methods, returning with ‘not enough permissions’ but shows the user has ‘admin’ permissions [Figure 5].