Skip to content

Maintainer can leak webhook secret token by changing the webhook URL

HackerOne report #1758126 by joaxcar on 2022-11-01, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Summary

This is similar to my other report (hence the reused intro) but the attack vector and leak differs, thus the separate report.

Since this issue #359989 (closed) was merged webhook secrets are hidden for maintainers of a project after they are saved. The UI and API gives no way of retrieving the secret after configuration. Just like hidden tokens in integrations. The issue states

Use type="password" for the Secret token field input. We also have to make sure that the values are not exposed to the frontend

After the fix the input field only show a line of dots when trying to edit a webhook. But other maintainers can get the token by simply changing the URL of the configured webhook to an attacker controlled server, make a test request to get the token and then switch back to the original URL.

Similar token fields on integrations are reset if the URL is changed, forcing the user edeting the integration to resend any token. This should probably also happen here.

The docs states this about the secret

You can specify a secret token to validate received payloads. The token is sent with the hook request in the X-Gitlab-Token HTTP header. Your webhook endpoint can check the token to verify that the request is legitimate.

This change to the input field of the UI was made intentionally to hide the secret from other maintainers (as they do not necessarily have access to the receiving service). The leaked token (LOW confidentiality) gives an unauthorized other maintainer the ability to spoof requests to the receiving server (LOW integrity). And the impacted service is the receiving service (Scope changed). This was my rating of this, feel free to edit it as see fit!

Steps to reproduce

  1. Log in to gitlab
  2. Create a new project
  3. Go to https://gitlab.com/GROUP/PROJECT/-/hooks and configure a webhook. Make sure to add a secret
  4. Click save
  5. Scroll to the bottom of the page to the list of configured hooks.
  6. Click edit on the new hook
  7. You can now see that the secret is hidden
  8. Edit the URL to an "attacker controlled server" (i used https://webhook.site to catch the request)
  9. Scroll down to the bottom of the page and click save (you can not send a test request before saving)
  10. Scroll to the bottom of the page again and click edit again on the hook
  11. Now click "test" to send a test request
  12. Check your server to see that the request is sent to the new URL and containing the secret token

(13. If you are an attacker now change back the URL to the original URL)

Impact

Maintainers can leak secret tokens that should not be accessible after configuration

What is the current bug behavior?

Secret token are kept even if the URL is changed

What is the expected correct behavior?

The secret token should be reset if the URL is changed (as on integrations)

Relevant logs and/or screenshots

secret.png

Screenshot_2022-11-01_at_23.30.15.png

Output of checks

This bug happens on GitLab.com

Impact

Maintainers can leak secret tokens that should not be accessible after configuration, the user can use this token to send spoofed requests to the receiving server

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: