Simple password resets could result in an account takeover due to a GitLab vulnerability
Getting your Trinity Audio player ready...

A password reset vulnerability in GitLab allows remote account takeover without user interaction. Due to a CVSS 10-scored bug, users of GitLab Community Edition (CE) and Enterprise Edition (EE) are advised to patch right away.

According to a GitLab security release released on January 11, the DevOps platform added the ability to reset a password using a secondary email address on May 1, which is when the critical GitLab account takeover vulnerability was first discovered in version 16.1.0.

“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 spokesperson for GitLab stated.

The issue, identified as CVE-2023-7028, has been fixed in GitLab versions 16.1.6, 16.2.9, 16.3.7, and 16.4.5 as well as in versions 16.5.6, 16.6.4, and 16.7.2 that were made available on Thursday.

It is also advised by GitLab that all accounts have two-factor authentication (2FA) enabled. Users who have enabled two-factor authentication are not susceptible to account takeover through the CVE-2023-7028 exploit; however, they are still at risk of having their password reset by an unauthorized individual.

The critical bug on and GitLab Dedicated instances has not been exploited, according to the company; however, users of self-managed GitLab instances should keep an eye on their logs for any abuse.

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

Through GitLab’s HackerOne bug bounty program, user asterion04 found and reported the vulnerability, for which GitLab awarded credit.

According to the company, GitLab customers with self-managed instances of GitLab CE or GitLab EE can examine their logs for possible exploitation in one of two ways:

  • Look through gitlab-rails/production_json.log for HTTP requests with params., JSON arrays containing several email addresses, made to the /users/password path.
  • Examine gitlabs-rails/audit_json.log for entries containing the JSON array with multiple email addresses, target_Details, and of PasswordsController#create.

The website announced that to guard against future vulnerabilities, it has updated its password reset logic. One change is that it no longer accepts the submission of multiple email addresses for reset links.

GitLab alerts users to a serious vulnerability

GitLab has addressed two serious vulnerabilities, one allowing account hijacking without user interaction, by releasing security updates for both the Community and Enterprise Editions.

The vendor warns that if “no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, this means all types are affected” and strongly advises updating all vulnerable versions of the DevSecOps platform as soon as possible (manual update required for self-hosted installations).

The most important security concern GitLab patched is being tracked as CVE-2023-7028 and has the highest severity score (10 out of 10). There is no interaction necessary for successful exploitation.

It’s an authentication issue that allows requests for password resets to be sent to random, untrusted email addresses, thereby facilitating account takeover. Resetting the password is possible if two-factor authentication (2FA) is enabled, but successful login still requires the second authentication factor.

Since GitLab is frequently used to host proprietary code, API keys, and other sensitive data, taking advantage of an account hijacking can have a major effect on an organization.

Another risk is supply chain attacks, wherein when GitLab is used for CI/CD (Continuous Integration/Continuous Deployment), attackers can compromise repositories by inserting malicious code in live environments.

Security researcher “Asterion” found the problem and reported it to GitLab through the HackerOne bug bounty platform. Version 16.1.0 of the update was released on May 1, 2023.

Affected versions are the following ones:

  • 16.1 before 16.1.5
  • 16.2 before 16.2.8
  • 16.3 before 16.3.6
  • 16.4 before 16.4.4
  • 16.5 before 16.5.6
  • 16.6 before 16.6.4
  • 16.7 before 16.7.2

GitLab versions 16.7.2, 16.5.6, and 16.6.4 were the first to address the flaw, and versions 16.1.6, 16.2.9, and 16.3.7 have also received a backport of the solution.

Slash commands function as shortcuts for launching apps in the Messaging Composer Box in Slack, and they enable integrating external applications into the workspace in Mattermost.

The remaining issues that GitLab resolved in version 16.7.2 are as follows:

  1. CVE-2023-4812: A high-severity vulnerability in GitLab 15.3 and later versions that allows one to modify a previously approved merge request to avoid CODEOWNERS approval.
  2. CVE-2023-6955: Inadequate access control for workspaces created in GitLab before version 16.7.2, which makes it possible for attackers to link an agent from one group to a workspace in another group.
  3. CVE-2023-2030: An issue with commit signature validation that affects GitLab CE/EE versions 12.2 and higher, about the potential for incorrect signature validation to change the metadata of signed commits.

Leave a Reply

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