SSRF Attacks and Data Breaches: what you need to know
SSRF Attacks – One of the largest banks in the United States was just fined $80 million for a massive data breach – a 2019 incident which exposed personal data of 100 million Americans and six million Canadians.
The breach was the result of an SSRF (Server Side Request Forgery) attack.
This attack has become more common over the last few years, as cloud architectures have created more opportunities for threat actors to use this technique.
If your organization has migrated to the cloud, it too might be vulnerable to SSRF. Here’s what you need to know about defending against it.
Anatomy of an SSRF attack
SSRF exploits a common structure of cloud architectures: that external traffic attempting to enter the cloud is distrusted (and therefore, must be scrubbed of threats before it is accepted), while intracloud traffic (i.e., requests passing between internal services) is inherently trusted.
An SSRF attack masks hostile requests by making them appear to be legitimate internal traffic. If the targeted network is not sufficiently hardened against SSRF, the services will accept and process the requests, allowing the attacker to accomplish a variety of malicious actions.
SSRF is not a new threat vector; it is possible to use it to attack a traditional on-premise network. But cloud architectures have several characteristics that make SSRF attacks more challenging to defend against. To illustrate, let’s discuss the Capital One breach.
Capital One: a real-world example
Capital One Financial had migrated much of its IT operations to the cloud but had misconfigured a WAF. The attacker discovered this and used the WAF to send a request to an internal IAM (Identity and Access Management) service. This service is inaccessible to traffic sources outside the cloud, but it trusts and accepts requests from internal network elements such as the WAF. Thus, it answered the request.
The attacker received a response containing credentials for the WAF’s compute instance. The attacker then used these credentials to query backend storage resources, discover their contents, and then systematically exfiltrate the data to an external web repository.
For this attack to succeed, multiple security holes had to exist. Among them are these:
- The WAF did not properly filter the initial request. The attacker was able to use the WAF to query the IAM service and receive a response.
- The WAF had been granted overly generous permissions. If the WAF’s IAM role had been appropriately restricted, the attacker could not have used its credentials to do much. A WAF usually does not need access to backend storage, or permission to iterate through its buckets and list their contents. But Capital One’s WAF did have these broad permissions, and so the attacker had the ability to iterate through cloud storage and steal data from it.
- Capital One did not have adequate SSRF detection set up. Executives didn’t know that this attack had occurred until several months later, when a third party stumbled across the exfiltrated data in a Github gist and notified them.
Some of these problems could potentially exist in a traditional network. However, some are unique to the cloud. For example, the forged request for credentials succeeded because the attacker was familiar with the specific cloud provider that Capital One used, and thus knew the IP address of the internal IAM service.
We see then that a cloud architecture can open up new opportunities for SSRF attacks, if the targeted organization does not properly harden its network against them. This hardening requires a multi-pronged approach that includes both detection and prevention. Let’s discuss these next.
Detecting SSRF attacks
There are several possible ways to detect SSRF attempts. They vary in their effectiveness, complexity, and cost.
Native threat detection: Some cloud providers offer threat-detection services as part of their platform. For example, Amazon Web Services (AWS) offers AWS GuardDuty.
As native products, these are usually straightforward to deploy and use. Unfortunately, when detecting SSRF these products tend to be retroactive; they cannot detect the initial forged requests, so they can only report an attacker’s usage of compromised credentials. By that point, the damage has already been done.
Per-host detection: System administrators can deploy host-based intrusion detection systems, or use tools that are already part of the environmental toolchain. For example, a Linux environment includes iptables and auditd. These can be used for monitoring traffic being sent to specific endpoints. Rules can trigger logging for unusual access attempts (e.g., attempts originating from users or processes that would not typically need access), and then existing log aggregation tools can be parsed for events indicating a potential attack. This approach can be effective; however, setting it up correctly is labor-intensive, time-consuming, and requires a high level of expertise from the admins.
Note that neither of the options described above will be effective unless system logs are continually monitored and alerts are fired when anomalies are detected. For example, Capital One appears to have had thorough logs, because admins were able to retrieve the specific requests by which their network was breached. Unfortunately, it appears that the logs were not monitored (or alerts were ignored), because the bank did not know a breach had occurred until a third party found the stolen data.
Detection by a web security platform: If a third-party security service is used to block SSRF attempts, then it will typically include reporting as part of the platform. It is usually straightforward to set up accompanying alerts and alarms that will fire whenever a problem is detected. More on this below.
Preventing SSRF attacks
Robust threat detection is important, but clearly, prevention is even better. Setting up effective defenses can preclude the need to triage, assess, and clean up penetration attempts, not to mention the financial damage that can result from a successful breach.
There are several approaches to SSRF prevention. All of them should be followed as much as possible.
Web-facing applications must sanitize their inputs. Sanitizing inputs with a focus on URL parsing can help block an important vector for SSRF attacks. Many frameworks include validation libraries; use them! Also ensure that validation is done by the server application; even if client-side validation is performed, this can be bypassed by an attacker, so don’t rely on it.
Sanitization should account for possible obfuscation/encoding of hostile inputs. Also, architecture-specific rulesets should be constructed and enforced. For example, AWS, Google Cloud Platform, and Microsoft Azure all use 169.254.169.254 as the IP address for their backend IMDS (Instance Metadata Service). Rarely, if ever, should a web-facing application accept a request containing that IP.
Use the principle of least privilege for your IAM. The major cloud providers offer fine-grained control over identity and access permissions. Every application and service in your network should have an appropriate role assigned, and every role should have only the least amount of permissions necessary.
Use the latest features and capabilities of your cloud provider. The top-tier providers are well aware of the current web threat environment and are constantly innovating ways for their customers to harden their networks. For example, AWS has released Version 2 of its IMDS, which uses a session token to ensure that requests for data are secure and authorized. Meanwhile, Google Cloud supports a custom header (Metadata-Flavor) to make it easier for services to identify legitimate intracloud traffic. Your organization should have a strategy to monitor your provider’s release schedule for new security capabilities, and to adopt them as quickly as possible.
Use a robust web security solution to scrub incoming traffic of SSRF and other threats. The top-tier providers include some native security products (e.g., AWS WAF, Google Cloud Armor, and the WAF in Azure Application Gateway). However, they are not comprehensive security solutions, nor are they meant to be. Furthermore, SSRF attacks are merely one among a broad spectrum of threats on today’s Internet.
There are a number of third-party solutions available which can provide protection against SSRF and other threats. A cloud security solution deployed as a reverse proxy can scrub incoming requests before they reach the protected applications and APIs. Furthermore, some solutions already include many of the requirements listed above: input sanitization, encoding/obfuscation detection, preventing access attempts to a backend IMDS, and so on. (This doesn’t mean your applications and network shouldn’t be hardened. The best practice is to have multiple layers of protection.) Having an effective solution in place is an important part of a good security posture for cloud workloads.
As discussed above, there isn’t a single magic bullet for either detection or prevention of SSRF attacks. A multi-layered, vigilant approach is the best practice for keeping an enterprise secure in the cloud.
SSRF Attacks and Data Breaches: what you need to know