Bingo, there is an ‘attachment’ section (shown below). Intuition guides us to start by looking at the ‘issues’ section, and the comment features surrounding them. Let’s navigate to Group 5, create a project, and then start looking for ways to create an attachment inside that project. ![]() Either way, once you’re done, the result should look something like this: While configuring these, you might start guessing about the nature of the bug - perhaps some kind of loop or path normalization, perhaps the names of each subgroup are concatenated in some weird way. It’s important to make sure that they’re nested. And secondly, a public project which is nested within at least five groups.Ĭreating five groups can be done with the root account.To reset the root account’s password, open up the container’s terminal and run: gitlab-rake "gitlab:password:reset" Reproducing the bugĪs we saw in the vendor advisory, an attacker requires two things: We can run this image with the following command: docker run -p 80:80 -hostname=hostname -env=PATH=/opt/gitlab/embedded/bin:/opt/gitlab/bin:/assets:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin -env=LANG=C.UTF-8 -env=EDITOR=/bin/vi -env=TERM=xterm -volume=/etc/gitlab -volume=/var/log/gitlab -volume=/var/opt/gitlab -label='.name=ubuntu' -label='=22.04' -runtime=runc -d gitlab/gitlab-ce:16.0.0-ce The ‘tags’ section reveals that a tag exists for the version we’re after - 16.0.0-ce. Setting up the target is refreshingly straightforward, thanks to the Docker images available from the official Gitlab DockerHub account. For this, we’ll be using Burp Suite and a local installation of the vulnerable software - Gitlab Community Edition v16.0.0. Given just the information that we are provided in the advisory, we wanted to see if we could reproduce the vulnerability. Why specifically five groups? Why not one, or twelve, or 1337 for that matter? The most unusual thing about this advisory are the conditions that were required for exploitation to take place. An unauthenticated malicious user can use a path traversal vulnerability to read arbitrary files on the server when an attachment exists in a public project nested within at least five groups. It’s an interesting one, so let’s get started right away, taking a look at what the vendor shares about the vulnerability: An issue has been discovered in GitLab CE/EE affecting only version 16.0.0. In this blog post we’ll be discussing a fresh vulnerability that has been issued an advisory by Gitlab with a CVSS score of 10.0 ( CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). Through our rapid PoC process, we enable our clients to understand if they are vulnerable to emerging weaknesses before active, indiscriminate exploitation can begin - continuously.įor the unaware, GitLab is a widely used, enterprise-grade web application for managing source code repositories at scale. It's our job to understand emerging weaknesses, vulnerabilities and misconfigurations - and quickly translate that knowledge into an answer to the question of "how does this impact our clients?". When we see impactful, exploitable vulnerabilities dropping out of the sky in typically critical systems - like GitLab - our attention is piqued. At watchTowr, some systems are interesting, and some systems are very interesting.
0 Comments
Leave a Reply. |