Patch time: Critical GitLab vulnerability exposes 2FA-less users to account takeovers

GitLab admins should apply the latest batch of security patches pronto given the new critical account-bypass vulnerability just disclosed.

Tracked as CVE-2023-7028, the maximum-severity bug exploits a change introduced in version 16.1.0 back in May 2023 that allowed users to issue password resets through a secondary email address.

Attackers targeting vulnerable self-managed GitLab instances could use a specially crafted HTTP request to send a password reset email to an attacker-controlled, unverified email address.

An attacker can complete the takeover without any user intervention, and those who haven't enabled two factor authentication (2FA) are prime targets for the opportunistic crime.

Users with 2FA enabled aren't vulnerable to account takeover, unless the attacker also had control of the 2FA authenticator, but a password reset could still be achieved.

GitLab doesn't support SMS-based 2FA – the most commonly hijacked implementation – only supporting app-based 2FA or that issued via a WebAuthn device, which are much more secure.

There are, however, a fair few versions of GitLab's Community and Enterprise editions that are affected and will require patching as soon as possible:

• 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

All authentication mechanisms are affected here, GitLab said, even some of those that use single sign-on (SSO).

"Users without SSO enforcement are vulnerable," GitLab said in its advisory. "If your configuration allows a username and password to be used in addition to SSO options, then you are impacted. Disabling all password authentication options via https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#password-authentication-enabled will mitigate the vulnerability for self-managed customers that have an external identity provider configured, as this will disable the ability to perform password reset."

Thankfully, at the time of disclosure, there was no evidence to suggest the bug had been successfully exploited, but as ever, when a vulnerability is made public, with an exploit as simple as this, wider exploitation attempts are likely and it becomes a race against the attackers to patch the flaw.

Since admins will need time to apply patches, without skipping upgrade stops to prevent instability issues from manifesting, a speedier stop-gap mitigation would be to mandate 2FA across all accounts as this will, in the vast majority of cases, prevent account takeover attempts.

Ideally, once that's enabled it will stay enabled for good, especially for key accounts like those with admin privileges.

We only need to look back to last week to learn the value of enabling 2FA – even the biggest names in security fumble the basics from time to time.

A takeover of a GitLab account could mean serious business for attackers, given the amount of intellectual property and source code belonging to organizations held in the DevOps platform.

• China loathes AirDrop so much it's publicized an old flaw in Apple's P2P protocol
• Number of orgs compromised via Ivanti VPN zero-days grows as Mandiant weighs in
• Why we update... Data-thief malware exploits SmartScreen on unpatched Windows PCs
• Exploit for under-siege SharePoint vuln reportedly in hands of ransomware crew

GitLab said customers can check their logs for signs of exploitation, highlighting two that will reveal any nefarious activity:

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

Since the vulnerability was brought to GitLab's attention via its bug bounty program, the company has added new tests to validate the password reset logic to prevent similar vulnerabilities from occurring in the future.

It's also started a root cause analysis process that it expects to generate additional follow-up actions to implement, as well as updating its documentation to improve awareness of the issue for engineers.

A second critical vulnerability was also addressed in the same round of patches. CVE-2023-5356 has been assigned a 9.6 CVSS score and allows attackers to execute slash commands in Slack or Mattermost.

While not as serious as an account takeover, a successful exploit could afford attackers the chance to add themselves into channels, potentially exposing an organization's secret work to unauthorized parties.

Organizations with custom apps and integrations that use slash commands could also leak sensitive data, depending on their function, for example.

Other, less-severe fixes also include:

• CVE-2023-4812: An issue has been discovered in GitLab affecting all versions starting from 15.3 before 16.5.5, all versions starting from 16.6 before 16.6.4, all versions starting from 16.7 before 16.7.2. The required CODEOWNERS approval could be bypassed by adding changes to a previously approved merge request.

• CVE-2023-6955: An improper access control vulnerability exists in GitLab Remote Development affecting all versions prior to 16.5.6, 16.6 prior to 16.6.4 and 16.7 prior to 16.7.2. This condition allows an attacker to create a workspace in one group that is associated with an agent from another group.

• CVE-2023-2030: An issue has been discovered in GitLab CE/EE affecting all versions from 12.2 prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2 in which an attacker could potentially modify the metadata of signed commits. ®