Beginners Guide to SSRF

Server-side request forgery, or SSRF, is a type of vulnerability where an attacker can can abuse the functionality on the server to read or update internal resources, attacker can manage somehow to be able to make a server perform unintended network requests. A SSRF Vulnerability allows the attacker to make requests originating from the server

Most of the companies have 🔥 firewalls in place that restricts external traffic from accessing internal servers, For example database servers, which are inaccessible to the 🌐 internet. So whenever say a user logs in to the account, user send a HTTP request with the credentials to the web server, which then perform its own request database, database responds back to the web server with data and then the server relays that information back to the to user.

Now a vulnerable server might allow an attacker to send requests to the database server and retrieve information which they shouldn’t have access to. SSRF vulnerabilities provide attackers access to a broader network to target.

Types

Most Common type of SSRF are:

• Blind SSRF: In this case the attacker can’t read the response of the request made.
• Full Response: Allows to see the entire response from the server
• Limited or No Response - Shows a portion of response like the title of a page or No response or you have access to resource but cant see them directly

Full Response SSRF

In Full Response SSRF, attacker is able to view the entire response and thus could lead to private data exposure.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

GET https://mysite.com/image/proxy?url=https://gravatar.com/1.png HTTP/1.1

Response: 
<<<<<<<<<<<<<IMAGE DATA>>>>>>>>>>

// So instead of entering a URL attacker can enter an internal IP address of a 
// internal application to access it which might not be otherwise accessible

GET https://mysite.com/image/proxy?url=http://10.0.0.1 HTTP/1.1
Response
   {
	"message":"Route Not Available",
	"routes":[
                   "/users/{user_id}",
	           "/users/{user_id}/make_admin",
	           "/users/{user_id}/new_password/{new_password}"
	   	  ]
   }

// Apart from internal resources you can also able to fetch internal files 
// for ex, depending on the URI scheme we have access to

GET https://mysite.com/image/proxy?url=file:///etc/passwd HTTP/1.1
Response

<<<<<<<<<<<<<<<<<< /etc/passwd data >>>>>>>>>>>>>>>>>

Blind SSRF:

This happens when we are able to hit the request but we are not able to see the response.As the attacker can’t read the responses, they will need to find an alternative means of extracting information. The two common methods of extracting information are: timing and DNS.

In some blind SSRFs, response times may reveal information about the servers. One way is to port scan internal servers. For example, if we send a request to a port, a response that returns in 1 second vs 10 seconds could indicate whether it’s open, or closed depending on how known ports respond.

For exmple say the url parameter of the request is vulnerable to SSRF then followin table could help in understanding how a timing attack works.

Thus attacker can scan the internal network for IP’s and Ports

Another method is DNS, So whenever a user makes a request to a doamin, a DNS Request is invoked to find the IP address of that domain. attacker could take advantage of this to smuggle the data.

To exploit this consider a scenarion say an attacker is able to perform arbitary commands on the server but is not able to read the response of those command, then what he can do is append the smuggled information/response as a subdomain to his own domain and the targeted server will performs a DNS lookup to his site for that subdomain.

For example, if there exist SSRF vulnerability and an attacker is able to execute some commands on the server, then running a command say whoami and adding its output as a subdomain would send a request to attacker server, attacker server will receive a DNS lookup for data.attackerdomain.com, where data will be the output of the whoami command.

Limited Response SSRF:

IN Limited SSRF only partial response to the request is possible, for example attacker might be able to get only the response codes in case of an HTTP request

Limitations

If there is an SSRF vulnerability in place, but we arent able to access internal servers, then check weather you can perform requests to arbitrary external sites If you can access external sites then this could be further exploited to access inforamtion about the underlying server or software, and also you could control the response to any request made.

For example, you might be able to convert external requests to internal requests if the vulnerable server will follow redirects. In cases where a site won’t allow access to internal IPs, but will contact external sites, you can return a HTTP response with a status code of 301, which is a redirect. Since you control the response, you can point the redirection to an internal IP address to test whether the server will follow the 301 and make an HTTP request to its internal network.

If an SSRF vulnerability only allows to communicate with a limited number of external websites it means there is an filtering in place. If the filtering is blacklist then we could try to take advantage of misconfigured blacklist filtering. And if the filtering is whitelist, then we might need to find a open redirect vulnerability to exploit the SSRF

Potential Blockers➖

• Whitelisting: Only Few Domain names to be used in the request
• Blacklisting: Block access to Internal IP address, domains or keywords
• Restricted Content-Type, extensions or characters - only allows a particular file type
• No Response- You may not be able to see the response from the request

Potential Solutions

• Whitelisting: Finding an Open Redirect
• Blacklisting: Create a Custom CNAME and pointing it to our internal IP address on the target
• Restricted Content-Type, extensions or characters - Manually Fuzzing and creating a Bypass
• No Response- Javascript XHR request to retrieve file content

Conclusion

Things to keep in mind while fuzzing for SSRF

• You are making a server side request
• You are browsing content that is rendering on host machine
• There are different ways to look for content on localhost like “localhost” or 127.0.0.1
• You may need to use an open redirect to redirect the machine to your destination host
• The current host may be able to communicate with other machines on the network (that may require being on the Corporate VPN)
• Make sure the request comes from the remote server and not your personal IP address

TL;DR: You have a “browser” thats rendering web pages for you on the host machine.

1
2

If you find an OPEN REDIRECT try to keep it for a while, to see if it helps
in Exploiting SSRF vulnerability

Thanks for Reading, Stay tuned for more ❤︎

If you enjoyed reading the article do follow me on:

Twitter

LinkedIn

Website

GitHub