Spotlight on the Server-Side: A Guide to SSRF Vulnerabilities

Server-side request forgery (or SSRF) vulnerabilities can lead to total system compromise and allow access to an organization’s internal or cloud infrastructure if exploited. Today, they are among the top ten highest-paid vulnerabilities on HackerOne, earning hackers over $100,000 in any given month. In April of this year, 196 SSRF vulnerabilities were found in HackerOne customer programs, 28% more than in March.

What is an SSRF?

SSRF is a web security vulnerability that allows modification, extraction, or publication of data by exploiting a URL on the server-side application. They are most common in applications where users can download an asset from an external resource, such as webhooks, integrations, and PDF generators.

Historically, SSRF bugs were relatively benign as they only allowed internal network scanning and sometimes access to internal admin panels. Still, the advent of cloud architecture has inadvertently exposed organizations to more risk due to the cloud metadata service. Instead of pointing to an external resource, the attacker could be pointed to an internal resource when vulnerable. Although this service is not queryable from outside the firewall, the SSRF vulnerability and missing mitigations can still allow attacker access. 

One example of a seemingly typical SSRF is a vulnerability found by hackers @nahamsec, @daeken, and @ziot in Snapchat’s ad platform. After observing abnormal behavior in the application’s import function, the hacker team discovered it could exfiltrate service account tokens and data from the Google Metadata Service. 

Figure 1: SSRF vulnerability reported by hackers to Snap on the HackerOne platform.

What was unique about this bug was that it required bespoke remediation. The application couldn't use the standard SSRF-mitigating proxies because Chrome did not respect proxy settings in certain cases. Moreover, an earlier part of the process still required access to the metadata server for bootstrapping. To remediate, Snap configured iptables to drop traffic to sensitive IPs for a specific restricted user. After initial setup, the application could then perform a one-way switch to the restricted user before using Puppeteer to automate actions with Chrome. The rest of the remediation time was spent fine-tuning this solution and adding necessary permissions for the application to clean up after itself properly. In the end, Snap awarded the hackers with a $4,000 bounty. 

SSRF vulnerabilities represent 23% of organizational bounty payouts, representing the top vulnerability for internet and online services companies. 

What are the implications of an SSRF vulnerability? 

Another vulnerability report submitted by hacker @nahamsec to Lyft demonstrates the implications of SSRFs. Lyft remediated this vulnerability before it was exploited. It could have allowed bad actors access to AWS metadata instance keys and read any files within that network.

Figure 2: SSRF vulnerability remediated by Lyft and submitted by @nahamsec on HackerOne. 

What started as a simple bug that allowed the hacker to insert HTML into the PDF generator and streamline his expense reports became a vulnerability that ran much deeper. With human curiosity and manual security, testing was required to combine a PDF with an XSS to unearth a hidden SSRF, something automated tooling wasn’t able to catch. 

How can you prevent SSRFs from cropping up?

“With the widespread adoption of the cloud, pivoting into an organization's cloud network via SSRF became all too easy with access to technologies like instance metadata and Kubernetes APIs,” said HackerOne hacker Justin Gardner, better known online as @rhynorater. “Companies that have been around for a while can also suffer from a well-targeted SSRF attack due to the weakness remaining from the endless battle of keeping internal assets up-to-date and patched.

The most effective defense I've seen against SSRF is good network segmentation. Every asset (including containers) should have firewall rules set in such a way as to follow the Principle of Least Privilege. If done effectively, this should take the bullet out of the gun for most SSRF attacks.”

Where possible, move security to the earliest possible point in the development process and start software development with security in mind. It’s difficult to rectify security risks after the fact. By working with hackers, insights from vulnerability reports are threaded into development improving application security at every stage. 

When configuring a resource, we recommend starting with the most restrictive policy and adjusting from there. In the name of security, it is better to have to relax a policy over time than to further restrict it. These are both components of the Principle of Least Privilege, which, as Justin mentions, explains that a user should only be given the privileges needed to complete their tasks. By separating systems from the start and initially building in stringent restrictions, it sets the precedent of non-access rather than defaulting to unrestricted access. 

Often, we see companies blocking terms and keywords to patch issues rather than fixing the issue itself. By teaming the Principle of Least Privilege with firewalls, organizations can defend against SSRF instead of using filtering practices. 

Identity and Access Management (IAM) profiles and AWS’s Security Token Service (STS) protect by allowing security and development teams to seamlessly integrate systems without configuring static keys or credentials. Creating associated lists reduces the chances of exposing information to unauthorized parties. It also minimizes the time infrastructure and security teams spend on periodic or incidental key rotation and enables better-scale deployments.

A simple step and industry best-practice, multi-factor authentication enables you to add an extra layer of protection against compromise. This step is a must for any organization and individual and is something we offer for all HackerOne users.

Finally, collecting data about reported vulnerabilities and mistakes is critical when prioritizing security projects. While SSRFs may have a reputation for being unimportant, they can lead to detrimental impacts and point to larger trends in infrastructure. With the increasing speed of releases and deployments, a better model is needed. When you collect vulnerability data, you continuously learn from your mistakes and enable your teams to move quickly and securely.

For more information about reducing risk and getting started with hacker-powered security, check out our CISOs Guide to Deriving Value from Hacker-Powered Security.