Threat Beyond The Front-end: SSRF

Welcome to our blog dedicated to exploring the intricate world of Server-Side Request Forgery (SSRF). In today’s digital landscape, where the internet serves as the backbone of countless services and applications, understanding the vulnerabilities and risks associated with SSRF is paramount. In this, we’ll delve into the fundamentals of SSRF, it’s potential impact on web security, common attack vectors, preventive measures, and much more.

Server-Side Request Forgery (SSRF) is a type of web application vulnerability that allows an attacker to send Unauthorized requests from the Vulnerable web server to other internal or external systems, resources, or services. This can lead to a range of attacks, including data theft, privilege escalation, and even remote code execution.

Types of SSRF:

Simple SSRF (In Band)

Basic or Simple SSRF is typically the most critical issue. In these scenarios, data from an arbitrary URI can be fetched from an internal service and will be returned to the attacker.

Blind SSRF (Out-of-Band)

 Blind SSRF occurs when you never get any information about a target Service from the initial request. Typically, an attacker will provide a URL, but data from this URL will never be returned to the attacker. To confirm a vulnerability in this case, an attacker must use Burp Collaborator, DNSbin , webhook or a similar tool. These tools can confirm that a server is vulnerable by forcing it to make DNS or HTTP requests to an attacker-controlled server. Blind SSRF is easy to validate but difficult to exploit.

How does SSRF work?

SSRF attacks typically involve three components: The vulnerable web application, the attacker, and the target system. Here’s how an attack might work:

1. The attacker identifies a vulnerable web application that allows them to control the URL or other network request parameters.
2. The attacker crafts a malicious request that includes a URL or IP address that points to the target system they want to attack.
3. The attacker sends the request to the vulnerable web application, which then sends the request to the target system on behalf of the attacker.
4. The target system receives the request and responds to it, potentially leaking sensitive data or executing arbitrary code.

Where To Look For SSRF:

• Any functionality that allows external service interaction is a good starting point, anywhere that accepts a third party URL or service integration, Request header(Referer header, Host header)
• Search for parameters like “url=” or easy way “=http” in requests .Try your SSRF payload and check response.

Example:

Imagine a shopping application that let the user view whether an item is in stock in a particular store. To provide the stock information, the application must query various back-end REST API’s. It does this by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. 

1. User views the stock status for an item, their browser makes the following request:

POST /product/stock HTTP/1.0Content-Type:
application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D

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

3. Here,an attacker will modify the request to specify a URL local to the server:

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

4. The server fetches the contents of the /admin URL and returns it to the user.

An attacker can visit the /admin URL, but the administrative functionality is normally only accessible to authenticated users. This means an attacker won’t see anything of interest. However, if the request to the /admin URL comes from the local machine, 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.

2. Blind SSRF:

• The most reliable way to detect Blind SSRF is using out-of-band techniques.
• which means to trigger an HTTP request to an external system that you control, and monitoring for network interactions with that system.
• The behaviour can’t be used to explore content on systems that the application server can reach. However, it can still be leveraged to probe for other vulnerabilities on the server itself or on other back-end systems. 
• You can blindly sweep the internal IP address space, sending payloads designed to detect well-known vulnerabilities.
•  If those payloads also employ blind out-of-band techniques, then you might uncover a critical vulnerability on an unpatched internal server. 

Let’s understand via example:

1. Visit a product, intercept the request in Burp Suite, and send it to Burp Repeater. 

2. Go to the Repeater tab. Select the Referer header, right-click and select “Insert Collaborator Payload” to replace the original domain with a Burp Collaborator generated domain. Send the request. 

3. Go to the Collaborator tab, and click “Poll now”. If you don’t see any interactions listed, wait a few seconds and try again, since the server-side command is executed asynchronously. 

See some DNS and HTTP interactions that were initiated by the application as the result of your payload. 

Whitelists Bypasses:

• Whitelists are generally harder to bypass because they are by default than blacklists. But it is possible if there is an open redirection vulnerability within the whitelisted domain.
• If you could find an open redirect,you can request a whitelisted URL that redirects to an internal URL.

http://example.com/ssrf.php?url=https://abc..com/?redirect=https://attacker.com

Blacklists Bypass:

1. Converting IP to hexadecimal:–

Example- Converting http://192.168.39.343 to doted hex – http://c0.a8.00.01 and dot less hex http://0xc0a80001

2. Converting IP to Decimal:-

Example-http://0177.0.0.1/= http://127.0.0.1 

                                     or 

http://2130706433/=http://127.0.0.1

3. Converting IP to Octal:–

Example- Converting http://192.168.0.1 to dotted octal  http://0300.0250.0000.0001 and dot less http://030052000001

4. Using wildcard DNS:–

For Example- 10.0.0.1.xip.io resolves to 10.0.0.1 – There are many site provide wildcard dns like xip.io, nip.io., Ip6.name, localdomain.pw

5. Using enclosed alphanumerics:-

Example -http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ = example.com

Impact:

• Access to a cloud provider’s metadata API (e.g. often allowing retrieval of confidential access tokens.
•  Examples :http://169.254.169.254/latest/meta-data/
• Access to local files (e.g. disclosing confidential passwords in configuration files)
• Access to internal IP addresses which are not reachable from the public network (e.g. allowing exploitation of common vulnerabilities / CVEs)
• Access to internal databases without authentication (e.g. allowing to dump all data)
• Port Scans or Cross Site Port Attack (XSPA)
• Protocol Smuggling

Remediation:

• Whitelist all IP / services to which the application needs access
• Disable URL schemes that are not needed (e.g. “file://”, “gopher://”, “ldap://”)
• Enable mandatory authentication on all reachable services (e.g. databases)
• Implement monitoring with anomaly detection on all outgoing http traffic

As we wrap up our exploration of Server-Side Request Forgery (SSRF), we want to express our gratitude for joining us on this enlightening journey. We hope that delving into the fundamentals, impact, and preventive measures surrounding SSRF has equipped you with valuable knowledge to bolster your web security defenses.