cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation
Date Fri, 28 Oct 2016 06:01:08 GMT


ASF GitHub Bot commented on CLOUDSTACK-9544:

Github user rhtyd commented on the issue:
    Merging this based on code reviews and tests on private@/security@, and test lgtm above

> Account API keys vulnerability in Cloudstack with possible privileges escalation
> --------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-9544
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API
>            Reporter: John Kinsella
>            Assignee: Rohit Yadav
>             Fix For:,,
>         Attachments: fix_api_keys.patch
> 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
> 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,

This message was sent by Atlassian JIRA

View raw message