In today's class, we are gonna be talking about blind SSRF vulnerabilities.

Now we covered normal SSRF vulnerabilities.

And we said earlier that in a normal scenario you would forge a request as the user.

You send it to a vulnerable web server and then that web server is gonna send that request that forged the request to another protected server and send the information back to the web server.

And therefore you'll be able to see it as the user.

So you're gonna request for something private that is only available and only accessible to the web server because it's trusted.

The response is going to be sent back because this place is trusted the web server but you as a user you're going to be able to read it.

And all of that is possible because this web server has a web application that is vulnerable to an SSRF vulnerability.

Now we're actually doing this and we're communicating to the server through the web server because if we communicate with it directly it will refuse our connections and it won't even speak to us because this is an internal server that only speaks to the web server.

That's why we have to exploit an SSRF vulnerability to be able to communicate with it and get the response back to a place that it trusts and therefore will be able to read it as the user.

In the blind scenario and blind SSRF vulnerabilities, we still have a web server that has a vulnerable web application and you're still able to send your forged request exactly the same way the forged request will be executed exactly the same way.

So it is still going to go to the private or to the protected server and it's going to execute whatever you're asking for.

The only problem is there will be no response.

Therefore for you as the hacker, it will be difficult for you to know if your attack was actually executed.

Also in many of the scenarios that I covered previously,

we were requesting private or protected information from the server and we were only able to see it because a response was sent back to the web server and we were able to see that information or these pages for example, we requested to access the admin page that is only available here.

And we were only able to see it because that admin page was sent back to the web server.

So the problem with the SSRF, you're gonna request the admin, this webserver will actually go to the admin but nothing is sent back to it and therefore you will never be able to see it.

Therefore, blind SSRF vulnerabilities can be a little bit less dangerous.

So the impact is a little bit lower.

But in some scenarios you'll actually be able to gain code execution or exploit vulnerabilities within the devices that are connected to the same network.

So if you remember another thing that we could do with SSRF is that we were able to map the internal network that this web server is connected to, and we can actually blindly send exploit payloads to these devices on this network and hope for one of them to be vulnerable so that we can get access to it.

Now, there is a good chance of discovering exploits in these internal services because these services remember are not exposed to the internet, they're only internal.

And therefore in many cases server admins do not pay a lot of attention in keeping these services fully patched and fully secure.

They only pay a lot of attention on trying to secure this and have the best firewall on it.

Therefore there is a good chance of you being able to exploit a non vulnerability in internal services and then gain access to that server.

Now we will talk about exploitation.

But for now, let's talk about discovering blind SSRF vulnerabilities.