Current Offer on Pentesting Exam: 90% Off on CAPenX

Understanding GitLab EE/CE Account TakeOver (CVE-2023-7028)

Understanding GitLab EE/CE Account TakeOver (CVE-2023-7028)

Hello readers! In this blog post, our Senior Consultants, Ravi and Punit talk about the recently discovered account takeover vulnerability identified in GitLab Community Edition (CE) and Enterprise Edition (EE). The blog talks about the vulnerability, covering its origin, potential risks, and the comprehensive measures GitLab has taken to address this critical issue in detail. The blog not only discusses the technical aspects of this vulnerability but also offers recommendations to fortify their GitLab instances.

By the end of this article, you’ll have a solid understanding of this vulnerability, as well as the techniques and tools needed to detect and exploit it. So, let’s get into the GitLab EE/CE Account Takeover (CVE-2023-7028) vulnerability and learn how to hack GitLab EE/CE like a pro!

TL;DR 

  • GitLab is vulnerable to a critical account takeover vulnerability, also known as CVE-2023-7028, which allows unauthenticated attackers to take over any user’s session by providing the victim user’s email address as an additional input during the password reset process.
  • The vulnerability primarily impacts users who do not have Two-Factor Authentication (2FA) activated or who use self-managed instances.
  • GitLab swiftly responded and issued a fix to address the identified issue. According to GitLab’s notification, all vulnerable GitLab instances must be upgraded to the newest version, and users must enable 2FA as an added layer of security.

Affected Versions

The following versions of GitLab EE/CE are affected by this vulnerability:

  • 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

How this Attack Worked Initially

First, let us understand what GitLab is and what is the root cause of the identified vulnerability.

GitLab is a web-based platform that provides a set of tools for managing source code repositories, facilitating collaboration among developers, and enabling continuous integration/continuous deployment (CI/CD) pipelines. It’s widely used for version control and project management, allowing teams to efficiently collaborate on software development projects.

As GitLab is a web-based platform that interacts with various users, it offers its users the ability to reset and recover their accounts if they lose their passwords. This is the primary region where the vulnerability exists, allowing an attacker to manipulate the password reset process and potentially gain unauthorized access to user accounts, including but not limited to higher-privileged users.

The figure below illustrates the whole attack cycle, explaining how it works and could be used to achieve account takeover.

Now that we have developed a high-level understanding of the vulnerability, let us dive into the more technical aspect of the underlying misconfiguration and understand how the vulnerability works. 

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 to recover the account. However, the platform fails to properly check the user’s input on the server side and sends the user’s password reset link to the attacker-controlled email address when the attacker’s email is provided as an additional email as input.

The affected input field and the payload are described below to develop a better understanding of the vulnerability:

Payload: user[email][]=victim@example.com&user[email][]=hacker@evil.com 

  • user[email][]=: This is the start of the payload, containing the parameter for the email address associated with the GitLab account.
  • victim@example.com: This is the legitimate email address of the target GitLab account, which the attacker is going to compromise.
  • hacker@evil.com: This is the attacker’s email address. Injecting this email in the payload allows the attacker to obtain the password reset link of the victim user.

Vulnerability Detection and Exploitation

Now that we’ve covered the theoretical aspects of the attack and have a solid knowledge of the vulnerability, let’s move on to the practical demonstration and see how the attack looks in real-time.

In Gitlab 16.1.0 community edition, navigate to the Login page and click the “Forgot your password?” option.

Enter the email address of the valid user whose account you want to reset, in this case it is “punit@grr.la ”as also shown in the screenshot below:

Click on the “Reset Password” button and intercept the password reset request using the Burp Suite proxy. The same has been demonstrated in the screenshot below:

Send the intercepted request to the Repeater tab, append the attacker’s email “punit7@gmail.com” to the “user[email][]” array, and forward the request, as shown in the screenshot below.

Payload &user%5Bemail%5D%5B%5D=punit%40grr.la&user%5Bemail%5D%5B%5D=punit7%40gmail.com

Visit the attacker’s mailbox and observe that the password reset email is received with two email addresses in the “to” section, as shown in the screenshot below:

Navigate to the victim user’s mailbox and observe that an identical mail is received in the email address “punit@grr.la” section, as shown in the screenshot below:

Understanding the Impact

This vulnerability allows unauthenticated attackers to perform an account takeover without requiring any interaction from the victim user and therefore is assigned a severity score of 10 on the CVSS scale.

For organizations with self-managed GitLab instances, a recommended course of action involves thoroughly reviewing logs to identify unusual behavior associated with password reset attempts by scrutinizing the gitlab-rails/production_json.log file.

A screenshot of a computer

Description automatically generated

Look for HTTP requests directed to the /users/password path with params.value.email containing a JSON array housing multiple email addresses. A second checkpoint involves the gitlab-rails/audit_json.log file, where entries with meta.caller_id labeled as PasswordsController#create and target_details featuring a JSON array with multiple email addresses could signify suspicious activity.

A screenshot of a chat

Description automatically generated

Mitigations and Best Practices

To prevent this vulnerability, the below-mentioned best practices and suggestions should be followed:

  • Immediately upgrade your GitLab instance to the latest patched version.
  • Multi-factor authentication should be enabled for all GitLab accounts, especially those with elevated privileges. This ensures that even if an attacker can perform a password reset on users with elevated access, the implemented 2FA will provide an additional layer of security.
  • Self-managed instances of GitLab must be upgraded to the latest version as soon as possible, as GitLab-managed instances have now all the security patches applied to prevent this vulnerability.
  • Review GitLab logs regularly, particularly the itlab-rails/production_json.log and gitlab-rails/audit_json.log, for any unusual behavior associated with password reset attempts.

References

  • https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/
  • https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-7028
  • https://docs.gitlab.com/ee/administration/logs/#production_jsonlog
  • https://nvd.nist.gov/vuln/detail/CVE-2023-7028
  • https://security.snyk.io/vuln/SNYK-DEBIANUNSTABLE-GITLAB-6153912
  • https://www.cert.ssi.gouv.fr/alerte/CERTFR-2024-ALE-002/
  • https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/critical-vulnerabilities-in-gitlab-products

Leave a Reply

Your email address will not be published. Required fields are marked *

Arrange a Callback

    Contact us
    Close