Fixed a vulnerability in GitLab that allows access to Runner tokens

several days ago in GitLab was unveiled via a blog post that researchers revealed the details of a vulnerability security now patched in GitLab, an open source DevOps software, that could allow an unauthenticated remote attacker to retrieve user-related information.

The main vulnerability, which is already registered as CVE-2021-4191, it is attributed to the medium severity flaw that affects all versions of GitLab Community Edition and Enterprise Edition since 13.0 and all versions from 14.4 and earlier than 14.8.

It was Jake Baines, a senior security researcher at Rapid7, who is credited with discovering and reporting the flaw, who after responsible disclosure on November 18, 2021, had fixes released as part of critical security releases. from GitLab 14.8.2, 14.7.4 and 14.6.5 which could allow an unauthorized user to mine registration tokens in GitLab Runner, which is used to organize call handlers when creating project code in a continuous integration system.

"The vulnerability is the result of a missing authentication check when executing certain GitLab GraphQL API requests," Baines said. mentioned in a report released Thursday. "An unauthenticated remote attacker can use this vulnerability to harvest GitLab registered usernames, names, and email addresses."

Additionally, it is mentioned that if you are using Kubernetes executors, you must manually update the Helm chart values. with the new registration token. 

And that for self-managed instances that aren't at versions 14.6 or later, GitLab has posted patches that can be applied to mitigate the disclosure of the Runner registration token through the vulnerability of quick actions  These patches should be considered temporary. Any GitLab instance should be updated to a patched version of 14.8.2, 14.7.4, or 14.6.5 as soon as possible.

Successful API leak exploitation could allow malicious actors to enumerate and compile lists of legitimate usernames belonging to a target which can then be used as a springboard to carry out brute-force attacks, including password guessing, password spraying, and credential stuffing.

“The information leak also potentially allows an attacker to create a new user wordlist based on GitLab installations, not only from gitlab.com but also from the 50,000 other Internet-accessible GitLab instances.”

Recommended to users who maintain their own GitLab installations to install an update or apply a patch as soon as possible. This issue was fixed by leaving access to quick action commands only to users with Write permission.

After installing an update or individual "token-prefix" patches, previously created registration tokens for groups and projects in Runner will be reset and regenerated.

In addition to the critical vulnerability, the new versions that were released also include fixes to 6 less dangerous vulnerabilities:

  • A DoS attack via the feedback submission system: an issue in GitLab CE/EE that affects all versions starting with 8.15. It was possible to activate a DOS by using the math function with a specific formula in the problem comments.
  • Adding other users to groups by a non-privileged user: which affects all versions before 14.3.6, all versions from 14.4 before 14.4.4, all versions from 14.5 before 14.5.2. Under certain conditions, the GitLab REST API can allow non-privileged users to add other users to groups, even if that's not possible through the web UI.
  • Misinformation of users through the manipulation of the content of Snippets: allows an unauthorized actor to create Snippets with deceptive content, which could trick unsuspecting users into executing arbitrary commands
  • Leakage of environment variables via the "sendmail" delivery method: Incorrect input validation on all versions of GitLab CE/EE using sendmail to send emails allowed an unauthorized actor to steal environment variables via specially crafted email addresses.
  • Determining user presence via the GraphQL API: Private GitLab instances with restricted registries may be vulnerable to user enumeration by unauthenticated users via the GraphQL API
  • password leaks when mirroring repositories via SSH in pull mode 

Finally if you are interested in knowing more about it, you can check the details in the following link


Be the first to comment

Leave a Comment

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

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.