Transferred group to new owner / namespace - Allowing unauthorized SSO and SCIM token misused
HackerOne report #1791518 by vaib25vicky
on 2022-12-03, assigned to @cmaxim:
Report | Attachments | How To Reproduce
Report
Hi,
In the past I've submitted same issues(https://hackerone.com/reports/1258092) affecting Gitlab.com but those bugs become ineffective because of new unrelated changes are deployed. Gitlab.com is saved and instances don't allow Group saml sso at that time.
However, after 1 year, Gitlab self-hosted instances allow Group saml sso and same bugs resurfaced. Gitlab self-hosted instances are vulnerable now and not Gitlab.com
Summary:
Group with SAML SSO when transferred to new namespace as a child group then group SAML SSO setting options become invisible.
But all the previous config still works such as SSO and SCIM token
This bug can be exploited for three things
- Previous owner transferred the group to private namespace, he got kicked out of the new group but he can again SSO into the group with owner permission.
New owner can't stop him because SSO settings are invisible - Billing is associated with the parent group so when the group with SAML SSO transfer to the parent group on free plan, SSO still works and allows paid feature group SAML SSO and SCIM to use as free
- Since, group SAML SSO becomes invisible SCIM token can longer be reset so in case when SCIM token is known to previous users or got leaked
then token can be used to create new users in the group with higher permissions
Steps-to-reproduce:
You can also try my POC given below where most of the things are already configured and you just have to exploit. This is much simple poc and suggested to use for quick triage!
SCIM Token
- set-up group sso and creates SCIM token
- transfer the group to a new namespace/group as child group
- child group saml sso setting becomes invisible
- use the token to creates a new user (https://docs.gitlab.com/ee/development/internal_api/index.html#create-a-scim-provisioned-user) in the child group
curl --request POST "https://gdk.test:3443/api/scim/v2/groups/lakita-group%2Fmadie-group/Users" \
--data '{"externalId":"test_uid","active":null,"userName":"username","emails":[{"primary":true,"type":"work","value":"name@example.com"}],"name":{"formatted":"Test User","familyName":"User","givenName":"Test"},"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"meta":{"resourceType":"User"}}' \
--header "Authorization: Bearer <SCIM_TOKEN>" --header "Content-Type: application/scim+json"
User will be successfully created
SSO into new private group
- set up group sso and generate scim token
- transfer the group as a child group in different namespace (private group)
- remove previous owner, they can't access the private group
- change your idP config of the saml and replace old group path to the new one
- go the saml auth url directly and intercept the request
- change the path parameter with the new namespace
- continue the authorization process
On success, previous owner will again gain owner permission in the new private group where he didn't have any access initially
POC:
My Gitlab Instance [REDACTED]
Group named test
was a top-level group with saml sso configured. It was later transferred to group named group-two
. Previous user kicked out and since, test
group is now a sub-group, new owner can't access saml sso settings in test
sub-group and can't disable it.
Previous user log-in to their idP dashboard and initiate login to gain access to new private project privv
inside group test
- Okta user credentials:
Okta dashboard url - [REDACTED]
username - [REDACTED] password - [REDACTED]
- After login, click gitlab-group app to initiate sso. You will be redirected to login to gitlab instance.
Gitlab instance user credentials
username - [REDACTED]
password - [REDACTED]
-
You will be redirected and gets an authorization screen, don't authorize yet
-
Open burp and keep intercept ON
-
Now, click on authorize and change the parameter
?group_path=test
to?group_path=group-two%2ftest
and forward it. -
Continue the saml flow without any more changes. After sso flow is completed you will gain access to the group
test
and also private project inside it namedtest/privv
Impact
Old SAML SSO still active so users part of the idP can still SSO into new private group which belongs to different owners
Previous kicked out owner can again become owner and new owner can't stop because saml settings are invisible
Billing is associated with the parent group so when the group with SAML SSO transfer to the parent group on free plan, SSO still works and allows paid feature group SAML SSO and SCIM to use as free
Since, group SAML SSO becomes invisible SCIM token can longer be reset so in case when SCIM token is known to previous users or got leaked
then token can be used to create new users in the group with higher permissions
Thanks!
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: