Can you leverage the SSRF vulnerability to identify port 3002 listening locally on the web server? Answer format: Yes, No
I don’t get it?
dfgdfdfgdfd@htb[/htb]$ echo "http://<VPN/TUN Adapter IP>:<LISTENER PORT>" | tr -d '\n' | base64
dfgdfdfgdfd@htb[/htb]$ curl "http://<TARGET IP>:3000/api/userinfo?id=<BASE64 blob>"
the api is at port 3000, other application are utilizing 3002 and no SSRF on 3002.
So what’s the solution to the question? (obviously not by guessing yes or no. lol.)
Hey, have you figured it out?
Yes, I mean, I got the correct answer on that question by guessing “Yes”.
But I still didn’t get the solution to arrive at that answer.
same ahah
I dont know if this is the intended way to determine this or not, but here is what I did.
convert http://127.0.0.1:3002 to base64 and use that in the id parameter. The session will not close in your curl command. Do the same thing using a different (closed) port and you will get a ‘{“success”:false,“error”:“Cannot reach to the resource”}’ message back.
Since the one connection stays open, we can evaluate that as the server is listening on that port, if a port is closed the connection will not work.
I followed the same path i got a response eventually though: curl: (52) Empty reply from server, would love to push on and see if there is a way to actually enumerate the service running on the port.
Has anyone managed to enumerate the service running on port 3002???
I tried to serve a file on my machine and make the request from it but I was unsuccessful.