Introduction
On January 11th, 2024, GitLab published an advisory for several vulnerabilities found in the products GitLab Community Edition and GitLab Enterprise Edition. Of particular interest is a critical vulnerability identified as CVE-2023-7028. This vulnerability allows remote, unauthenticated third parties to takeover any GitLab account by resetting the associated password with an unauthorized email address. A complete takeover of the compromised account is possible as long as no Multi Factor Authentication (MFA) is in place.
The simplicity of exploitation as well as the potential impact on an organization made CVE-2023-7028 receive a CVSS rating of 10, rating it as ‘critical’. The vulnerability was dutifully found and reported through GitLab’s bug bounty program by the user ‘asterion04’ (a link to the initial report on the bug bounty platform Hackerone can be found here).
Presenting CVE-2023-7028
GitLab is a platform that allows easy management of source code repositories, facilitating collaboration amongst developers. It is widely used for version control and project management, maximizing the throughput of software development teams. As so many other web-based platforms with a large user base, GitLab provides users who forgot their password with a password reset option where the user receives an email with a link to reset the password.
The password reset request contains an array that accepts the user’s email address as input, after which the GitLab instance sends a password reset link to the user’s email address. However, and this is where the vulnerability lies, the platform fails to properly check the user’s input on the server side and sends the password reset link to any subsequent email address that is listed after the legitimate user’s email address. So, by appending his email address to the victim’s email, the attacker is able to receive the password reset email, just like the victim.
Ultimately, the attacker only requires the correct value for the ‘authenticity_token’ field, as well as the victim’s email address, to succeed with the attack.
While the password reset is possible throughout all affected versions, the account takeover won’t work for entities that have MFA enabled.
Figure 1 Vulnerability POST /users/password (Source: TryHackMe)
Affected versions
The following versions of GitLab are affected by CVE-2023-7028:
- 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
Within these versions, all authentication mechanisms are impacted (source: GitLab’s security advisory).
CVE-2023-7028 step-by-step exploitation
Let’s take a look at a practical example on how to exploit CVE-2023-7028. This step-by-step guide can be found on the cybersecurity training platform TryHackMe in this dedicated room, which allows for a hands-on experience in a safe environment.
Step 1: Preparation
The exploit is only successful when the attacker has knowledge of the victim’s email associated with his GitLab account. So, as a first step, it is essential to obtain the correct email address for the victim.
Step 2: Prepare the exploit code
The GitHub user Vozec published an out-of-the-box working Proof-of-Concept exploit code for CVE-2023-7028, massively simplifying the steps an adversary has to take.
So, in a second step, the attacker will need to create a local copy of the exploit code.
Step 3: Execute the exploit script
Next, the attacker proceeds to execute the exploit script. The usage for the script is as follows:
|
python3 attack.py -u <URL to the vulnerable GitLab instance> - t <victim@mail.com> -e <attacker@mail.com> |
Figure 2 shows a successful exploitation of the exploit script.
Figure 2 Successful exploitation of CVE-2023-7028 with the provided exploit code (Source: TryHackMe)
Step 4: Reset the password for the victim
Upon successful exploitation, the attacker as well as the victim will receive an email prompting them to reset the password.
Figure 3 Password reset email sent to the attacker and the victim (Source: TryHackMe)
Step 5: Further actions on the victim
Once the attacker gained initial access, he can now start to take further actions on the victim’s GitLab instance. Here, the possibilities are almost endless. For instance, the attacker could introduce malicious code into existing projects, exfiltrate confidential information as well as user credentials, or even delete valuable data. Furthermore, the compromised account could be leveraged for further attacks against other users or systems.
Impact
The wide-ranging deployment of GitLab in combination with the public availability of an out-of-the-box working exploit code could have made this vulnerability highly impactful. Fortunately, most of the damage was prevented since the vulnerability was dutifully reported through the HackerOne bug bounty program. Thanks to this report, a patch could be developed before attackers gained knowledge of the vulnerability’s existence. GitLab stated in their security advisory that they could not find any successful exploitation on GitLab-managed instances, including gitlab.com. Self-hosted customers should review their logs, checking for possible exploitation attempts (source: GitLab).
A quick search (8th of February, 2024) on shodan.io shows that worldwide, more than 43’000 instances of GitLab are publicly accessible (see Figure 4). However, it is not known how many of these instances are still unpatched.
Figure 4 GitLab instances worldwide. Query: ‘product:GitLab’ (Source: Senthorus)
Currently, there are 319 publicly accessible GitLab instances in Switzerland, ranking Switzerland within the top 20 on the list of most GitLab instances per country.
Defending against CVE-2023-7028?
It is highly recommended to patch any self-managed, vulnerable version of GitLab Community Edition or Enterprise Edition to any of the following versions or higher: 16.1.6, 16.2.9, 16.3.7, and 16.4.5, in addition to 16.5.6, 16.6.4, and 16.7.2. Organizations that have their instances managed by the vendor itself have no need to take any immediate action as the GitLab-managed version is already running on the latest patch.
Further, organizations that do not have the MFA requirement set up are urged to implement this extra layer of defense since it has proven itself to be a valuable layer of defense.
To ensure immediate notification every time a patch is released, organizations can enable GitLab security alerts, allowing for early awareness.
Indicators of Compromise (IOCs)
Organizations that suspect a possible compromise:
- Check the web logs for API calls to ’/users/password’ with multiple email addresses.
- Inspect email server logs for messages from GitLab with unexpected recipients (possible attacker-controlled emails).
- Examine GitLab audit logs for entries containing ‘meta.caller.id’ as ‘PasswordsController#create’.
How Senthorus protects its customers
Most cybersecurity experts work in a 9-to-5 environment. Well, the bad news is that threat actors don’t. Critical vulnerabilities like CVE-2023-7028 can arise at any time, and not only during business hours. This is where Senthorus jumps in the breach, taking the lead in providing its customers with cyber defense made in Switzerland through full 24/7 monitoring of their infrastructure. On top of this, Senthorus’ registered customers benefit from Incident Response and Digital Forensics services, in direct collaboration with our analysts, available all year around, 24/7/365.
Summary
As shown in this article, CVE-2023-7028 could have had a big impact on many organizations worldwide. Mainly because an out-of-the-box working exploit code was shortly after released to the public, but also because the exploit does not require anything else but an email address associated with a GitLab account.
CVE-2023-7028 is a textbook example of why running a bug bounty program can strengthen security in a reactive way. Through the dutiful report and the immediate actions taken by the vendor, a patch could be developed and provided before any adversarial groups even knew of the existence of said vulnerability.
CVE-2023-7028 is a strong reminder of the dynamic nature of cybersecurity as well as the importance of the concept ‘Defense in Depth’. The simple implementation of MFA for an account protected it against its takeover, massively reducing the impact an attacker could have had on the compromised organization.
Lastly, we showed how Senthorus can help organizations level up their cyber defense capabilities through extensive 24/7 monitoring and incident response, helping them to always stay ahead in the ever-evolving world of cybersecurity threats.
