:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.** **[HackerOne report #2627925](https://hackerone.com/reports/2627925)** by `joaxcar` on 2024-07-28, assigned to `GitLab Team`: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## Report #### Summary An attacker can gain full access to a victim account through `cross window forgery` [link](https://www.paulosyibelo.com/2024/02/cross-window-forgery-web-attack-vector.html) I previously reported a similar issue in #2383443 that was solved as CVE-2024-2177 in version 17.1.1. See the private issue here https://gitlab.com/gitlab-org/gitlab/-/issues/444467 The fix for #2383443 included removing the `id` attribute from the `authorize` button on the permission screen. However, the new `device authorization flow` introduced in 17.2 re-introduced the same issue with `id`s on the auth buttons. You can go to https://gitlab.com/oauth/device and inspect the button, it will look like this ```html <button id="commit-changes" testid="authorization-button" type="submit" class="gl-button btn btn-md btn-confirm "><span class="gl-button-text"> Authorize </span> </button> ``` note the `id` of `commit-changes`. This first page only accepts the device token, but if you enter any random token into the field and move authorize this page you will see that even the next page on https://gitlab.com/oauth/device/confirm (needs to be visited from the first page form submit) the button there also has the same `id` This new flow makes my old POC's functional again with some minor alterations. I will show this using my `captcha` POC from earlier, but an attack can also be done using a simple game or any other way to trick users into performing the user interaction. See #2383443 for more examples. #### Steps to reproduce 1. Create two accounts, `attacker` and `victim` 2. Log in as `attacker` and go to https://gitlab.com/-/user_settings/applications 3. Create a new `application`. Name it anything and fill out the form with anything, just make sure `confidential` is __not checked__ 4. Save it and take a note of the `application` ID 5. Log out and log in as the `victim` 6. Start a terminal and run this command (replace `<APPLICATION ID>`) ```bash CLIENT_ID="<APPLICATION ID>" curl -X POST https://gitlab.com/oauth/authorize_device -d 'client_id=$CLIENT_ID&scope=email&scope=api' -H "content-type: application/x-www-form-urlencoded" ``` 7. The response should look like this ```json {"device_code":"code","user_code":"code","verification_uri":"https://gitlab.com/oauth/device","verification_uri_complete":"https://gitlab.com/oauth/device?user_code=code","expires_in":300,"interval":5} ``` take a note of the `device_code` and the `user_code` 8. As the victim now visit this page `https://joaxcar.com/gitlab/click_attack_1.html?code=<USER_CODE>` (replace `<USER_CODE>`) 9. On the page follow the instructions to prove you are a human (holding down enter for approximately 3 seconds 10. Now back in the terminal run this command (replace `<DEVICE_CODE>` with device code from step 7 and `<APPLICATION_ID>` from step 4 ```bash DEVICE_CODE="<DEVICE_CODE>" CLIENT_ID="<APPLICATION ID>" curl -X POST \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=$CLIENT_ID&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=$DEVICE_CODE" \ https://gitlab.com/oauth/token ``` This should give you a response like this ```json {"access_token":"token","token_type":"Bearer","expires_in":7200,"refresh_token":"token","scope":"api","created_at":1722151585} ``` This token will now give the attacker full access to the victim. Test it with this command ```bash TOKEN="<access_token>" curl --header "AUTHORIZATION: Bearer $TOKEN" "https://gitlab.com/api/v4/user" ``` 11. As the victim go to https://gitlab.com/-/user_settings/applications and see that you have a new application with `api` access on your account here is the POC page if you want to self host REDACTED #### Impact The attacker gains full access to the victim's account through API (read and write) I put the CVSS to the same as the previous report as the impact is the same #### What is the current *bug* behavior? The Authorize button has an ID and can thus be the target of a fragment identifier. This allows for the "cross window forgery" attack #### What is the expected *correct* behavior? Removing the ID from the button will stop the attack #### Relevant logs and/or screenshots REDACTED #### Output of checks This bug happens on GitLab.com #### Impact The attacker gains full access to the victim's account through API (read and write) ## Attachments **Warning:** Attachments received through HackerOne, please exercise caution! REDACTED ## Solution proposal In addition to removing the ID attribute, we should add specs for the OAuth flow such that the consent forms don't get ID attributes added again in future, to avoid more regressions. ## How To Reproduce Please add [reproducibility information] to this section: 1. 1. 1. [reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues