A10:2021 OWASP – Server Side Request Forgery

What is Server Side Request Forgery?

OWASP SSRF when abbreviated, it is a variety of cyber-attack wherein the skilled hacker takes the advantage of the pre-existed vulnerability, present on a server, and uses it against the server. Depending upon the intent of the hacker, an attacker uses SSRF to temper mission-critical server data (stored or passing by) by inserting a corrupted code/link.

‍

The Impact of SSRF

If ignored for a long time, the SSRF attack can cause hassles beyond once it and expectations. The key impacts are as follows:

• Attackers can use a compromised server as an IP scanner or port to gather the information from front and back-end systems
• If internal protocols like Gopher are enabled on targeted servers then hackers can easily make a path for further reconnaissance possibilities  
• A successful SSRF cyber-attack permits threat actors to find out the hidden IP addresses that are running at the back of reverse proxy
• By creating a possibility for XCE, SSRF creates a base for multiple cyber troubles as malware, viruses, ransomware, and other sorts of ill-intended components can be introduced.

All in all, SSRF can cause big troubles for the victim. 

‍

SSRF and OWASP Top 10 2021

When successful, this vulnerability can cause a wide array of hassles that includes exploitation of servers and related systems, bypassing host-based authentication and IP whitelisting, accessing files stored on the server, exporting the user data, authorized interaction, or access to server-side APIs, and so on.

Seeing this, it’s not shocking to learn why SSRF is included in Top 10s of OWASP. From the very first list released to the newest one, SSRF has always been defined as a potential security threat. However, it got its separate category this time only.

Depending upon the total CVEs reported, SSRF secured 10th place in the OWASP list. Wallarm - a top cybersecurity organization - had already predicted the same in OWASP Top 10 2021 predictions. Based on a huge database and detailed analysis, this prediction emphasizes more on taking SSRF vulnerability seriously. 

Wondering what would be the OWASP Top 10 2022 predictions? Here is what you need.

‍

SSRF in action

The best way to understand how SSRF works and impacts is to get familiar with the Server Side Request Forgery examples. See a few of them here:

Example #1 - Unsegmented network architecture is an opportunity for attackers as they can use them to figure out whether or not the internal server ports are open. If ports are open, they can easily carry an SSRF connection.

Example #2 - Using the URLs like http: //localhost:28017/ and file: ///etc/passwd, attackers can get into internal services or local files, stealing sensitive data thereafter.

Example #3 - Cloud solutions having stored metadata as http: //169.254.169.254/. are easily accessible to the attacker and they can use it to access crucial information.

Example #4 - By modifying the response, an attacker can create a scope for DoS and RCE.

Server Side Request Forgery Example

A threat actor can succeed at an SSRF exploit using a simple GET call. It is also possible to get access to local system resources or even perform the remote-code execution if the hacker could guess the folder structure of your endpoints or server. Let us explain the same through an example to you.

Have a look at this GET request and guess why it is vulnerable to SSRF attacks.

http:/localhost/?link=http://example.arm.com/images/header.gif

Not sure? Well, take a closer view at the PHP code that will execute this request:

<?php

//verify if the variable ‘link’ has a value

if (isset($_GET['link']))

{
$link = $_GET['link'];
$img = fopen($link, 'rb'); // Forwards a ‘open’ request for image/binary-file; no checks.
header("Content-Type: image/png");	// Sends back the response-header directly.
fpassthru($img); // Returns the image contents.
}

?>

If you read this code, which is to be executed on the server, you will realize that there is no validation being done on the GET input. So, one can pass normal as well as malicious payloads through it.

To be more specific, in the above example, the cybercriminal is checking if he has a complete hold over the ‘link’ variable/parameter. For this, he made a quick and random GET request. The server responded to it and confirmed that it was vulnerable enough.

Now, the threat actor can make further arbitrary GET calls to the website to access its more important resources. This could be the next request of the attacker:

GET /?url=http://example.arm.com/server-status HTTP/1.1
Host: http://example.arm.com

In this request, the attacker is making a request with the mod_status as enabled. The Apache HTTP servers will leak the server performance and active connections’ details to let him gain extra knowledge about the ecosystem under attack.

Besides the above scenarios, a cybercriminal can also use SSRF for more serious attacks, for example - to access the internal server resources that are unavailable for the normal audience otherwise. From running port scans to fetching the cloud service’s instance’s meta-data, he can leverage this server vulnerability as he pleases. Here’s how:

GET /?link=http://169.253.167.244/latest/meta-data/ HTTP/1.1
Host: http://example.arm.com

Not only the web-based server resources but the offline physical server resources, i.e. the local files of the system, are also at risk if an attacker succeeds in carrying out an SSRF attack. Apart from http:// and https:// URL schemas, he can also try file:/// and gain access to unsecured local data of your network’s endpoints or the server itself. Here is an example:

GET /?link=file:///etc/passwd HTTP/1.1
Host: http://example.arm.com

As the success of the attacker and the degree of exploit depends upon how an application is allowing the threat actor to act in its system, some cybercriminals can even try cURL requesting. This means that they will be able to use even more URL schemas, e.g. dict://, and utilize the victim’s system to forward their request through any port. These requests will have customized data as its content, as set by the attacker. 

GET /?link=dict://arm.com:11211/stat HTTP/1.1
Host: http://example.arm.com

Through the above request, the cybercriminal will get quick access to unexposed ports like 11211 (Memcached’s default port) and other similar resources. As you can realize already, things can take a more dangerous turn from here.

‍

Main types of SSRF vulnerabilities

For any server-side ecosystem, there are two sides, the server and its internal components and the server with the back-end system. Based on the side impacted by this vulnerability, it has got 2 classifications:

Against the server

This is also known as basic SSRF and refers to the direct display of the outcome of the attack to the hacker. To make this happen, the server accesses the attacker-fetched URL, gathers the information/data/response and shares it with the hacker.

Mostly, the hacker swaps the actual URL with ‘localhost’ or IP 127.0.0.1. Doing so will help the hacker to find out the path that will directly lead to crucial data. This type of SSRF attack is common and can lead to hacker identification if the right kind of investigation is carried out.

Against back-end systems

Here, the threat actor doesn’t directly reach the server or communicate with it. Rather, it involves taking any server back–end system under control and using it to access severe responses or information. So, it is known as blind SSRF too.

When the server transmits data to that compromised back-end system, the hacker will access it and use it as per the will.  As most of the back-end systems feature weak security, hackers don’t have to do much hard work to process it. 

‍

Basic SSRF attacks vs. blind SSRF attacks

In the examples that we explained above, the attacker could always see what’s happening when he sends a request in order to exploit a server loophole. This type of SSRF exploit is called non-blind or basic type. 

To make it simpler to understand, the threat actor can receive output or feedback from the server in a non-blind attack. As the visual data is received, it is easy to tell if the exploit was a success or a failure. 

See another example for more clarity:

http: //localhost/ ?link=http: //example.arm.com/ images/ footer_bg.gif

Here, if the server returns the ‘footer_bg.gif’ file, the exploit is successful. Otherwise, it fails.

The blind SSRF attack, on the contrary, is similar to its name. No data is returned upon its successful or failed execution. So, the focus here is performing an illicit action rather than fetching some data illicitly. 

From changing user rights to modifying critical business data or a server parameter’s value, a blind exploit can aim at anything. For example, check this out:

http: //localhost/ ?link=http://external_site.com/ 1GB_gif.gif

Here, the threat-actor attempts to fetch an extremely large file (a GIF of size nearing 1 GB) from an external source repetitively and makes the server slow down or crash.

‍

What kind of damage can SSRF do?

Honestly speaking, the damage extent is hard to predict as the outcomes depend on the system configuration, API security practices adopted, and the severity of the attack. However, certain standard dangers follow for sure if an SSRF against you in successful. here are a few examples of what may happen:

• ‍Remote Code Execution (RCE) 

It is a potential danger of a successful SSRF attack. Most modern applications use ample HTTP requests and their improper control or management grants an opportunity for attackers for RCE. Mostly, RCE targets the core server like Redis because it could fetch hackers more info that is precious to the victim.

• ‍Port Scans or Cross Site Port Attack (XSPA)

It’s not necessary that an SSRF-related attack will have to bring the response data to the hacker. To avoid missing any response, an attacker can take the help of an open port. Using an open port, it’s easy to carry out a quick network scan of the application server. This is known as XSPA.

Also, it’s worth noting that network connection timeout maintains the original value and is not bothered about the status of the port/host. A seasoned attacker can use this feature to carry out an SSRF attack by using an acceptable request and using it to define the future network connection timelines.  

Once the request is accepted, attackers are able to record the service existence details on the targeted network and perform the protocol smuggling assaults.

• ‍Data Exposure

If successful, SSRF vulnerability grants hackers admin-like access to the data stored on the server and its back-end system. The world has already witnessed it when Amazon EC2 became a victim of this vulnerability. A variety of Amazon EC2 instance credentials were compromised. 

Now, if you’re wondering how much data can be exposed or compromised then it’s crucial to understand that it depends on the permissions given to IAM roles. If too many permissions are allowed then entire customer account details can be compromised.

• ‍Reconnaissance

Enterprises adopt the practice of limiting the usage of servers involved in public dealing. This is done to narrow down the scope of outsiders’ threats. SSRF can use the reserved servers and make them work to gather the data/information/response shared or stored via an internal network and use these details to monitor other servers. This is known as reconnaissance and is a potential danger as one successful attempt can put all your internal servers at risk.

• ‍Denial of Service (DoS)

As we all know, DoS refers to preventing authorized or permitted users to access a particular resource. When SSRF is considered, the resource here is the server. Because of receiving a higher number of requests, internal servers are designed to handle reduced bandwidth.

However, skilled threat actors can overflow the internal servers with huge traffic. This leads to a DoS attack.

How to identify SSRF vulnerability? 

Early detection is the first toward a successful SSRF mitigation approach. Gladly, it’s not hard to spot the problem if you’re attentive. Here are a few good practices to adopt:

• Look at partial URLs in the request

It’s very common practice for an application/program to keep a part of the URL or host details while forwarding a request. Such requests, on their receipt in server, are incorporated as a full URL. You have to closely look for the presence of GET-type form inputs or URLs to look for the easy clues of SSRF cyber-attack, for which, the input can reveal the obvious.

• Pay attention to the data formats

In general, applications, transmitting the data in rich formats, permits the presence of the URL needed for the parsing of data in a preferred manner. For instance, XML often carries the structured data to and fro. So, it makes a path for XXE injections and SSRF. So, if you’re using a data format within an URL, stay alert and adopt adequate SSRF prevention measures.

• Presence of Referer header

If you’re using server-side analytics software to keep tabs on server visitors then it’s obvious that the software will record the Referer header in requests. This is important for effective tracking of received links.

There is also a possibility that this server analytics software is visiting a third-party URL and it’s appeared in the Referer header. This kind of Referer Header shows a positive environment for SSRF like intrusions.

‍

Mitigating and preventing attacks

SSRF can be proved fatal, if not handled carefully. Hence, it’s important to learn about the best SSRF mitigation techniques. While you’re doing so, make sure that your preventive measures are updated, potential, and capable of making the SSRF attack ineffective. Here are the top four ways using which an organization can reduce the likelihood of such attacks.

• Response handling

To make sure the server-side or client-side response, against a request, isn’t approachable by any unauthorized user, request-response handling measures should be adopted. For instance, under no circumstances, an unfamiliar response or a raw response body should be processed further.

• Whitelists and DNS resolution

A better alternative to blacklisting, IP and DNS name whitelist works well as an SSRF preventive solution as it makes the application-accessible IP address/DNS names inaccessible. Also, it’s crucial to perform user input authentication wisely. Actions like not giving access to a private IP address, as it is non-routable, must be taken.

• Disable unused URL schemas

Always follow the HTTPS or HTTP URL schemas for request initiation and dispose of all the other redundant URL schemas and reduce the scope of SSRF attacks. The more URL schemas you follow or store, the higher the opportunities for the hacker to carry out an attack.

• Keeping proper access-restrictions for internal services

In case you’re using services like MongoDB, Memcached, Redis, and MongoDB, it’s essential to enforce solid authentication. As these services lack default authentication, hackers can use them as a means to conduct the SSRF attack. When strong authentication measures are implemented on such internal services, they become safe to use.

Wallarm will protect against SSRF vulnerability

Even though SSRF has the potential to create a great ruckus, the right kind of assistance and timely actions can lead to early SSR mitigation. Wallarm, a renowned AppSec platform, offers a wide range of security tools that can help you prevent the SSRF.

• Cloud WAF

Capable of protecting resources like APIs, serverless workloads, and applications stored on servers, this cloud WAF requires only a minor DNS change to work. Its automatic tuning and nearly zero false-positive results ensure that you always get accurate protection against SSRF-related dangers. This is the first even cloud WAF offering the assistance of automated incident analysis. Hence, it is a hard pass.

• API Threat Prevention

With Wallarm’s API Threat Prevention, it’s easy to keep your server-side APIs protected from SSRF. The solution works on all the leading APIs and is compatible with all sorts of ecosystems, including IBM Cloud, AWS, and Service Mesh.

Along with SSRF, many other cyber-vulnerabilities (including OWASP Top 10) can be stopped in their infancy stage.