Skip to content

Server Side Request Forgery(SSRF) Explained with Examples

Hello All

Finally, I managed my time to write something about SSRF (Server Side Request Forgery) Vulnerability which is going wild nowadays in Bug Bounty Programs.

Server Side Request Forgery (SSRF) is a type of web application vulnerability that allows an attacker to manipulate the server into making unintended requests on the attacker’s behalf. This can include accessing internal resources that are generally not accessible from the internet or even executing arbitrary code on the server. SSRF attacks are often used to bypass firewall or security group restrictions and can also be used to perform reconnaissance on the internal network. It is important to validate user input and sanitize any URLs or IP addresses used in server-side requests to prevent SSRF attacks.

Let’s take a look at what I will cover in this post. 😉

Index

  • What is SSRF?
  • Diagrammatic Explanation of SSRF
  • Vulnerable Code Example in PHP
    • curl_exec()
    • file_get_content()
    • fsockopen()
  • How to Exploit SSRF using pseudo protocol.
    • HTTP/HTTPS
    • FTP/FTPS/SMB (Anonymous Access)
    • GOPHAR (Universal Protocol)
    • FILE (Read the Local file)
    • DICT (probe intranet service)
    • telnet (Anonymous Access)
  • SSRF Bypass
    • Converting IP Address
    • Using HTTP Redirection (302 Code) to jump
    • DNS Rebinding
    • Bypassing using Non-HTTP protocols
  • Vulnerable Docker Container
    • Installation of vulnerable Docker
  • Mitigation

What is SSRF or Server Side Request Forgery?

In the Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL to which the code running on the server will read or submit data, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed. (Link)

Diagrammatic Explanation of SSRF

Vulnerable Code Example in PHP

curl_exec()

<?php
function curl($url){
                $ch = curl_init();
                curl_setopt($ch, CURLOPT_URL, $url);
                curl_setopt($ch, CURLOPT_HEADER, 0); 
                curl_exec($ch);
                curl_close($ch); 
}
$url = $_GET['url'];
curl($url);
?>

file_get_content()

<?php
if (isset($_GET['url'])) { 
	$content = file_get_contents($_GET['url']); 
	$filename ='./images/'.rand().';img1.jpg'; 
	file_put_contents($filename, $content); 
	echo $_GET['url']; 
	$img = "<img src=\"".$filename."\"/>"; 
} 
echo $img; 
?>

fsockopen()

<?php 
function GetFile($host,$port,$link) { 
	$fp = fsockopen($host, intval($port), $errno, $errstr, 30); 
	if (!$fp) { 
		echo "$errstr (error number $errno) \n"; 
	} else { 
		$out = "GET $link HTTP/1.1\r\n"; 
		$out .= "Host: $host\r\n"; 
		$out .= "Connection: Close\r\n\r\n"; 
		$out .= "\r\n"; 
		fwrite($fp, $out); 
		$contents=''; 
		while (!feof($fp)) { 
			$contents.= fgets($fp, 1024); 
		} 
	fclose($fp); 
	return $contents; 
	}
}
?>

Above shows, Example is basic vulnerable code which is very easy to exploit. I have later on this post. I’ll cover some advanced code which required some bypass techniques to exploit SSRF.


How to Exploit SSRF using pseudo protocol

In this section, we’ll explore each pseudo protocol which helps us exploit the SSRF vulnerability in the vulnerable target.

SSRF vulnerabilities can often be exploited using various types of pseudo-protocols, such as the “file” or “gopher” protocols, in order to access internal resources that are not normally accessible from the internet.

HTTP/HTTPS Protocol

Description

This protocol used wild in SSRF for requesting internal webserver and for getting a pingback request from vulnerable target to attacker domain for making an attack PoC 😉

file:// Protocol

Description

An attacker may send a request to a vulnerable application with a URL that uses the “file” protocol and a file path pointing to an internal resource. If the application is vulnerable to SSRF, it may make a request to the specified file path, allowing the attacker to access the internal resource.

For example, an attacker may use the “file” protocol to read the contents of a file on the server. An attacker could exploit an SSRF vulnerability by sending a request with a malicious URL, such as “file:///etc/passwd” to read the contents of the “/etc/passwd” file on the server.

file:///etc/passwd

gopher:// Protocol

Description

Another example is using the “gopher” protocol, an attacker can access to internal network by specifying the gopher protocol and a “target” IP address, if the SSRF vulnerability allows the attacker to reach internal IP addresses and the target IP address is a firewall or proxy, the attacker can use this to access resources behind the firewall/proxy, or even to use the firewall/proxy as a pivot point to attack other internal systems.

ftp:// Protocol

Description

An attacker may also use the “ftp” protocol to access files on an internal FTP server. An attacker could exploit an SSRF vulnerability by sending a request with a malicious URL, such as “ftp://internal-ftp-server/sensitive-file” to read the contents of the “sensitive-file” on the internal FTP server.

dict:// Protocol

Description

The “dict” protocol can be used to probe internal services on the target system. An attacker could exploit an SSRF vulnerability by sending a request with a malicious URL, such as “dict://internal-dict-server:2628/show:db” to access the internal DICT server.

dict:// Protocol

Description

The “dict” protocol can be used to probe internal services on the target system. An attacker could exploit an SSRF vulnerability by sending a request with a malicious URL, such as “dict://internal-dict-server:2628/show:db” to access the internal DICT server.

telnet:// Protocol

Description

The “telnet” protocol can be used to access internal resources with anonymous access. An attacker could exploit an SSRF vulnerability by sending a request with a malicious URL, such as “telnet://internal-telnet-server” to access the internal telnet server.

….. WIll Continue….

Mitigation

To mitigate SSRF vulnerabilities, it is important to properly validate and sanitize any user input used in server-side requests, and limit the types of protocols that the application can make requests to. It’s also important to keep the application and its dependencies up to date, and use a Web Application Firewall (WAF) to detect and block malicious requests.

Published inWeb ApplicationWeb Attacks

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *