Cybercrime , Fraud Management & Cybercrime , Governance & Risk Management
Capital One's Breach May Be a Server Side Request Forgery
SSRF Appears to Fit Scenario, But Details Are SlimCapital One’s enormous data breach is the subject of intense scrutiny as well as fear among companies. It’s likely months before a definitive post mortem will appear.
See Also: AI and ML: Ushering in a new era of network and security
But enough detail has been released so far to give security professionals enough to ponder about how one of the biggest breaches possibly occurred.
The criminal complaint against Paige A. Thompson, the accused intruder, alleges she bypassed a misconfigured Capital One firewall and obtained administrative credentials for an account, which is described as “*****-WAF-ROLE.” That account had enough privileges to view and copy data behind the firewall, resulting in the breach (see: Capital One: Where Did the Bank Fail on Defense?).
That has led to theories that the intruder may have leveraged a server side request forgery, a type of web application vulnerability that security blogger Brian Krebs wrote about on Friday. Meanwhile, other security companies and experts concur an SSRF flaw is indeed a strong candidate, but one that has yet to be confirmed.
What’s SSRF?
Evan Johnson, who is part of Cloudflare’s product security team, writes that SSRF is a bug hunter’s dream in that it can yield critical vulnerabilities. An SSRF attack involves tricking a server into accessing a resource it shouldn’t be touching on behalf of the attacker. In a tweet, Johnson describes SSRF as “the new RCE [remote code exploitation].”
Thompson, 33, of Seattle, worked for Amazon’s S3 between 2015 and 2016. Capital One uses S3, which has led to speculation she may have had an inside track on weaknesses at the bank. She is accused of accessing personal data belonging to 106 million people in the U.S and Canada, some of which was on credit card applications collected by the bank between 2005 and this year.
Johnson outlines how a SSRF attack could have been pulled off against Capital One. AWS uses what’s called a metadata service, which supplies fresh IAM credentials for a new image. The metadata service runs on a hypervisor, and an HTTP request to an IP address – for AWS it is 169.254.169.254 - can obtain new temporary credentials.
“The metadata service is amazing,” Johnson writes. “It provided customers with a mechanism to write software that securely authenticates with AWS services without requiring any special code or handling of real IAM keys (which have been the source of many other breaches).”
But the request to the metadata service isn’t authenticated or authorized, Johnson writes.
“My rule of thumb is that anywhere a hostname or IP address is accepted as user-input, there is a 50 percent chance that SSRF is possible and an attacker could potentially make requests to the metadata service,” Johnson writes.
Capital One uses ModSecurity, an open-source WAF that originally grew out of the Apache project, Krebs reports.
CloudSploit, which specializes in cloud security, summarizes Capital One’s breach as a two-step problem: First is the SSRF issue that may have led to the capturing of temporary credentials for a role. The second issue is that role may have had too many permissions for backend data.
It’s a mistake that’s likely pervasive, CloudSploit writes.
“While it may be easy to blame Capital One’s developers for the loss of data, the truth is that IAM role misconfigurations are likely present in nearly every single AWS account,” CloudSploit writes. “Very few developers take the time to carefully list each permission required; oftentimes a wildcard is used in many more places than it should be, resulting in unintended access. Without a compromising factor, this misconfiguration is likely to go unnoticed indefinitely.”
Securing Metadata Services
Still, there’s something not quite right with the scenario, writes Christian Folini, a webserver engineer and a security consultant at Netnea. Two years ago, Folini co-authored the ModSecurity Handbook with security researcher Ivan Ristic.
Folini tweeted that he couldn’t see how ModSecurity could have been misconfigured to allow for SSRF. “There is some piece of the puzzle that’s missing,” he writes.
Kenn White, a security expert and co-director of the Open Crypto Audit Project, writes that there may be another Apache proxy or gateway module, ModProxy, in the mix, which perhaps allowed outbound metadata service calls.
Nonetheless, Johnson writes that AWS should take steps to prevent attackers from taking advantage of the metadata service via SSRF.
“In my opinion, it’s clear that AWS’ product offering is not complete since this is a major and recurring problem amongst their biggest customers,” Johnson writes. “AWS should do something about this because IAM is the root of all security within AWS.”
One idea is to enforce a special header for requests going to the metadata service. He writes that Google offers this for IAM roles on its Cloud Platform. The header won’t necessarily stop all SSRF scenarios, “but it is an improvement and provides protections for simple webhooks implementations where customers can provide only a URL that receives requests.”
"My rule of thumb is that anywhere a hostname or IP address is accepted as user-input, there is a 50 percent chance that SSRF is possible and an attacker could potentially make requests to the metadata service."
—Evan Johnson, Cloudflare
Another idea is to require a second authentication factor when someone is trying to use credentials gained from metadata services, Johnson writes. This somewhat slows the workflow, but it also means that an attacker who successfully pulls credentials from metadata services can’t use them.
Another way to blunt an attack using temporary credentials would be to ensure the credentials are only submitted only within an organization’s own private cloud. Johnson writes that temporary credentials can be submitted from another customer’s VPC as well as, for example, someone sitting at home on a laptop.
“Determining when a credential has been compromised and is being used in the wrong VPC would require a lot of work from AWS,” Johnson writes. “However, this is something that power users of AWS have started to figure out how to detect, and the folks at Netflix have published some amazing research on the subject.”