[GITLAB] — Just another SSRF issue.

Today I am going to talk about the second SSRF vulnerability that I have identified in Gitlab. Just to emphasize again that I’ve never considered seriously participating in bug bounty programs as a full-time job so I discovered all vulnerabilities by chance.

For the next few months, I am planning to spend a little bit more time on HackerOne in order to test myself and my knowledge. I think it is a good way to earn some extra money.

After reporting my first SSRF issue, I considered it worth spending some more time so I spent a few hours reviewing Gitlab’s functionality. I would rather conduct white-box testing because of the bigger possibility of finding vulnerabilities at all, but due to the lack of knowledge with Rails, I stuck to the Black-Box.

SUMMARY

The Gitlab Kubernetes page suffers from server-side request forgery due to improper restriction of the “API URL” field. This vulnerability could affect the application in such a way as to allow an attacker to perform ports scanning against the internal network or services.

Steps to reproduce

1. Create a project.
2. Open the newly created project and go to the “Operations -> Kubernetes” page.
3. Open “Add Kubernetes cluster”.
4. Go to the “Add existing cluster” page.
5. Fill in the “API URL” field with the following value “http://localhost:22”.
6. Press “Add Kubernetes Cluster”.
7. In order to be able to see the output, you will need to open the “Monitoring Page”.

Output — Monitoring Page

wrong status line: "SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u4"

The output confirmed that there was SSRF vulnerability.

Gitlab board decided to reward me $1,000 for this report.