SSRF 101: How Server-Side Request Forgery Sneaks Past Your Web Apps

library
crime | hacking | security

While an SSRF attack will often be used to help an attacker move laterally through an organization, it can use the server’s loopback function (a call to 127.0.0.1) to gain access to application server capabilities that would normally be hidden from the outside.

In both of these cases, the SSRF is taking advantage of the trust relationship that exists between the Web application server and the rest of the enterprise application infrastructure. Since most organizations have allowed systems within their enterprise boundaries to communicate without constant authentication, once an attacker finds a vulnerable Web server, they can move laterally to a wide variety of targets within the enterprise.

The How
There are a variety of techniques that can be used to launch an SSRF attack. Most use a URL that contains data the targeted server doesn’t expect and doesn’t deal with in a safe fashion. In many cases, these involve a handful of specific characters that lead the Web server astray.

In the first example of how a SSRF can begin, the URL string can begin with something other than “http” or “https.” Other schema can include “file,” “dict,” and “image,” each indicating a specific type of resource the server expects to return, while “ftp” and “gopher” are examples of schema that specify services that will be used to return data. If an application hasn’t been coded to properly whitelist only the resource and service types intended for its use, then one of the others can be the gateway to behavior the developers never intended.

The next example comes via a handful of special characters that can be embedded within URLs. These characters, like the “#” indicating a URL fragment to follow, can be the jumping off point for malicious URL excursions into resources you thought were safe. Other special characters, like “?” and “*,” can provide similar points of departure through slightly different mechanisms. In all cases, though, the code that follows the special character is the malicious payload that can do digital violence to your security.

Finally, the application server itself can be attacked through URLs specifying that information be returned from 127.0.0.1 or “localhost.” The malicious use of either of these locations in the URL can result in the server giving up sensitive information about itself — information that can then be used for even more powerful and pervasive attacks.

Further, as Kelly Sheridan wrote for Dark Reading: “SSRF poses a threat to cloud services due to the use of metadata API, which allows applications to access configurations, logs, credentials, and other information in the underlying cloud infrastructure. While the metadata API can only be accessed locally, an SSRF flaw makes it accessible from the Internet and could enable lateral movement and network reconnaissance.”

The No
Given the danger, and the modern requirement to have Web-based application servers open to large user populations, what can be done to keep infrastructures safe? As it turns out, several safety options are available to both software developers and security professionals.

The first option is to whitelist or blacklist specific schema and resource locations. Whitelists can be quite powerful, limiting the responses to specific schema types and resource addresses. If an application requires more flexibility than a whitelist easily provides, blacklists can do the job — though they require much more thought and imagination on the part of the developer to eliminate every malicious schema and address.

Request response filters to ensure that, for example, a field expected to return a two-digit number can return only a two-digit number are powerful in their own right. They’re the mirror image of input validation, in which the application filters input to make sure that only appropriate, properly formatted input is allowed.

Finally, a zero-trust approach to security, in which the various parts of the application environment must constantly revalidate to one another, can go a long way toward making sure that stray queries from malicious URLs aren’t answered by servers because there will have been no application authentication between the various points.

SSRF attacks can be difficult for both human analysts and security technology to spot, and once successful can be the point of entry for malicious payloads that are both serious and long-lasting. Using application and infrastructure design to stop them before they start can help protect an organization from these URL-based bits of bad news.

Comments are closed.