Various Attack Methods

SSRF against the server itself

The attacker induces the application to make an HTTP request back to the server that is hosting the application via loopback interface (127.0.0.1).

For example,

Consider a shopping application that lets user view whether an item is in stock.

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

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 a specific URL to get the stock status, So the attacker can modify the end URL to be something like this :

POST /product/stock HTTP/1.0 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 118 
stockApi=http://127.0.0.1/admin

The server will fetch the contents of the /admin URL and return it to the attacker.

Note

If the /admin URL is accessible to the normal user then why should he implement an SSRF Attack ?

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.

Hence, the application grants full permission to the admin functionality because the request appears to originate from a trusted location.

PortSwigger Exercise

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.

SSRF against other back-end systems

A SSRF vuln can even interact with the other backend systems that are not directly reachable by users.

These systems have a non-routable private IP address

Since the backend systems are normally protected by the network topology, they often have a weaker security posture.

In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.

PortSwigger Exercise

PortSwigger Exercise

SSRF with Blacklist-based input filters

Modern application blocks input containing hostnames like 127.0.0.1 and localhost or sensitive URLs like /admin.

These can be circumvented using techniques such as :

• 127.0.0.1 as 2130706433, 017700000001 or 127.1

• Registering own domain name that resolves 127.0.0.1 {Burp collaborator}

• Obfuscating blocked strings using URL encoding or case variation {admin}, double URL encode the string admin to bypass.

PortSwigger Exercise

SSRF with Whitelist-based input filters

Modern applications only allow some inputs which matches, begins with or contains just like the MIME type in file-uploads.

So how do we bypass this ?

• embed credentials in a URL before the hostname, using the @ character

https://website-host@evil-host

• By using the # to indicate the URL fragment

https://evil-host#website-host

• Can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control

https://expected-host.evil-host

• URL-encode characters to confuse the URL-parsing code, combination of these techniques will work !

Firstly, decode and test the API using the regular URL => 200

Tamper the domain to get some interesting error such as so and so domain should be present, if its whitelisted as stock.weliketoshop.net then it is compulsory to be in the request,

Try adding few strings before the domain, http://[e-mail] => 500 Internal Server error

Now we get a different kind of error where, it says the domain is correct but it cannot connect to the internal stockAPI

Try tampering it like, http://[e-mail] => 200 Double URL encode the #, to bypass whitelisting

Now we can access the /admin panel => http://[e-mail]/admin/delete?username=carlos

Bypassing SSRF filters via Open-Redirection

For example,

Suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior, The application whose URLs are allowed contains an open redirection vulnerability.

/product/nextProduct?currentProductId=6&path=http://127.0.0.1

Returns redirection to the localhost as expected.

We can leverage the open redirection vuln to bypass URL filtering and exploit SSRF.

Reason why this works most of the time

It's beacuse the application first validates that the supplied stockAPI URL is on an allowed domain => which is TRUE

The application then requests the supplied URL which is the Attacker's URL and triggers the open redirection

The same usual techinique is applied, which is to tamper the stockAPI but now there is a different case scenario where the stockAPI gives only the path of the stocks available to the user.

So there is no service connecting to the internal server which brings us the stock info, we cannot tamper the path.

Below that same page we get to see, there is another interesting option which is called Next option, the background request for this option contained a variable called &path which leads to the next product's image.

So tampering that to &path=https://www.google.com, gave us an open-redirection vuln

As the challenge said there is another IP running in the server containing admin panel, so redirecting to that achieves the moto of this challenge.