Enforce SSO settings bypassed for public projects for Members without identity
HackerOne report #2004158 by theluci
on 2023-05-27, assigned to @nmalcolm:
Report | Attachments | How To Reproduce | Specific cases details
Report
Hello,
I found that Enforce SSO settings can be bypassed for public projects for Members without identity using invite a group option.
Summary
According to the documentation.
When SSO settings are enforced for public projects, they need to be enforced for Members without identity (Members that are not part of the identity provider).
However, they are not enforced if members without identity are invited via invite a group option.
For example,
group with ultimate trial
is a public group with SAML SSO set up and enforce SSO-only authentication enabled.
<---------------------------------------------Important------------------------------------>
Lucifer Non-SAML
is a member without identity.
When Lucifer Non-SAML
tries to visit group with ultimate trial
, he is shown the following,
SAML SSO is enforced which is the expected behaviour.
<--------------------------- This is where the problem arises ------------------------->
group-to-be-invited
is a group invited to group with ultimate trial
.
Lucifer-Attacker
is a member of group-to-be-invited
.
Lucifer-Attacker
has access to group with ultimate trial
and is a member without identity.
When Lucifer-Attacker
tries to visit group with ultimate trial
, SSO settings are not enforced and he is able to do so,
Steps to reproduce
-
victim
creates a groupvictim-group
and activates ultimate trial. -
victim
goes tohttps://gitlab.com/groups/<victim-group>/-/saml
, setup SAML and enforce SSO.
(If you are having difficulty with setting up SAML, watch the following video how to setup SAML with Okta)
-
victim
creates a public projectvictim-project
insidevictim-group
. -
victim
goes tohttps://gitlab.com/<victim-group>/<victim-project>/edit
, Expand Visibility, project features, permissions and set all settings as Only project members. -
victim
is a member ofgroup-to-be-invited
andattacker
is a maintainer ofgroup-to-be-invited
-
victim
goes tohttps://gitlab.com/groups/<victim-group>/-/group_members
and clicks on Invite a group. -
victim
invitesgroup-to-be-invited
with maintainer role.
Now, attacker
is a member without identity of victim-group
**.**
-
attacker
visitsvictim-group
and is able to do that without SSO enforcement. -
attacker
visitshttps://gitlab.com/groups/<victim-group>/-/settings/repository
and changes some pre-defined push rules. (Shows thatattacker
has access without SSO sign in.) -
attacker
visitsvictim-project
and is able to do that without SSO enforcement.
10.1 attacker
is able to see the repository set as project members only, download it, fork it etc.
10.2 attacker
is able to create issues, merge requests, run pipelines etc.
10.3 attacker
goes to victim-project setting’s and is able to change project name, description & all the other settings.
Attacker is not able to edit the files in the repository directly but is able to do anything else that he has access permissions for.
- Attacker can create a project access token to edit the repository and affect integrity.
POC
Saml-sso-enforcement-bypass.mp4
In the above video, I have an ultimate trial so wasn't able to create a project access token, but it is possible.
<----------------------------------Important--------------------------------------------->
NOTE: To demonstrate impact I used attacker with maintainer role, however, it is not a necessity. Attacker with any role is able to bypass SSO enforcement and perform actions he has permissions for.
<----------------------------------------------------------------------------------------->
Output of checks
This bug happens on GitLab.com (Probably on instance too).
Impact
Enforce SSO settings bypassed for public projects if attacker has access via invite a group option.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
- saml-enforce-sso.png
- saml-enforce-sso-1.png
- saml-enforce-sso-2.png
- saml-enforce-sso-3.png
- saml-enforce-sso-4.png
- saml-enforce-sso-5.png
- saml-enforce-sso-6.png
- saml-enforce-sso-7.png
- Saml-sso-enforcement-bypass.mp4
How To Reproduce
Please add reproducibility information to this section:
Specific cases details
To clarify, we have an issue for following cases:
- a group (
group shared
) is shared to the group where SSO (group A
) is enforced (via invite group) and the SSO is not enforced members of thegroup shared
when accessing thegroup A
or its subgroups/projects - a project member of
project 1
which belongs to a group with SSO enforced tries to access theproject 1
- SSO is not enforced and should be