Vulnerability Management, Patch/Configuration Management, DevSecOps

GitLab vulnerability risks account takeover via simple password reset

Share
In this photo illustration, the GitLab logo seen displayed on a smartphone screen.

A GitLab vulnerability enables remote account takeover without user interaction due to a password reset flaw. Users of GitLab Community Edition (CE) and Enterprise Edition (EE) are warned to patch immediately due to the CVSS 10-scored bug.

The critical GitLab account takeover vulnerability was introduced in version 16.1.0 on May 1 when the DevOps platform added the option to reset a password through a secondary email address, according to a GitLab security release published Jan. 11.

"Account takeover can be achieved by crafting a specially formatted HTTP request that is capable of sending a password reset email to an unverified email address in an unpatched version," a GitLab spokesperson told SC Media.

The bug, tracked as CVE-2023-7028, is addressed in versions 16.5.6, 16.6.4 and 16.7.2 released Thursday, and was also backported to GitLab versions 16.1.6, 16.2.9, 16.3.7 and 16.4.5.

GitLab also recommends enabling two-factor authentication (2FA) on all accounts. Users with 2FA activated are not vulnerable to account takeover via CVE-2023-7028 exploitation but are still vulnerable to their password being reset by an unauthorized party.

The company said it has not detected any exploitation of the critical bug on GitLab.com or GitLab Dedicated instances, but users of self-managed GitLab instances will need to check their own logs to monitor for abuse.

"All affected customers were informed that a security patch would be released prior to January 11 to ensure their teams would be available and prepared to address it expeditiously," a GitLab spokesperson said.

GitLab credited user asterion04 for discovering and reporting the vulnerability through GitLab’s HackerOne bug bounty program.

How to check your GitLab logs for suspicious activity

GitLab customers with self-managed instances of GitLab CE or GitLab EE can check their logs for potential exploitation in the two following ways, according to the company:

  • 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 gitlabs-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

The platform said it has revised its password reset logic to prevent future vulnerabilities, including by not supporting the submission of multiple email addresses for reset links.

Critical Slack/Mattermost integration flaw among 4 other vulnerabilities disclosed

GitLab also advised users of four other vulnerabilities in its Thursday security release, including a critical vulnerability involving Slack and Mattermost integrations within GitLab CE and EE.

  • CVE-2023-5356 (CVSS score 9.6) allows Slack/Mattermost GitLab integrations to be misused to execute slash commands as another user.
  • CVE-2023-4812 (CVSS score 7.6) allowed CODEOWNERS approval to be bypassed by altering a previously approved merge request.
  • CVE-2023-6955 (CVSS score 6.6) enabled the creation of a workspace in one group that is associated with an agent from a different group.
  • CVE-2023-2030 (CVSS score 3.5) enabled the metadata of signed commits to be altered.

All of these issues are resolved by updating to the latest GitLab version.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.