GitLab Releases Security Updates To Fix Account Hijacking Flaw

GitLab, a web-based Git repository, on Thursday, released versions 16.7.2, 16.6.4, and 16.5.6 for GitLab Community Edition (CE) and Enterprise Edition (EE) to address two critical vulnerabilities, including one of them allowing account hijacking by resetting passwords without requiring any user interaction.

The first critical vulnerability — tracked as CVE-2023-7028 — has been awarded the maximum severity score (10 out of 10) on the CVSS scoring system.

This issue affects GitLab self-managed instances running GitLab CE/EE versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.3 prior to 16.3.7, 16.4 prior to 16.4.5, 16.5 prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2 in which hackers can effortlessly hijack accounts of any access privileges and send the account password reset emails to an unverified email address.

Security researcher ‘Asterion’ discovered and reported the vulnerability to GitLab via the HackerOne bug bounty platform. It first appeared in the May 1, 2023 release of GitLab version 16.1.0.

“The vulnerability was introduced in 16.1.0 on May 1, 2023,” GitLab security engineer Greg Myers shared in a GitLab security release after a change was made to allow users to reset their password through a secondary email address. “The vulnerability is a result of a bug in the email verification process.”

While users who have two-factor authentication (2FA) enabled are vulnerable to password reset, they are not susceptible to account takeover as their second authentication factor is required for successful login.

GitLab said it has fixed the security issue in GitLab versions 16.7.2, 16.5.6, and 16.6.4, and the fix has also been backported to GitLab versions 16.1.6, 16.2.9, and 16.3.7.

“Within these versions, all authentication mechanisms are impacted. Additionally, users who have two-factor authentication enabled are vulnerable to password reset but not account takeover as their second authentication factor is required to login,” Myers added.

While the vulnerability was resolved with the latest security release, the vendor strongly recommends admins of self-managed GitLab instances update all vulnerable versions to a patched version immediately. It also advises users to enable 2FA for all GitLab accounts (and especially for administrator accounts).

GitLab says it has not detected any abuse of CVE-2023-7028 on platforms managed by GitLab, including GitLab.com and GitLab Dedicated instances but shared the following signs of compromise for defenders:

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

GitLab also patched the second critical vulnerability identified as CVE-2023-5356 (CVSS score of 9.6 out of 10) as part of the latest update, which allows an attacker to abuse Slack/Mattermost integrations to execute slash commands as another user.

There are incorrect authorization checks in GitLab CE/EE from all versions starting from 8.13 before 16.5.6, all versions starting from 16.6 before 16.6.4, and all versions starting from 16.7 before 16.7.2.

Besides the above two critical vulnerabilities, GitLab also fixed the following three flaws in GitLab CE and EE versions 16.7.2, 16.6.4, and 16.5.6:

  1. CVE-2023-4812: This high severity issue (CVSS score: 7.6) existing in GitLab 15.3 and later, bypasses the required CODEOWNERS approval by adding changes to a previously approved merge request.
  2. CVE-2023-6955: This medium severity issue (CVSS score: 6.6) existing in GitLab prior to 16.7.2 due to improper access control allows an attacker to create a workspace in one group that is associated with an agent from another group.
  3. CVE-2023-2030: This low severity issue (CVSS score: 3.5) discovered in GitLab CE/EE affecting all versions from 12.2 and later could potentially allow an attacker to modify the metadata of signed commits due to improper signature validation.

To learn more about the latest security releases, click here for more information.

Kavita Iyer
Kavita Iyerhttps://www.techworm.net
An individual, optimist, homemaker, foodie, a die hard cricket fan and most importantly one who believes in Being Human!!!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Read More

Suggested Post