Skip to content

Content injection via `Status checks` widget in Merge requests

HackerOne report #1628009 by yvvdwf on 2022-07-06, assigned to H1 Triage:

Report | Attachments | How To Reproduce

Triager's Note

  • In this update, the reporter indicates that he was able to accomplish the same exploitation against Browser performance, Load performance, Metrics reports, etc. Be sure to review this part of the report as well.
  • Additionally, there appears to be an inconsistency in successfully exploiting this vulnerability across the environments. For example, this was able to be confirmed in a current version of self-hosted EE and on .com, but not on staging. If there is a non-context-specific explanation for this behavior, please ping @galfaro2 so we can pass on this note to the H1 triage team.

Report

Content injection via Status checks widget in Merge requests

External Status Checks is a feature available only in Gitlab Utimate. Consequently the attacker need to hold an Gitlab utimate account to perform this attack (this can be achieved via free trials).

Service name in Status check allows attackers to inject any HTML content that is although sanitized latter by v-safe-html directive. There exists data-disable-with attribute that is not sanitized and allows attackers to inject any HTML content. Consequently attackers may get full XSS in the Gitlab self-managed instances that are not protected by a restricted CSP as I reported

Furthermore, the Status check is in merge requests, thus attackers may send arbitrary POST requests on behalf of victims. This leads to the possibility of admin user escalation or account takeover (when the account was created via a third party provider.

The following steps shows a demo of account takeover attack on Gitlab.com

Step to reproduce

  • These steps will be done on Gitlab.com. They require two things:

    • access to an utimate subscription (this can be achieved on Gitlab.com via a free trial)
    • a third party account that is not registered on Gitlab.com (such as, a Google, Github, Twitter, Bitbucket, or Saleforce user)
  • On an existing project or create a new project with Initialize repository with a README is checked

  • Goto Settings/General, then Merge request section, then click on Add status check button. Then fill the form as the following, then click Add status check:

    • Service name: <a class=js-issuable-todo data-create-path=/-/profile/password?_method=put&user%5Bnew_password%5D=12345678&user%5Bpassword_confirmation%5D=12345678>Service check
    • API to check: http://gitlab.com (or can be any url as you want)

status-check-setting.png

  • Now go back to the repository file list, then do some modification in README.md file as you want, then commit the modification in a new branch, such as dev with Start a new merge request with these changes is checked (please see the image)

edit-file.png

  • After clicking on Commit changesbutton, You will be redirected in a New merge request page. Click on Create merge request button.
  • You can expand Status checks tab, then click on Service check: http://gitlab.com link, you will see a POST request is sent to gitlab.com. This POST request will modify password of victim if the victim account is created via third party provider.

trigger-post-request.png

  • Now logout Gitlab.com, then login with a third party provider to generate a new account on Gitlab.com
  • (If the attack project is not public, then we need to invite the victim to be a member of the project so that the victim can access to the merge request page)
  • As the victim, visit the merge request page and click on the Service check: http://gitlab.com link as in Step
  • Refresh the page, you should now be logged out from Gitlab.com as your password was changed

Impact

HTML injection allows attackers to (1) get full XSS in the Gitlab self-managed instances that are not protected by a restricted CSP, or (2) to send arbitrary POST request on behalf of victims that can lead to permission escalation or even account takeover, etc.

Impact

HTML injection allows attackers to (1) get full XSS in the Gitlab self-managed instances that are not protected by a restricted CSP, or (2) to send arbitrary POST request on behalf of victims that can lead to permission escalation or even account takeover, etc.

Attachments

Warning: Attachments received through HackerOne, please exercise caution! %% REDACTED %%

Edited by Greg Alfaro