[jira] [Commented] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15647073#comment-15647073 ] 

ASF subversion and git services commented on CLOUDSTACK-9544:
-------------------------------------------------------------

Commit 0f89a8939fa618aa516523f21933fc7cabfe8a3a in cloudstack's branch refs/heads/master from [~marcaurele]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f89a89 ]

CLOUDSTACK-9544: Check access on account trying to generate user API keys

This fixes CVE-2016-6813

Signed-off-by: Marc-Aurèle Brothier <m...@brothier.org>
Signed-off-by: Rohit Yadav <ro...@shapeblue.com>
(cherry picked from commit 158497d68a92ab1e1f864a77371ea1de5c4dc5bb)
Signed-off-by: Rohit Yadav <ro...@shapeblue.com>


> 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)