GitLab has released patches to address multiple vulnerabilities for both the Community and Enterprise Edition. CVE-2023-7028 has been given a critical severity rating and a maximum CVSS score of 10. Successful exploitation of the vulnerability may allow an attacker to take control of the GitLab administrator account without user interaction.
Another vulnerability rated critical with a CVSS score of 9.6 is CVE-2023-5356. The vulnerability may allow an attacker to abuse Slack/Mattermost integrations to execute slash commands as another user.
GitLab is a web-based DevOps lifecycle solution built by GitLab Inc., providing unrivaled insight and productivity across the DevOps lifecycle in a single application.
GitLab has also addressed the following vulnerabilities in the recent patch:
- CVE-2023-4812: The vulnerability may allow an attacker to bypas CODEOWNERS approval by changing a previously approved merge request.
- CVE-2023-6955: Inadequate access control for workspaces allows attackers to link an agent from one group to a workspace in another group.
- CVE-2023-2030: Successful exploitation of the vulnerability involves the possibility of modifying the metadata of signed commits due to improper signature validation.
CVE-2023-7028: Account Takeover via Password Reset without user interactions
The vulnerability impacts the authentication mechanisms of the application. An attacker may modify the password if they obtain the token sent in the email.
The vulnerability originates from a flaw in the email verification process when resetting passwords. An attacker can provide two emails, and the reset code will be sent to both.
It is, therefore, possible to provide the email address of the target account and that of the attacker and reset the administrator password.
An example of the payload that can be used to exploit the vulnerability is code>user[email][]=
my*******@ex*****.com
&user[email][]=
ha****@ev**.com
GitLab uses the supplied email to look for a verified user. If the email consists of a single string, GitLab locates a verified user connected to that string and emails the reset token to that address.
If the email is an array of email addresses, GitLab uses the array to identify a verified user and then sends the reset token to each address in the array.
Users with two-factor authentication enabled are vulnerable to password reset but not account takeover, as their second authentication factor is required to log in.
Indicators of Compromise
GitLab has mentioned in the advisory that they have not detected any abuse of this vulnerability on platforms managed by GitLab, including GitLab.com and GitLab Dedicated instances.
Self-managed customers can review their logs to check for possible attempts to exploit this vulnerability:
- Check gitlab-rails/production_json.log for HTTP requests to the /users/password path with params.value.email consisting of a JSON array with multiple email addresses.
- Check gitlab-rails/audit_json.log for entries with meta.caller_id of PasswordsController#create and target_details consisting of a JSON array with multiple email addresses.
Affected Versions
- 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
Mitigation
GitLab has released versions 16.7.2, 16.5.6, and 16.6.4 to patch the vulnerability. The fix has also been backported to 16.1.6, 16.2.9, and 16.3.7.
For more information, please visit the GitLab release announcement page.
Qualys Detection
Qualys customers can scan their devices with QIDs 379244 and 379245 to detect vulnerable assets.
Please follow Qualys Threat Protection for more coverage of the latest vulnerabilities.
References
https://github.com/Vozec/CVE-2023-7028
https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/
