Expose private project namespace through pipeline_id through creating vulnerability_feedback

HackerOne report #426172 by ngalog on 2018-10-20:

Summary: Gitlab EE introduced an awesome feature, that you can view the security scanning report directly from gitlab UI, and you can create/dismiss the finding respectively by clicking the issue itself. It is achieved by sending a post request to /:project_namespace/vulnerability_feedback. There is pipeline id inside the POST json payload, and this is where the bug happens.

Description: The POST request looks like this

POST /[REDACTED]/publicawesome/vulnerability_feedback HTTP/1.1
Host: gitlab.com
...
Cookie: ...

[REDACTED]

Notice the pipeline_id, you can change the pipeline_id to arbitrary pipeline_id, (in this case 33657997) that doesn't belong to your project, and then the private project namespace associated with that pipelie_id will be disclosed in the response, like this

{[REDACTED]
}

Now we can see the pipeline_id [REDACTED] belongs to project /[REDACTED]/, and this should be private, and not to be disclosed.

Steps To Reproduce:

• Fork https://gitlab.com/[REDACTED] and run a pipeline, and make sure you are running a premium gitlab user account
• Then go to security dashboard, and pick any issue, and dismiss vulnerability and intercept the request, the request should look like POST [REDACTED]vulnerability_feedback HTTP/1.1, change the pipeline_id in the POST data to random pipeline_id such as 1232, and change the project_fingerprint to other random value
• Finally you will be able to see the private project namespace in the response associated with the pipeline_id

This is little bit complicated to reproduce, I prepared a video for poc

Supporting Material/References:

[REDACTED]

Impact

Expose private project namespace through pipeline_id through creating vulnerability_feedback