**[HackerOne report #1628009](https://hackerone.com/reports/1628009)** by `yvvdwf` on 2022-07-06, assigned to `H1 Triage`: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#steps-to-reproduce) ## Triager's Note - In [this update](https://gitlab.com/gitlab-org/gitlab/-/issues/367408#note_1021167792), 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](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html) 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](https://hackerone.com/reports/1579645) 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)  - 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)  - After clicking on `Commit changes`button, 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.  - 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 %%