Gain access to private project when an attacker who has claimed an unverified email is invited

⚠ 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 #2118371 by theluci on 2023-08-21, assigned to @nmalcolm:

Report | Attachments | How To Reproduce

Report

Hello,
Member invitation by email address is vulnerable and allows user impersonation.

Background

Gitlab recently added a feature which allows a user to update his primary email while signing in.

Vulnerability

The reason behind CVE-2022-2326 was GitLab linking unverified secondary emails to users.
It was also acknowledged that unverified primary emails are also being linked to users. However, it wasn’t a security bug at that time because Gitlab didn’t allow to change an email to another email without verification.

Please read this comment.

20aug-1.png

However,
Gitlab has recently added a feature which allows a user to update his primary email while signing in.

20aug-2.png

For newly created accounts (with unverified primary email address), the feature isn’t available when using UI. However, if an attacker intercepts the request and modifies it, the attacker can update the primary email address associated with his account.

This allows the attacker to achieve the same impact as CVE-2022-2326, however, this time using unverified primary email linked to attacker’s account to gain access to a private project through an email invite and later updating the email to one of attacker’s owned email.

Attack Scenario

Similar to issue 356665.

Suppose there is company name xyz.org, all projects of this company are only accessible to its employees, that is those Gitlab accounts that have email addresses that match <employee_name>[@]xyz.org
Attacker can create an account with email address john@xyz.org which is an unverified primary email address and then all invitation to the john@xyz.org actually goes to the attacker and he gains access to the private projects of the company.
Attacker can later update his email to one of his owned email address attacker@attacker.com to complete sign in flow and gain access to the account.

Steps to reproduce

  1. attacker creates an account with email address john@gitlab-bounty.com.

This is the unverified primary email address linked to attacker account.

  1. victim creates a project named Gitlab-Bounty.

  2. victim invites member to the project by email address john@gitlab-bounty.com.

  3. attacker account gains access to Gitlab-Bounty.

  4. attacker sends the following request to update his email,

PATCH /users/update_email HTTP/2  
Host: gitlab.com  
Cookie: <COOKIES>  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0  
Accept: application/json, text/plain, */*  
Accept-Language: en-US,en;q=0.5  
Accept-Encoding: gzip, deflate  
Referer: https://gitlab.com/users/sign_in  
X-Csrf-Token: <X-Csrf-Token>  
X-Requested-With: XMLHttpRequest  
Content-Type: application/json  
Content-Length: 55  
Origin: https://gitlab.com  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin  
Te: trailers

{"user":{"email":"attacker_owned_email_address"}}

Be VERY SURE to replace attacker_owned_email_address
(Please watch the POC for clarification)

  1. attacker complete the sign in flow to gain access to his account

attacker has successfully managed to impersonate a legitimate employee of the company and gained access to the private project and repository.

POC

21aug-1.mp4

Output of checks

This bug happens on GitLab.com (Probably on instance too).

Impact

CVE-2022-2326 Bypassed - Gitlab doesn't check verified primary email address prior to matching them with Gitlab accounts and this allows an attacker to gain access to private projects with higher permissions and impersonate legitimate members of the project.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: