Server-Side Request Forgery (SSRF) vulnerabilities are pervasive in web applications, and as a result, developers deploy various defenses to thwart malicious exploitation. However, these defenses are not foolproof, and adept attackers can find ways to circumvent them. In this comprehensive guide, we’ll explore the intricacies of circumventing common SSRF defenses, shedding light on techniques that go beyond conventional security measures | Karthikeyan Nagaraj

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

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 the following techniques:

• Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
• Register your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.
• Obfuscate blocked strings using URL encoding or case variation.
• Provide a URL that you control, which 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.

It is sometimes possible to bypass filter-based defenses by exploiting an open redirection vulnerability.

In the previous example, imagine the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

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

Blind SSRF vulnerabilities arise when an application can be induced to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application’s front-end response.

The impact of blind SSRF vulnerabilities is often lower than fully informed SSRF vulnerabilities because of their one-way nature. They cannot be trivially exploited to retrieve sensitive data from back-end systems, although in some situations they can be exploited to achieve full remote code execution.

The most reliable way to detect blind SSRF vulnerabilities is using out-of-band (OAST) techniques. This involves attempting to trigger an HTTP request to an external system that you control, and monitoring for network interactions with that system.

The easiest and most effective way to use out-of-band techniques is using Burp Collaborator. You can use Burp Collaborator to generate unique domain names, send these in payloads to the application, and monitor for any interaction with those domains. If an incoming HTTP request is observed coming from the application, then it is vulnerable to SSRF.

Note

It is common when testing for SSRF vulnerabilities to observe a DNS look-up for the supplied Collaborator domain, but no subsequent HTTP request. This typically happens because the application attempted to make an HTTP request to the domain, which caused the initial DNS lookup, but the actual HTTP request was blocked by network-level filtering. It is relatively common for infrastructure to allow outbound DNS traffic, since this is needed for so many purposes, but block HTTP connections to unexpected destinations.

When faced with applications employing SSRF defenses, attackers need to employ innovative methods to bypass these protections. Here are some effective circumvention techniques:

1. Alternative IP Representations: Blacklists often focus on specific representations of sensitive IPs like 127.0.0.1. Attackers can use alternative representations, such as 2130706433, 017700000001, or 127.1, to trick the filters and execute SSRF attacks undetected.

2. Domain Registration Trickery: Instead of directly using blocked IPs, attackers can register their domain names that resolve to forbidden IPs like 127.0.0.1. This involves creating a DNS entry that points to the prohibited IP, providing a covert channel for SSRF attacks. A common tactic is to use a domain like spoofed.burpcollaborator.net for this purpose.

3. Obfuscation through Encoding: Blacklists may target specific strings, making direct attacks challenging. Attackers can obfuscate blocked strings using techniques like URL encoding or case variation. This involves transforming forbidden strings into formats that evade the filters, allowing malicious SSRF requests to pass through undetected.

4. URL Redirection Tricks: Provide a URL that redirects to the target URL. By leveraging different redirect codes and protocols, attackers can bypass anti-SSRF filters. For instance, switching from an http: to https: URL during the redirect has been known to successfully evade certain defense mechanisms.

To provide a comprehensive understanding, we’ll delve into each circumvention technique, examining real-world scenarios and case studies where these methods have proven successful. From dissecting alternative IP representations to exploring the nuances of URL redirection tricks, this guide will equip security professionals and developers with the knowledge needed to bolster SSRF defenses effectively.

Conclusion: Navigating the SSRF Landscape

In the ever-evolving landscape of web security, understanding SSRF defenses and their potential circumvention techniques is paramount. This guide aims to be a valuable resource for security practitioners, enabling them to stay one step ahead of attackers by comprehending the intricacies of SSRF and implementing robust countermeasures.

As we unravel the complexities of circumventing common SSRF defenses, remember that proactive defense measures, continuous monitoring, and a deep understanding of evolving attack vectors are essential for maintaining the security posture of web applications in the face of emerging threats.