[CLOUDSTACK-9544] Account API keys vulnerability in Cloudstack with possible privileges escalation

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 4.8.1.1, 4.9.0.1, 4.5.2.2
• Component/s: API
• Security Level: Public (Anyone can view this level - this is the default.)
• Cloudstack-CVSS: 8.5
• Assignee: Rohit Yadav
• Reporter: John Kinsella
• Created: 14/Oct/16 14:28
• Updated: 08/Nov/16 09:53
• Resolved: 27/Oct/16 14:43

Description

Reported by Marc-Aurèle Brothier to security@:

Hello,

I don't know if you would consider this as a vulnerabilities but I think it is one. Currently in all Cloudstack version, any user having access to the API can regenerate API keys for all user except the system one with ID=1, with the assumptions that he knows the UUID of the user. With the consideration that user knows another user UUID from a privilege domain, the attacker can change the api key of that user and then get the same access since he will receive the new key and secret in the API response for that privileged user. Therefore he can create a privilege account for himself after that call. From there, it's open bar It's the description of the worst case scenario.
Other cases would be to access to other accounts data/vm and invalidate api keys.

I think it is a vulnerability since the user UUID is not something supposed to be kept secret, and having the knowledge of this single uuid let you access to the ROOT domain pretty easily.

Human description to reproduce the case:
Search for a user in the ROOT domain and admin account of your cloudstack installation, and get the ID of a user, but not the admin one, or create a new user in this account.
Create or use another user from a different account/domain that does not have any privileged access, a normal account. Then using the secretkey and apikey from the normal user, issue a registerUserKeys id=<privileged user uuid> and see that you're getting a new pair of api & secret key.

The patch is pretty simple and attached to this email, 3 lines to change in one class to check the access of the account caller on the account associated to the user uuid in the request. The patch has been done on the file version on the master branch, and should be very easily back ported to all version since the code hasn't changed much in this method.

I haven't open any PR or bug of course to relate this finding. We will patch our own cloudstack version (the repo having this fix is private) today, that's all.

Let me know if you have any questions or for the follow up.

Kind regards,

Issue Links

• links to: GitHub Pull Request #1742