Making a Federal Case of the Capital One Hack


Written by Tim Haight

I'm VP of Technology Services for CGNET. I love to travel and do IT strategic planning.

October 31, 2019

On October 24, Senators Elizabeth Warren and Ron Wyden wrote the Federal Trade Commission asking that the FTC determine whether Amazon engaged in an unfair business practice because of its role in the Capital One hack.

According to CNBC, an AWS spokesperson said in a statement, “The letter’s claim is baseless and a publicity attempt from opportunistic politicians.” But was it? And now that everybody is moving resources to the cloud, what can we learn from this case about doing things differently?

What Happened

The Capital One hack, revealed last July, resulted in the theft of personally identifiable information about 100 million Americans and six million Canadians. Capital One’s information was stored on AWS. You can read the basic details here. The hacker gained access to a misconfigured Capital One Web Application Firewall (WAF) and then used the firewall to send requests to AWS’ metadata service, which provided the firewall with temporary credentials to access servers in its cloud.

Once the hacker had the temporary credentials, she (assuming the person accused of the crime did it) was able to mirror s3 buckets, convert desired snapshots into volumes and mirror the volumes to her server via a storage gateway.

Security researcher Brian Krebs has written a couple of excellent posts about the hack, which are here and here.

The key weakness in the chain of lateral movement and privilege escalation was vulnerability to a Server Side Request Forgery (SSRF) attack. The forged server-side requests came from the compromised Capital One WAF and attacked AWS’ metadata service. This is where the hacker got the credentials to access the other servers.

The Perils of SSRF

As Senators Wyden and Warren wrote in their letter, “SSRF attacks can be used by hackers to steal valuable data from servers rented from cloud computing companies. Amazon’s largest competitors have included mandatory protections against SSRF attacks in their products for several years – Google since 2013 and Microsoft since 2017. Amazon’s failure to add a similar software protection against SSRF attacks to its Amazon Web Services (AWS) cloud computing product has been the subject of significant public discussion among cybersecurity experts for the past five years, including in presentations at major industry conferences.”

What do we know so far? It looks as if both Capital One and AWS are responsible for weaknesses that allowed the hack to happen. Capital One should have configured its WAF better so it couldn’t have been taken over. Amazon should have protected its metadata service better, so a hijacked firewall couldn’t get temporary credentials to access other servers.

Evan Johnson, manager of the product security team at Cloudflare, has described some of the ways that can be used to protect against SSRF attacks. Krebs quoted Johnson as writing, “SSRF has become the most serious vulnerability facing organizations that use public clouds. The impact of SSRF is being worsened by the offering of public clouds, and the major players like AWS are not doing anything to fix it. The problem is common and well-known, but hard to prevent and does not have any mitigations built into the AWS platform.”

Oh, What to Do?

What are the implications of this for organizations storing data in the cloud or moving there? First, it looks like AWS, at least, has a major vulnerability that it knows about and doesn’t want to fix. Krebs mentioned that protections could break a lot of backwards compatibility in AWS. In other words, full confidence in the security provided by cloud vendors is, at least in this case, misplaced.

Second, Capital One should have managed its Web Application Firewall better. This points out that just moving applications and data into the cloud is not going to absolve an organization’s IT staff (e.g., you) from some serious work requiring a good deal of specialized knowledge. Sigh.

Third, it may indeed be time for “opportunistic politicians” to get into the act. We have a history of requiring products to perform as advertised. Tap water is supposed to be safe to drink. Prescription drugs aren’t supposed to kill you. Maybe bringing the force of law to bear, or writing new laws, is necessary. Here’s another interesting quotation from the Wyden-Warren letter:

“The FTC has made it clear that companies have an obligation to act on third-party reports of cyber security vulnerabilities. In the FTC’s 2013 case against the smartphone manufacturer HTC, the FTC established that companies must “implement a process for receiving and addressing security vulnerability reports from third-party researchers, academics or other members of the public.” HTC’s failure to do so, the FTC argued then, constituted an unfair business practice.”

Lots of evidence exists that Amazon has known about the danger of SSRF attacks and done nothing about it. Google it. Wyden and Warren have shown a precedent for the principle that ICT vendors should pay attention to these dangers and fix them. Let the investigation begin!

Written by Tim Haight

I'm VP of Technology Services for CGNET. I love to travel and do IT strategic planning.

You May Also Like…

You May Also Like…


Translate »
Share This