Real World GitLab Account Take Over

New target, this time it’s a company that provides VoIP solutions. The target has some serious clients like government organizations, banks and telecom providers. The company asked for an external engagement and the scope was pretty much every internet asset the company own.

The first day was about the reconnaissance on the target. To read more about some of the recon methodology I use, read this article. This time, the attack surface is not that big and the time to dig into every asset arrived. The most interesting assets that were found are:

target.comadmin.target.comapi.target.comstaging.target.comcl.target.com (clients login)git.target.com

I didn’t have a valid user to login as a client or employee, so I let my fuzzers to run at the background on most of the addresses, and I turned to check out the git subdomain.

GitLab hacking. Image by Gridinsoft.com

Accessing git.target.com reveals a normal GitLab CE login page:

Login Page

The first thing that stood up to me was the bottom of the page — Register now. I wondered if I could just create my own account and maybe accessing projects of authenticated users. In some cases that I had in previous engagements, after clicking on the registration link, I got some kind of a block — 403, Access Denied or error page. Luckily here I could access the real registration page:

GitLab Registration Page

Although I could successfully registering to the GitLab server, I didn’t get any activation email and the account was pending for the approval of the GitLab’s administrator.

Blocked Account

We all heard about the recent published CVEs of GitLab and now it’s time to check if one of them is relevant for this one.

The one of the latest CVE was Account TakeOver (CVE-2023–7028). Vulnerable GitLab versions to this CVE are:

16.1–16.1.516.2–16.2.816.3–16.3.616.4-16.4.416.5–16.5.516.6–16.6.316.7–16.7.1

Going back to the login page, I was checking the GitLab’s version by viewing the page source code and looking for the revision ID.

GitLab revision ID

Taking the revision ID to GitLab FOSS and searching it showed this result:

And then it also disclosed the GitLab’s version:

GitLab’s version from GitLab FOSS

Now we know that we are dealing with GitLab 16.2.1, which is on the vulnerable versions list!

According to the vulnerability description, the exploitation occurs by triggering the “Reset Password” functionality, combining with two email addresses — one for a valid GitLab user, and one for the attackers email address.

The vulnerable piece of code resides in spec/controllers/password_controller_spec.rb. The code is expecting a POST request containing an email address as a parameter, but without validating that there aren’t multiple email address in the list.

The Vulnerable GitLab Code

The exploitation causes to the GitLab server to send an email with a reset token to both email addresses, ending with an account takeover the minute the attacker clicks the link in his/her mailbox.

In order for the exploitation to work, the attacker needs to send a POST request to the /users/password along with:

a valid GitLab account email address (like user@target.com)the attackers email addressauthenticity_token for CSRF protection

Eventually, the request should looks like this:

POST request to account takeover

So now, we have a vulnerable GitLab server that we might use to takeover an account of one of the R&D staff, we just need to have a list of employees email addresses!

There are many ways to get valid email addresses of a company, especially if they are under the company’s domain.

First, let’s check what is the MX record of the target:

MX record of the target

Now that we know that the target is using its own domain address for email, let’s give theHarvester to work around.

Harvesting email addresses with theHarvester

theHarvester found only 6 results, and I couldn’t be sure that one of them is relevant for the GitLab server. So I used other sources (account needed):

hunter.iointelx.ioviewDNS.infogrep.app (search target’s email in GitHub repos)

I ended up with more than 80 email addresses of employees!

We have a lot of email addresses to try, each request requires also issuing a CSRF token, so it can’t be with Burp Intruder of something like that. We need a custom script.

Luckily there are some good PoC scripts in GitHub for this vulnerability, like this one here. All I need to do now, is just adding a small portion to the code to run a for loop that uses all the email addresses from a text file provided. I also added 2 minute sleep between each loop, so I’ll be able to see first if I got a recovery email in my mailbox before the script continue to takeover more than one valid account.

And then it happened, I got the email!

Reset Password Email From GitLab

I clicked the link and immediately got the reset password page:

GitLab’s Reset Password Page

Submitting a new password, and then going to the login page:

Login page after changing user’s password

That’s it, we’re in!

After logging in to the server, I was able to access all the company projects, without any permissions issues. I continued the engagement by downloading all the company’s code and extracting API keys and hardcoded credentials with TruffleHog.

The credentials extracted from the GitLab server were useful for accessing other assets of the company, especially the API and the clients subdomains. I was able to use all the company’s API with high permissions and to generate admin user for myself in the clients panel.

Target Pwned :)

For more content and hacking tips — follow me on X.