Reflecting on the use of SSRF in the Capital One Breach

One of the most notable breaches of 2019 was the Capital One breach, where the attacker used a Server Side Request Forgery (SSRF). It was notable not only because the victim is a household brand name or that an enormous amount of personal information was stolen (standard hallmarks of your headline-grabbing breach) but also because of how the breach was discovered (the stolen data was found in a public Github repo!) and the tactics employed by the attacker.

The details of the breach are fundamentally changing how application security professionals think of what was once considered a fairly pedestrian attack (not even making the latest OWASP Top 10) into something especially concerning in today’s cloud-hosted application environments. That attack, of course, was SSRF, or Server Side Request Forgery.

In this blog post, we’ll review the technical details of SSRF, how it was utilized in the Capital One breach, why it’s so critical to understand for today’s cloud-hosted web apps, and how organizations can protect their web applications and APIs from such attacks.

What is Server Side Request Forgery (SSRF)?

Server Side Request Forgery (SSRF) is an attack where a target application or API is tricked into sending a request to another backend service, either over the internet or across the network the server is hosted on, to retrieve information from that service and relay it back to the attacker.

Typically, this is accomplished by submitting a URL within a web request to an application—if the application or API processing that request is susceptible to SSRF, it will attempt to make a secondary request to the URL contained in the payload of the original, malicious request. The response from that secondary request then makes its way back to the attacker via the vulnerable application. In a way, the SSRF-vulnerable application is being used as a proxy to retrieve information from a backend service or database that wouldn’t trust or allow a direct connection from the attacker. There are legitimate reasons why an application would accept a URL from an end user to retrieve data from another server, e.g. embedding a YouTube video in a social media post. If these features aren’t carefully designed or the traffic isn’t inspected for suspicious URLs, an SSRF attack could be successfully carried out.

How the Capital One Attacker Leveraged SSRF

Here’s a summary of how the Capital One breach played out:

• SSRF was used to retrieve AWS (Amazon Web Services) credentials that were then used to steal the personal information of over 100 million Capital One customers.

• The open-source legacy WAF (Web Application Firewall) ModSecurity was the vulnerable application.

• ModSecurity was deployed on AWS’ EC2 (Elastic Cloud Compute) service and thus had access to an AWS backend service known as the Metadata service.

• The AWS Metadata service is a web service only EC2 instances (virtual machines running on EC2) have access to. When an instance requests that service, it provides metadata information about that instance.

• In the case of Capital One, the vulnerable WAF accepted a malicious request from the attacker, which queried the metadata service and returned the AWS IAM (Identity and Access Management) role running the instance hosting the WAF back to the attacker.

• That role was configured to be overly permissive and had access to the sensitive customer data stored in AWS S3 (Simple Cloud Storage Service) buckets, which the attacker then used to download that data.

The Importance of Detecting SSRF in Modular Cloud Native Apps

With services like the AWS Metadata service required for cloud platforms like AWS, SSRF has become a valuable tool in the attacker’s portfolio in carrying out attacks against modern web applications hosted in the cloud. Furthermore, with organizations rapidly adopting the “cloud native” development pattern and redesigning their monolithic on-premise applications to microservices-based architectures in the cloud, there are more discrete backend services and network connections being made between these services—further increasing the attack surface area when an SSRF vulnerability exists in any client-facing service or application. Although SSRF can typically be detected in the initial north/south (client-to-server) web request, being able to also detect SSRF in east/west (service-to-service) requests is becoming increasingly important as organizations migrate to the cloud and make their applications more modular.

How Can Web Applications Protect Themselves Against SSRF?

In the case of the Capital One breach and SSRF attacks that directly target the AWS metadata service, detection, and prevention boils down to the ability to quickly determine whenever an incoming request attempts to pass on the URL to the AWS metadata service. The AWS metadata service has the IP address of 169.254.169.254, so detecting whenever that IP address is sent in a request is a critical first step in effectively protecting your applications against the attack Capital One fell victim to.

At Fastly, we work hand in hand with our customers to ensure our Next-Gen WAF continuously provides the best protection for all web-based attacks. We’ve recently added a new Power Rule to the product specifically designed to detect and block SSRF attacks targeting the AWS metadata service.

SSRF Rule as shown within the Templated Rules of the Next-Gen WAF’s management console.

Suppose the AWS Metadata service URL appears in the request header, query, or POST arguments. In that case, we will immediately flag the request and, if configured to do so, immediately block the request from reaching the protected application or API. This rule originated as a custom advanced rule developed for some customers within days of when the Capital One breach first made the news. Since then, our engineering team has optimized that rule, improving its performance by nearly 700%, and have made it available to all customers as part of the standard ruleset.

In the months since the Capital One breach, AWS has rolled out version 2 of the AWS Metadata Service, which now requires a token to query it. Although this is an excellent improvement to the service and provides an extra layer of security, it is optional for AWS customers. It requires them to change their cloud configuration to take advantage of it.

Interested in learning more about how Fastly’s Next-Gen WAF can protect against SSRF and other web-based attacks and how it uniquely does so for both your traditional on-premise web apps and your modern, cloud-native ones? Contact us