[
https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614449#comment-15614449
]
ASF GitHub Bot commented on CLOUDSTACK-9544:
--------------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1742
> Account API keys vulnerability in Cloudstack with possible privileges
> escalation
> --------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-9544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544
> 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: 4.8.1.1, 4.9.0.1, 4.5.2.2
>
> 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 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,
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
