[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.
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.