GitLab released a fix for CVE-2021-4191, which is an instance of CWE-359, “Exposure of Private Personal Information to an Unauthorized Actor,” on February 25, 2022. GitLab versions since 13.0 were affected by the now-patched vulnerability. A missing authentication check when executing some GitLab GraphQL API queries caused the vulnerability. This vulnerability can be used by a remote, unauthenticated attacker to obtain registered GitLab identities, names, and email addresses. For this issue, we’ve assigned a CVSSv3 base score of 5.3.

A Metasploit module is available and we expect it to be used in the wild to harvest data and generate username lists. The exploit’s impact on its own is unlikely to be significant, but it could be significant when combined with brute force password guessing and credential stuffing attacks.

If the API information leak is successfully exploited, malicious actors may be able to enumerate and assemble lists of genuine usernames belonging to a target, which can then be used as a stepping stone for brute-force attacks such as password guessing, password spraying and credential stuffing.

  • November 2021: Initial discovery and confirmation by Jake Baines of Rapid7
  • Thu, Nov 18, 2021: Initial contact to GitLabs
  • Tue, Nov 23, 2021: Issue #1408214 opened with GitLabs with full technical details provided
  • Mon, Jan 17, 2022: Vendor indicated a fix is forthcoming, after a number of status updates through November and December
  • Tue, Feb 8, 2022: Fix prepared, tested, and ready for release in the next security update
  • Fri, Feb 25, 2022: Patch released for CVE-2021-4191
  • Tue, Mar 1, 2022: Metasploit Module PR#16252 submitted for CVE-2021-4191
  • Thu, Mar 3, 2022: Public disclosure (this document) for CVE-2021-4191.

Unless you plan on making GitLab available to the general public, make sure your GitLab instance is not accessible from the internet. Of course, we recommend that users update their GitLab server instances to the most recent releases as well (14.8.2, 14.7.4, and 14.6.5). Disabling public profiles is an effective overall defence against unauthenticated data collection.

Go to Admin Area -> General -> Visibility and access controls -> Restricted visibility levels to disable public profiles. Then select “Public” from the drop-down menu. Anyone who isn’t logged in should be unable to read user profiles.

Finally the researchers concluded that ,” The information leak might also allow an attacker to construct a new username wordlist based on GitLab instals not only from gitlab.com, but from the other 50,000 GitLab instances accessible through the internet. The patch also fixes six other security weaknesses, one of which is a major flaw (CVE-2022-0735, CVSS score: 9.6) that allows an unauthorised attacker to steal the runner registration tokens needed to authenticate and approve CI/CD jobs hosted on GitLab instances.

–-For more Cyber security news in crisp content . Please follow our site via twitter handle @cyberworkx1, Linkedin handle @linkedin

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s