Lack of audit logging when /oauth/token endpoint is being misused
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Short description
A remote attacker without any privileges can lock a user account without the login attempts showing in the application_json.log (usually there is something like "Failed Login"
Discovery of this
I discovered this when I received a mail from my gitlab instance that my default-admin-account got locked because of too many failed login attempts. After looking at logs I discovered the attack.
Attack path
An attacker can simply use the following curl to launch the attack:
curl -X POST -d "grant_type=password&username=root&password=GIBBERISH&token[grant_type]=password&token[username]=root&token[password]=GIBBERISH" <gitlab-url>/oauth/token
I have included a -H 'X-CSRFToken: <CSRF taken from a request to /users/sign_in>, but I have not changed the value for subsequent requests, so I'm not sure if an attacker could even leave out this.
After running the request multiple times the account gets locked.
The reply from the server is the following:
{"error":"invalid_grant","error_description":"The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client."}The relevant log line from production_json.log
{"method":"POST","path":"/oauth/token","format":"html","controller":"Oauth::TokensController","action":"create","status":400,"time":"2024-12-18T20:48:40.623Z","params":[{"key":"grant_type","value":"password
"},{"key":"username","value":"root"},{"key":"password","value":"[FILTERED]"},{"key":"token","value":{"grant_type":"password","username":"root","password":"[FILTERED]"}}],"correlation_id":"01JFDRF8RTZFJXPE92Y8KAS
1GS", ...The root account in my instance did not have 2FA enabled.
What is very interesting is that in the value for token the username and password are repeated.
I haven't checked more than this, I wanted to submit this as soon as possible, in case this is a new attack that was just discovered.
Running Version
I am running gitlab-ce 17.6.2-ce.0 on a Debian machine, with an apache2 as webserver
Proposal
Update the audit logs to ensure such attacks are still logged to provide traceability if attempts are made resulting in a lockout.