Explor-im GitLab

Explore is not a bug, it's a feature!

Holywar The topic of Gitlab's research functionality for anonymous users has been going on for several years since 2017. And closing this feature before 2020 was more of a crutch. But the problem was noticed and Explore and Help were closed for unauthenticated users through repository visibility settings (Covid played a certain role in this).

Fig. 1

Fig. 1

In Search of Secrets

Now that the introduction is over, let's move on to the research. The most obvious things to look for in Gitlab are tokens, API keys, and internal network information.

There were different things in the projects 🙂 :

Fig. 2. Disclosure of Gitlab login and password (https://login:pass@gitlab.example.com)

Fig. 2. Disclosure of Gitlab login and password (https://login:pass@gitlab.example.com)

Fig. 3. Disclosure of the DB login and password in the .sh file

Fig. 3. Disclosure of the DB login and password in the .sh file

Fig. 4. Revealing API keys in a .sh file

Fig. 4. Revealing API keys in a .sh file

Fig. 5. Shared Runner environment disclosure in .yml file – Ansible

Fig. 5. Shared Runner environment disclosure in .yml file – Ansible

And if, looking at the first three screenshots, everything is quite obvious (and I have not shown anything new), then the Shared Runner environment is of the greatest interest for exploiting a combination of vulnerabilities and executing remote code on the server. If the Shared Runner token is disclosed, we can contact Gitlab directly and intercept CI/CD process task session. This can help to gain initial access to the repository on behalf of the project user.

Shared Runners

Well, if the repository is empty for various tokens and secrets, then we go to the CI/CD section of the project and see what's in the Jobs:

Fig. 6 Another place for environment variable leaks

Fig. 6 Another place for environment variable leaks

Having CI/CD processes is already good and here you can build an interesting vector, which we will discuss in great detail told guys from Pulse Security.

And it was this vector that allowed me to get into the Pentest Award shortlist, as well as take a good bounty in one of the VK programs.

The main problem was access to this repository. Unfortunately, there was no leak of the Shared Runner token, but we, as cunning bug hunters, know that if it is possible to acquire legal access (yes, not Try Harder), it is not a pity to invest your own funds, which are more likely to pay off. And this was exactly such a case. Having fussed a little with entering my card data, I received the coveted credits and ran to test my theory of poheck 🙂 .

My theory was this: Shared Runners in Gitlab are part of the Pipeline process of the CI/CD environment.

Fig.7

Fig.7

For a hacker, this is a tasty morsel if:

1) The user has the right to write to .gitlab_ci.yml in the repository;

2) Runner is located in the internal infrastructure.

By default, GitLab Runners are available on a per-project basis. This means that an attacker does not need access to a specific repository to perform attacks. An attacker with any access to GitLab can create a personal repository and start attacking the runner infrastructure.

Fig. 8

Fig. 8

Moreover, as a rule, “docker-in-docker” is used for this (DIND) to create a container inside a pipeline.

I walked through the above diagram as a one-eyed Joe while studying CI/CD on the Gitlab server.

Pohhek 🙂

Having walked a little through the projects of the ill-fated repository, having taken the template .gitlab_ci.yml and having removed all the unnecessary stuff from there, I put together this gentlemanly set of letters:

Fig.9

Fig.9

Before performing any manipulations, it is important to click on the runner we need in the CI/CD repository settings.

We raise the nc on our Front Gun:

Fig.10

Fig.10

We launch the build and wait for our backconnect to arrive.

Fig.11

Fig.11

And we are in docker. The resulting shell is crooked and inconvenient. Therefore, we get a good TTY (how can we do without tabs and .bash_history):

And here we are walking around the Shared Runner environment. Of course, we don't get any impact from it, except for possible builds of other users. But we are in Docker, which means we need to upgrade to Docker host.

And in my case everything went quite trivially 🙂

We go to /var and see docker.sock lying by default.

Fig.12

Fig.12

This is where my eyes lit up! We set up the environment to run docker-ce:

And we enter the treasured command for profit:

Fig. 13

Fig. 13

I run in with root to see what's in /home and observe the infrastructure users.

Fig.14

Fig.14

There was no limit to my happiness and the report began to be written under the release of light adrenaline. Special thanks to the VK Bug Bounty team for the fast triage and excellent payout!

In conclusion

To fully understand the above chain of various misconfigurations and vulnerabilities, the following diagram can be used:

Fig.15

Fig.15

Returning to the second heading: “Explore is not a bug, but a feature!”, it is worth noting that this functionality, available to an anonymous user, is still a bug. It is extremely difficult to track all the processes and pushes that occur in Gitlab, as well as what data will be available to a “random” user. Therefore, you should take the privacy settings of your repository seriously.

Recent research Truffle Security is another “feature” affecting Github and including private Gitlab repositories, related to the disclosure of sensitive data in project forks, which suggests that these instances should be carefully closed from prying eyes and especially malicious hackers.

Let's make our RuNet safer! 🙂

Subscribe to telegram cyberokthere is still a lot of interesting stuff about cybersecurity and monitoring the surface of external attacks.

Dmitry Prokhorov

Penetration Tester, CyberOK.

Similar Posts

Leave a Reply

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