[
https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614445#comment-15614445
]
ASF subversion and git services commented on CLOUDSTACK-9544:
-------------------------------------------------------------
Commit ec1d1e50c5bdea785fd5784700b47d561830ff46 in cloudstack's branch
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec1d1e5 ]
Merge pull request #1742 from shapeblue/cve-2016-6813
CLOUDSTACK-9544: Check access on account trying to generate user API keysThis
is to merge Marc's fix on 4.8+ branches.
Tests run:
$ nosetests --with-xunit --xunit-file=test-results.xml --with-marvin
--marvin-config=../marvin-cfgs/adv-kvm.cfg -s -a tags=role
--zone=Sandbox-simulator --hypervisor=Simulator
test/integration/component/test_accounts.py
==== Marvin Init Started ====
=== Marvin Parse Config Successful ===
=== Marvin Setting TestData Successful===
==== Log Folder Path: /tmp//MarvinLogs//Oct_27_2016_22_44_32_GVC833. All logs
will be available here ====
=== Marvin Init Logging Successful===
==== Marvin Init Successful ====
=== TestName: test_user_cannot_renew_other_keys | Status : SUCCESS ===
=== TestName: test_user_key_renew_same_account | Status : SUCCESS ===
=== TestName: test_updateAdminDetails | Status : SUCCESS ===
=== TestName: test_updateDomainAdminDetails | Status : SUCCESS ===
=== TestName: test_updateUserDetails | Status : SUCCESS ===
===final results are now copied to: /tmp//MarvinLogs/test_accounts_90CDC2===
* pr/1742:
CLOUDSTACK-9544: Check access on account trying to generate user API keys
Signed-off-by: Rohit Yadav <rohit.ya...@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)
