Server-Side Request Forgery (SSRF) – Exploitation And Defense Insights

In this section, we’ll explain what server-side request forgery is, describe some common examples, and explain how to find and exploit various kinds of SSRF vulnerabilities.

What is SSRF?

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure.

In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

What Is The Impact Of SSRF Attacks?

Server-Side Request Forgery, also known as SSRF, refers to an attack that lets an attacker send crafted requests from the back-end server of a vulnerable web application.

SSRF is commonly used by attackers to target internal networks that are behind firewalls and can not be reached from an external network.

When the attacker has complete or partial control over the request that the web application sends, SSRF vulnerabilities occur.

If the vulnerable web application processes the user-supplied URLs, then the application is vulnerable to SSRF attacks.

Cross-Site Port Attack (XSPA) is also part of SSRF. In XSPA, an attacker can scan the open port of a targeted web server with the help of a vulnerable web application that is processing the user’s URL.

Common SSRF Attacks

SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions.

These trust relationships might exist in relation to the server itself, or to other back-end systems within the same organization.

Impact Of A Server Side Request Forgery Attack

If the user-supplied URL is processed and the back-end response is not sanitized, then the attack can lead to several impacts, like:

1. Port scanning: A user can scan the port of a particular website through the vulnerable web application that is processing the user’s URL.
2. Fingerprinting intranet.
3. Attacking internal or external web applications.
4. Reading local web server files using the file:/// protocol handler.
5. In some cases, a successful SSRF attack can even lead to Remote Code Execution (RCE).

SSRF Attacks Against The Server Itself

In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application via its loopback network interface.

This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).

For example, consider a shopping application that lets the user view whether an item is in stock in a particular store.

To provide stock information, the application must query various back-end REST APIs, depending on the product and store in question.

The function is implemented by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. So when a user views the stock status for an item, their browser makes a request like this:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.

In this situation, an attacker can modify the request to specify a URL local to the server itself. For example:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

Here, the server will fetch the contents of the /admin URL and return it to the user.

Of course, the attacker could just visit the /admin URL directly. But the administrative functionality is ordinarily accessible only to suitable authenticated users.

So an attacker who simply visits the URL directly won’t see anything of interest. However, when the request to the /admin URL comes from the local machine itself, the normal access controls are bypassed.

The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.

Why do applications behave in this way, and implicitly trust requests that come from the local machine? This can arise for various reasons:

• The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server itself, the check is bypassed.

• For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine.
• This provides a way for an administrator to recover the system in the event they lose their credentials.

• The assumption here is that only a fully trusted user would be coming directly from the server itself.

• The administrative interface might be listening on a different port number than the main application, and so might not be reachable directly by users.
• These kinds of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, are often what make SSRF a critical vulnerability.

SSRF Attacks Against Other Back-End Systems

Another type of trust relationship that often arises with server-side request forgery is where the application server is able to interact with other back-end systems that are not directly reachable by users.

These systems often have non-routable private IP addresses. Since the network topology typically protects the back-end systems, they frequently have a weaker security posture.

In many cases, internal back-end systems have sensitive functionality that anyone with access to the systems can access without authentication.

In the preceding example, suppose there is an administrative interface at the back end. Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by submitting the following request:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

Circumventing Common SSRF Defenses

It is common to see applications containing SSRF behavior together with defenses aimed at preventing malicious exploitation. Often, these defenses can be circumvented.

SSRF With Blacklist-Based Input Filters

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using various techniques:

• Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.

• Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.

• Obfuscating blocked strings using URL encoding or case variation.

• Providing a URL that you control, which subsequently redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL.
• For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filters.

SSRF With Whitelist-Based Input Filters

Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent the filter by exploiting inconsistencies in URL parsing.

The URL specification contains a number of features that are liable to be overlooked when implementing ad hoc parsing and validation of URLs:

• You can embed credentials in a URL before the hostname, using the @ character. For example:

https://expected-host:fakepassword@evil-host

You can use the # character to indicate a URL fragment. For example:

https://evil-host#expected-host

You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example:

https://expected-host.evil-host

• You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request.

• Note that you can also try double-encoding characters; some servers recursively URL-decode the input they receive, which can lead to further discrepancies.

• You can use combinations of these techniques together.

About The Project

An exploit of Server-side request forgery (SSRF)

Built With

Whilst I was the main developer of this project, this project couldn’t of even started without the help of these open source projects, special thanks to:

• [Python]

Getting Started

This is an example of how you may give instructions on setting up your project locally. To get a local copy up and running follow these simple example steps.

Installation & Usage

1. Clone the repo

git clone https://github.com/errorfiathck/ssrf-exploit.git

2. cd to directory

cd ssrf-exploit

3. Run the script as an example:

python3 ssrf-exploition.py --help

4. Have fun!