An attacker can deny to create new access tokens on any groups or projects

HackerOne report #1777349 by u3mur4 on 2022-11-17, assigned to @nmalcolm:

Report | Attachments | How To Reproduce

Report

Summary

An attacker can deny to create new access tokens on any groups or projects (visibility doesn't matter).

Steps to reproduce

VICTIM ACCOUNT:

Sign in to a GitLab instance as victim user
Create a new Project (settings do not matter) and note the project id (eg.: 10)

ATTACKER ACCOUNT:

Sign in to a GitLab instance as attacker user
Go to "Edit Profile" => "Emails":
- To deny a project access token add a new email address as: project#{resource.id}_bot@noreply.#{Gitlab.config.gitlab.host} eg.: project10_bot@noreply.gitlab.192.168.1.201.nip.io
- To deny a group access token add a new email address as: group#{resource.id}_bot@noreply.#{Gitlab.config.gitlab.host} eg.: group10_bot@noreply.gitlab.192.168.1.201.nip.io

An attacker need to know the project id or the group id or use brute force approach. If there is already one or more access token created we need to add a number after the id. eg.: project10_bot1@noreply.gitlab.192.168.1.201.nip.io

VICTIM ACCOUNT:

Sign in to a GitLab instance as victim user
Go to the previously created project
Go to "Settings" => "Access Token"
Try to add a new Access Token

The victim user will get an error: Email has already been taken and cannot create new access token.

What is the current bug behavior?

I think the bug is that the generate_email function accepts the email address but later cannot create the internal account because another account has already added as unconfirmed secondary email.

https://gitlab.com/gitlab-org/gitlab/-/blob/a61973f86156edef29499ad0a6395f11b2e6f31f/app/services/resource_access_tokens/create_service.rb#L82

def generate_email  
  email_pattern = "#{resource_type}#{resource.id}_bot%s@noreply.#{Gitlab.config.gitlab.host}"

  uniquify.string(-> (n) { Kernel.sprintf(email_pattern, n) }) do |s|  
    User.find_by_email(s)  
  end  
end

Other internal users eg.: (alert_bot, security_bot, support_bot, etc...) also uses the User.find_by_email uniquify kernel but I did not find any security bug there yet.

What is the expected correct behavior?

the uniquify kernel should not accept email address where another user has already added the email as unconfirmed email address.

Output of checks

Access token only available on premium subscription so I didn't test it but I think github.com is vulnerable.

POC Video on a local GDK instance

victim project id: 10
gitlab host: gitlab.192.168.1.201.nip.io
email to add: project10_bot@noreply.gitlab.192.168.1.201.nip.io

video:

poc.mp4

Results of GitLab environment info

bundle exec rake gitlab:env:info RAILS_ENV=development  
System information  
System:    
Proxy:  no  
Current User: u3mur4  
Using RVM: no  
Ruby Version: 2.7.5p203  
Gem Version: 3.1.6  
Bundler Version:2.1.4  
Rake Version: 13.0.6  
Redis Version: 7.0.5  
Sidekiq Version:6.5.7  
Go Version: go1.19.3 linux/amd64

GitLab information  
Version: 15.6.0-pre  
Revision: 93afb8749d2  
Directory: /mnt/hack_data/gitlab-development-kit/gitlab  
DB Adapter: PostgreSQL  
DB Version: 14.5  
URL:  http://gitlab.192.168.1.201.nip.io:3000  
HTTP Clone URL: http://gitlab.192.168.1.201.nip.io:3000/some-group/some-project.git  
SSH Clone URL: ssh://git@gitlab.192.168.1.201.nip.io:2222/some-group/some-project.git  
Elasticsearch: no  
Geo:  no  
Using LDAP: no  
Using Omniauth: yes  
Omniauth Providers: google_oauth2

GitLab Shell  
Version: 14.13.0  
Repository storage paths:  
- default:  /mnt/hack_data/gitlab-development-kit/repositories  
GitLab Shell path:  /mnt/hack_data/gitlab-development-kit/gitlab-shell

Impact

an attacker can deny to create new access tokens on any groups or projects

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

poc.mp4

How To Reproduce

Please add reproducibility information to this section: