This is the first of three reports describing my findings from a review I did of Gitlab around 6 months ago. I thought I’d start with the simplest and the least impactful of them. Whilst this isn’t a high severity vulnerability, brute forcing credentials is a typical and low cost avenue of attack. Allowing credentials to be brute forced sometimes not only impacts the system with the weakness, but also potentially the network it’s deployed in as a whole. It’s very common for people to reuse credentials, so having one system inside a network with brute-forceable logins can weaken its overall security.

I found this flaw incidentally whilst exploring how Gitlab CI/CD pipelines authenticate against their core API. This happens via basic authentication, which for some endpoints is also a supported method for user authentication. For what looks like legacy reasons, this process doesn’t keep track of failed login attempts per user and instead opts for a global counter per IP address. This counter can be reset by sending a valid login request. The impact is that user logins without 2fa enabled can be infinitely brute forced without the ip address being banned or the user having a login cool-down period enforced.

The Nitty Gritty

The vulnerable code is in the IpRateLimiter class in the auth component.

On successful authentication, the function calls IpRateLimiter.reset! which clears the counter.

The issue here is that the counter is reset globally for that ip address, which effectively disregards the number of failed attempts made against a specific user. The other authentication methods supported by Gitlab typically increment the users.failed_attempts database field and enforce a cooldown period once a threshold is met. However, for basic authentication, so long as an attacker has one set of valid credentials to reset the counter per rack_attack.git_basic_auth.maxretry attempts (by default this value is 5), credentials can continue to be brute forced with impunity. By default Gitlab has open registration.