Skip to main content

CVE-2023-7028 - Critical GitLab Vulnerability

Introduction

Given GitLab's widespread usage and its significance to many of our customers, we deemed it important to provide an update on the latest security developments and patched vulnerabilities in GitLab.

This report focuses on CVE-2023-7028, a critical vulnerability in GitLab, posing a significant risk due to its ability to enable unauthorized account takeovers through a password reset mechanism. This flaw affects various GitLab versions, exposing a broad range of systems to potential exploitation. The discovery of CVE-2023-7028 was made through the organization's vulnerability reward program. The vulnerability requires no user interaction to be exploited. It has a CVSS score of 10.0, reflecting its critical severity. The issue originated from a change implemented in GitLab 16.1.0, which introduced password resets through a secondary email address. The vulnerability results from a bug in the email verification process, underscoring the need for immediate attention and remediation.

GitLab is a web-based DevOps lifecycle tool that provides a platform for source code management (SCM) and Continuous Integration and Delivery (CI/CD). It enables teams to collaborate on code development, issue tracking, and software deployment.

Affected Versions and Applications

The vulnerability impacts self-managed instances of GitLab Community Edition (CE) and Enterprise Edition (EE) in specific version ranges. Affected versions include:

  • 16.1 (before 16.1.6)

  • 16.2 (before 16.2.9)

  • 16.3 (before 16.3.7)

  • 16.4 (before 16.4.5)

  • 16.5 (before 16.5.6)

  • 16.6 (before 16.6.4)

  • 16.7 (before 16.7.2)

GitLab has released patches in versions 16.5.6, 16.6.4, and 16.7.2, along with backports to earlier affected versions. The bug was first introduced in version 16.1.0, dated May 1, 2023.

Risks

The vulnerability in question poses a substantial risk to organizations, particularly due to the widespread use of GitLab for storing proprietary code, API keys, and other sensitive information. Any security breach in such a system can result in severe data leaks and loss of critical intellectual property. Additionally, there is a heightened risk of supply chain attacks, where attackers could exploit this weakness to insert harmful code into repositories, especially alarming in scenarios where GitLab facilitates Continuous Integration/Continuous Deployment (CI/CD). This could lead to the direct implementation of compromised code in operational environments, amplifying the potential for extensive harm.

Mitigations and Recommendations

To mitigate the risks associated with the identified vulnerability in GitLab, it's crucial to upgrade all affected GitLab instances to the latest patched versions as soon as possible.

Additionally, enabling Two-Factor Authentication (2FA) for all GitLab accounts is strongly recommended. When 2FA is enabled, password reset is possible, but accessing the account still requires the second authentication factor for a successful login.

For organizations using Single Sign-On (SSO) in conjunction with username/password authentication, it's important to be aware of the risk. In such cases, disabling password authentication can be an effective mitigation step. For detailed instructions on disabling password authentication, please check the GitLab’s official documentation.

Signs of compromise

For defenders looking to identify signs of compromise related to the vulnerability in GitLab, here are specific things to check:

  1. Monitoring HTTP Requests in Logs:

    Examine the ‘gitlab-rails/production_json.log’ file for HTTP requests directed to the ‘/users/password’ path. Specifically, look for requests where ‘params.value.email’ consists of a JSON array containing multiple email addresses. This log file is a structured log that records Rails controller requests received by GitLab, which could indicate attempts to exploit the vulnerability.

  2. Audit Log Review:

    Review the ‘gitlab-rails/audit_json.log’ for entries where ‘meta.caller.id’ is ‘PasswordsController#create’. Pay particular attention to entries where ‘target_details’ include a JSON array with multiple email addresses. Adjustments to group or project configurations and changes in member statuses are recorded in this file, specifically within the 'target_details' section. This could indicate an exploitation attempt or unusual activity related to the vulnerability

Additional Vulnerabilities

In the latest GitLab security update, the main vulnerability CVE-2023-7028 and several additional CVEs were simultaneously patched. This inclusion gives a holistic overview of the security enhancements implemented in this update, ensuring that users are fully aware of all the security improvements made in GitLab. The severity of the vulnerabilities includes everything between critical and low

The additional addresses CVEs:

CVE-2023-5356: A critical vulnerability allowing users to execute Slack/Mattermost slash commands as another user, now patched in GitLab's latest release.

CVE-2023-4812: A high-severity issue enabling the bypass of CODEOWNERS approval in merge requests, now resolved in the recent GitLab update.

CVE-2023-6955: This medium-severity vulnerability allowed the creation of workspaces under different root namespaces, which has been addressed in the latest GitLab version.

CVE-2023-2030: A low-severity issue in GitLab where commit signature validation could be bypassed, now mitigated in the newest release.

For more detailed information, you can refer to the GitLab release notes here.

References

GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6

Critical GitLab flaw allows account takeover without user interaction, patch quickly! (CVE-2023-7028) - Help Net Security

GitLab Releases Updates to Address Critical Vulnerabilities

Urgent: GitLab Releases Patch for Critical Vulnerabilities - Update ASAP

GitLab warns of critical zero-click account hijacking vulnerability

Log system | GitLab

Log system | GitLab

GitLab.jpg

Back to all blogs

Featured blogs