Skip to content

Enforce SSO settings bypassed for public projects for Members without identity

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

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

saml-enforce-sso.png

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.

saml-enforce-sso-1.png

saml-enforce-sso-2.png

<---------------------------------------------Important------------------------------------>
Lucifer Non-SAML is a member without identity.

saml-enforce-sso-3.png

When Lucifer Non-SAML tries to visit group with ultimate trial, he is shown the following,

saml-enforce-sso-4.png

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.

saml-enforce-sso-5.png

Lucifer-Attacker is a member of group-to-be-invited.

saml-enforce-sso-6.png

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,

saml-enforce-sso-7.png

Steps to reproduce

  1. victim creates a group victim-group and activates ultimate trial.
  2. victim goes to https://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)

  1. victim creates a public project victim-project inside victim-group.
  2. victim goes to https://gitlab.com/<victim-group>/<victim-project>/edit, Expand Visibility, project features, permissions and set all settings as Only project members.
  3. victim is a member of group-to-be-invited and attacker is a maintainer of group-to-be-invited
  4. victim goes to https://gitlab.com/groups/<victim-group>/-/group_members and clicks on Invite a group.
  5. victim invites group-to-be-invited with maintainer role.

Now, attacker is a member without identity of victim-group**.**

  1. attacker visits victim-group and is able to do that without SSO enforcement.

  2. attacker visits https://gitlab.com/groups/<victim-group>/-/settings/repository and changes some pre-defined push rules. (Shows that attacker has access without SSO sign in.)

  3. attacker visits victim-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.

  1. 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!

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 the group shared when accessing the group A or its subgroups/projects
  • a project member of project 1 which belongs to a group with SSO enforced tries to access the project 1 - SSO is not enforced and should be
Edited by Jarka Košanová