Quick Bites Ep 4 - Let's Talk About SSRF, Baby!

Let’s talk about you and (application) secur-i-ty! Let’s talk about all the good things and the bad things that may be! Let’s ta - sorry. That was ridiculous. But hey, I grew up in the 90’s, and it got stuck in my head…and tell me it’s not stuck in your head now. Of course, you have to say Ess-Ess-Arr-Eff really quickly, and it throws off the cadence of the rest of the song… /me clears throat

Anyway, let’s actually talk about SSRF.

SSR-what?

Server Side Request Forgery (SSRF) is a particularly nasty vulnerability which allows an attacker to forge a request from an application to gain access to files or services through the application which are not otherwise available. One of the more interesting aspects of this vulnerability is that it’s the only vulnerability in the 2021 OWASP Top 10 that has its own category. It could eventually fall into other Top 10 categories like Injection, Broken Access Control, and Insecure Design, however, the OWASP community survey rated the flaw as #1, which warranted its inclusion to the Top 10. I think this is because this attack is going to be a really big deal very soon, particularly as more organizations make the jump to cloud.

Ok, but what is it?

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly bypassing access controls such as firewalls that prevent the attackers from accessing the URLs directly. The server can be used as a proxy to conduct port scanning of hosts in internal networks, use other URLs such as that can access documents on the system (using file://), or use other protocols such as gopher:// or tftp://, which may provide greater control over the contents of requests. [1]

Hmmmm…ok. An attacker sends a malicious URL to a server, and they can potentially bypass controls like firewalls to access information that wouldn’t normally be accessible. But how?

How does it work?

Web applications are built to provide a user interface to a service which can be accessed from virtually any web browser. Of course, being an application requires input from a user to gain some sort of an output. Generally, input is data in the form of text/numbers (like words in a search engine) or serialized data that is sent to the application through a POST request.

SSRF vulnerabilities occur when an application accepts an input like a file address or URL, but it doesn’t validate if the user (or in my case, attacker) has the appropriate authorization to access said file or URL. SSRF can be triggered in the backend of applications using data access protocols like file:// and ftp://. Attackers can inject a payload containing one of these protocols instead of http:// or https://, which can cause the backend server to interpret the unauthorized protocol, creating a request to some internal resource. The same is possible with internet facing URLs, again, which may be inaccessible through other means.

SSRF requires the attacker to have control of a request that the application makes.

The application is used as a means to bypass restrictions that are in place, retrieving files or pages which are not normally accessible. Essentially, the attacker is tricking the web application to make a request on their behalf, exploiting a trust relationship with a server or service (which, in a sense, sounds like cross-site request forgery aka CSRF). Often, SSRF is used to access backend resources, such as webapp admin pages or internal services.

Of course, this can lead to some pretty nasty consequences. The particular consequences vary, but they can include confidential information leaks (passwords, session tokens, configurations), internal access to other systems, even remote code execution.

Honestly, it’s a cool vulnerability (for cats like me), but it can spell trouble for an organization that relies on the vulnerable application. As a matter of fact, it’s been trouble for a couple of large organizations over the last few years, namely Microsoft (Exchange - CVE-2021-26855), and potentially Capital One (financial records stolen through an undisclosed web application firewall misconfiguration). Note: There’s still some speculation about the Capital One hack, because the actual attack was never disclosed.

How can I mitigate it?

There are a few ways to mitigate SSRF vulnerabilities, including block-listing or allow-listing objects (file or URL addresses), disabling access to unauthorized data access protocols, and making sure that only specific types of responses are presented back to the client. Let’s talk about these.

Trying to block-list a set of objects will eventually get bypassed with enough time and effort. The easiest (and most secure) way to do input validation on file/URL inclusion is to simply have an allow-list of the objects that the application can access. This accomplishes two different objectives: it tells the application what it can accept as a valid input, and it also validates that no other objects can be accessed, because they’re not on the list. Now, will this list have to be updated? Yes, and potentially often depending on the scope of the application.

Blocking unauthorized data access protocols (SMB, NFS, etc.) and schemes like ftp:// and file:// should be relatively easy to write into code, and again, this is where allow-listing certain protocol schemes like http:// or https:// (or other protocols that are needed for business purposes) is favorable over using a block-list which can be incomplete and potentially bypassed.

It’s also recommended to ensure that any HTTP based responses accept only a specific set of Content-Types which have been vetted for business purposes. This ensures that only specific data types (and no raw data) are being presented to the client in the response.

Welp, I hope you enjoyed this episode of Quick Bites, and maybe learned something new. As always, if you have questions, shoot me an email at aaron.moss@secureideas.com. We’re happy to help!

[1] https://cwe.mitre.org/data/definitions/918.html