What can we learn from the Capital One data breach?

Last week, we discussed the major details of the Capital One data breach, which resulted in 106 million credit applications, 140,000 Social Security numbers and 80,000 bank account numbers being compromised. This week, we’ll take a look at what went wrong.

Misconfigurations and server-side request forgery (SSRF)

The core of this attack was a configuration problem on the web application firewall (WAF) on Capital One’s server at its cloud provider, Amazon Web Services (AWS). This misconfiguration allowed a server-side request forgery (SSRF) attack, which involves an attacker manipulating URLs to allow them to make requests to unintended locations. Ultimately, this allowed the attacker to gain unauthorized access to the buckets housing the credit applications, Social Security numbers and bank account numbers.

Capital One was storing the data on AWS’ Simple Storage Service (S3) and was running virtual machines on AWS’ Elastic Cloud Compute (EC2). This meant that the data and systems were sharing the physical infrastructure with other customers, but it was isolated logically. Capital One had virtual machines responsible for different tasks, each with their own sets of policies and permissions for access. However, they were all running on top of the same AWS hypervisor.

When one of these virtual machines wants to upload a file to S3, the VM makes a request to the metadata service to get temporary credentials to access S3. These requests never go out over the network—the metadata service runs locally on the EC2 instance. AWS assumes that the customer trusts the underlying hypervisor.

The metadata service doesn’t have any authentication or authorization, which makes it really easy to access the temporary credentials. HTTP requests are trusted, which opens up the door for SSRF attacks to the metadata service.

Capital One had misconfigured ModSecurity, an open-source web application firewall (WAF), on the AWS server. This misconfiguration allowed the attacker to perform an SSRF attack and manipulate the firewall into relaying requests to the metadata service. Capital One had given the WAF way too many permissions, which meant that the attacker could access credentials from the metadata service that should have otherwise been locked down. This is what enabled them to access the 700 S3 buckets that contained the sensitive customer data.

Although AWS was not directly responsible for the attack, the configuration problem was an easy mistake to make at the time. The good news is that AWS has since released a new protocol to address the issue, the Instance Metadata Service Version 2 (IMDSv2). The second version of the protocol protects each request with session authentication, which means that the attacker would have had to authenticate themselves via password before gaining access to the buckets. Using IMDSv2 on AWS can help to prevent similar issues from occurring at your company, but it’s not the only solution you should be thinking about.

The principle of least privilege

One of the key issues that led to the data breach was the fact that the WAF just had way too many permissions. The principle of least privilege essentially states that any employee or entity should have the minimum number of permissions that they need in order to do their job effectively. They should only be granted access to the things that they really need, and if their role changes, their permissions should be updated accordingly. The WAF should never have been granted such wide access—if the admins had locked it down, the attacker would have only been able to access a fraction of the data, saving the company from such a monumental data breach.