SSRF when importing a project from a git repo by URL
- Title: SSRF when importing a project from a git repo by URL
- Types: Design Issue, Information Disclosure, Missing Best Practice
- Link: https://hackerone.com/reports/135937
- Date: 2016-05-03 06:49:04 -0400
- By: strukt
Details:
Hello,
There's an SSRF bug that allows for scanning internal ports of the server in the project importing from a repo URL functionality, following are the steps to reproduce:
-
Login to your GitLab account and create a new project, then go to https://gitlab.com/{username}/{projectname}/import/new, where username is your username and projectname is the name of the newly created project.
-
As I have only scanned the ports that are already known to be open, I will provide them as test cases:
If you enter http://127.0.0.1:22 as the "Git repository URL", you will get a "fatal: unable to access 'http://127.0.0.1:22/': Recv failure: Connection reset by peer" error, which indicates that the port is open but we received a RST packet.
If http://127.0.0.1:80 is entered, we will get a "fatal: repository 'http://127.0.0.1/' not found" error, indicating that the port is open but a 404 error was there.
If http://127.0.0.1:443 is used, we get a "fatal: unable to access 'http://127.0.0.1:443/': The requested URL returned error: 400" error, indicating that the SSL port is open but got a Bad Request.
If we try http://127.0.0.1:21 or http://127.0.0.1:12345 as examples of closed ports, we get a "fatal: unable to access 'http://127.0.0.1:21/': Failed to connect to 127.0.0.1 port {port number}: Connection refused", indicating that the port is actually closed.
Thanks
Timeline:
2016-05-03 17:19 (-0400): @rspeicher (comment)
@strukt
Thank you for the report. Forgive my ignorance, but couldn't this same information be disclosed by, for example, the attacker using telnet
to connect to the host and a specific port?
2016-05-04 07:48 (-0400): @strukt
(comment)
Hello,
Your argument is kinda true in the sense that we already know that ports 22, 80, and 443 are open. But, the issue with a SSRF bug is that we can -in this scenario- force a machine (your server) to issue requests to it's own internal ports, so for example if port 888 is not an internet facing port and is not accessible, unlike the 3 mentioned ones, we can test and confirm if this port is open/filtered/closed/etc if we force the machine to test it by itself, because then it will be accessible as it's a computer testing itself rather than a computer from a different network testing it.
I hope my explanation is clear enough, and I'm here if you need any further information.
Regards