GitLab Account Takeover
Overview
The SonicWall Capture Labs threat research team became aware of an account takeover via password reset vulnerability in GitLab, assessed its impact and developed mitigation measures for the vulnerability. GitLab, an open-source code-sharing platform, published an advisory on this vulnerability affecting GitLab CE/EE versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.3 prior to 16.3.7, 16.4 prior to 16.4.5, 16.5 prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2. Considering the substantial user base as well as the existence of public POC, not only it is expected to be exploited in the wild, but it will also presumably join CISA’s Known Exploited Vulnerabilities (KEV) catalog. Because of this, GitLab users are strongly encouraged to upgrade their instances to the latest versions as applicable.
CVE Details
This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2023-7028.
The CVSS score is 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), based on the following metrics:
• Attack vector is network.
• Attack complexity is low.
• Privileges required is none.
• User interaction is none.
• Scope is changed.
• Impact of this vulnerability on data confidentiality is high.
• Impact of this vulnerability on data integrity is high.
• Impact of this vulnerability on data availability is high.
Technical Overview
This vulnerability was introduced in version 16.1.0 when the enhancement in the password reset function was made that enabled users to reset their password using a secondary email address. The flaw in the implementation of this process lets the threat actors abuse the password reset functionality and deceive the application into sending the reset link to the attacker-controlled email address by leveraging the parameter pollution technique.
To remediate the issue, new versions are being released with a patch (as seen in the commit) that enforces the password reset instructions to be sent to the users’ secondary email only if it’s confirmed, unlike previous versions. The password reset page of the patched version of GitLab reflects the same message as well, as seen in Figure 1.
Figure 1: Reset password instructions in vulnerable vs patched version
Triggering the Vulnerability
The only prerequisite for this attack is that the threat actor knows the victim’s email address. Combine that with the low attack complexity, and that makes exploitation of this vulnerability very straightforward. Additionally, the attackers can make use of ‘admin@example.com’, which is the default registered email address for the user ‘root’, to gain the highest privilege available – provided the user has not deleted the pre-registered email. The attacker then needs to construct the post request using the legitimate email address of the victim and their own email address to receive a password reset link. The sample URL-decoded request data would look like this:
Figure 2: Sample URL
Exploitation
The malformed password reset request, as demonstrated in Figure 3, needs to be sent to acquire the password-reset link of the victim account to the attacker-controlled unverified mailbox which yields an attacker access to the victim account by resetting the password.
Figure 3: Sample attack request
Two-factor authentication (2FA) can lessen the risk to an extent by denying the threat actor account access, but the underlying risk of the password being reset by an unauthorized user will still be present.
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature has been released:
- IPS:4229 GitLab Password Reset Attempt Using Multiple Email IDs
- IPS:4231 GitLab Password Reset Attempt Using Multiple Email IDs 2
Indicators of Compromise (IOC)
As mentioned in the vendor advisory, the users can access the following logs to check the potential attempts to exploit this vulnerability:
- Check gitlab-rails/production_json.log for HTTP requests to the /users/password path with value.email consisting of a JSON array with multiple email addresses as shown in below sample:{“method”:”POST”,”path”:”/users/password”,”format”:”html”,”controller”:”PasswordsController”,”action”:”create”,”status”:302,”location”:”http://gitlab.sw.local/users/sign_in”,”time”:”2024-01-16T09:53:16.121Z”,”params”:[{“key”:”authenticity_token”,”value”:”[FILTERED]”},{“key”:”user”,”value”:{“email”:[“victim@example.com”,”attacker@example.com”]}}],”correlation_id”:”08V0ZKAEAF9Q8QQ6X867DFS”,<truncated…>}
- Whereas normally a sample log for the legitimate request would look like: {“method”:”POST”,”path”:”/users/password”,”format”:”html”,”controller”:”PasswordsController”,”action”:”create”,”status”:302,”location”:” http://gitlab.sw.local/users/sign_in”,”time”:”2024-01-17T14:25:38.840Z”,”params”:[{“key”:”authenticity_token”,”value”:”[FILTERED]”},{“key”:”user”,”value”:{“email”:”user@example.com”}}],”correlation_id”:”01X0ECS3P6ZEF55YRA7XNNH”,<truncated…>}
- Check gitlab-rails/audit_json.log for entries with caller_id of PasswordsController#create and target_details consisting of a JSON array with multiple email addresses.
Remediation Recommendations
- Enable Two-Factor Authentication (2FA), a silver bullet to deny unauthorized access, for all accounts.
- GitLab released an update to address the issue, and it is highly recommended to update the application to version 16.7.2, 16.6.4, 16.5.6 or newer as appropriate. Notably, since this security fix has been backported to versions 16.1.6, 16.2.9, 16.3.7 and 16.4.5, the users can choose to update the application to those versions as well.
Relevant Links
- https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/
- https://github.com/Vozec/CVE-2023-7028
- https://gitlab.com/gitlab-org/gitlab/-/commit/394e91005d4a7b3df36be077aecf8a36acdee0f3
- https://gitlab.com/gitlab-org/gitlab/-/issues/16311
