Skip to content

[Bypass] 1-click account takeover via XSS in the code editor in gitlab.com (bypass of CVE-2024-4835)

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #2517090 by matanber on 2024-05-23:

Report | How To Reproduce

Report

Summary

In report #2497024, I exploited the HTML file hosted at https://gitlab.com/assets/webpack/gitlab-vscode/0.0.1-dev-20240501001436/vscode/out/vs/workbench/services/extensions/worker/webWorkerExtensionHostIframe.html in order to get XSS in the gitlab.com origin. This was done by making the victim navigate to the file, with a malicious origin in the parentOrigin query parameter. Judging by the new behavior of this page, the fix that was implemented for that report involves checking intercepting every request to the vulnerable HTML file, and blocking it if the string parentOrigin=https://gitlab.com doesn't exist in it's URL. This fix is supposed to ensure that the value of the parentOrigin parameter is always set to https://gitlab.com and not to a malicious origin, but it fails to do so, as a request to a URL such as the following would not be blocked:

https://gitlab.com/assets/webpack/gitlab-vscode/0.0.1-dev-20240501001436/vscode/out/vs/workbench/services/extensions/worker/webWorkerExtensionHostIframe.html?&vscodeWebWorkerExtHostId=a&parentOrigin=https://peo.si&bparentOrigin=https://gitlab.com

Because an attacker can use a URL of that form to specify a parentOrigin parameter with a malicious value, the fix can be bypassed, and the attack described in report #2497024 can be performed.

Steps to reproduce
  1. As the victim, log in to your account in gitlab.com.
  2. Navigate to https://peo.si/gl/editor/bypass-poc-frame.html.
  3. Notice the API token which was logged in the console.
  4. Navigate to https://gitlab.com/-/user_settings/personal_access_tokens, and notice the malicious API token which was added to your account.
What is the current bug behavior?

A URL of the form https://gitlab.com/assets/webpack/gitlab-vscode/0.0.1-dev-20240501001436/vscode/out/vs/workbench/services/extensions/worker/webWorkerExtensionHostIframe.html?&vscodeWebWorkerExtHostId=a&parentOrigin=https://malicious.com is blocked, but a URL of the form https://gitlab.com/assets/webpack/gitlab-vscode/0.0.1-dev-20240501001436/vscode/out/vs/workbench/services/extensions/worker/webWorkerExtensionHostIframe.html?&vscodeWebWorkerExtHostId=a&parentOrigin=https://malicious.com&bparentOrigin=https://gitlab.com is not.

What is the expected correct behavior?

Any URL with a parentOrigin URL parameter which does not have a value of https://gitlab.com should be blocked.

Output of checks

This bug happens on GitLab.com

Impact

An attacker can take over a victim's GitLab account, with a single click (a navigation) from the victim.
This impact is identical to the impact described in report #2497024.

How To Reproduce

Please add reproducibility information to this section: