Technical details of hacking Capital One bank on AWS

On July 19, 2019, Capital One Bank received a message that every modern company is afraid of - a data leak has occurred. It affected more than 106 million people. 140,000 US Social Security Numbers, one million Canada Social Security Numbers. 80,000 bank accounts. Unpleasant, agree?



Unfortunately, the hacking did not happen at all on July 19th. As it turned out, Paige Thompson, aka Erratic , performed it between March 22 and March 23, 2019. That is almost four months ago . In fact, only with the help of external consultants did Capital One know that something had happened.



Former Amazon employee arrested, she faces a fine of $ 250 thousand and five years in prison ... but there is a lot of negativity. Why? Because many companies that have been hacked are trying to brush aside responsibility for strengthening their infrastructure and applications amid growing cybercrime.



In any case, you can easily google this story. We will not go into drama, but talk about the technical side of things.

First, what happened?

Capital One had about 700 S3 bucket that Paige Thompson copied and deflated.

Secondly, is this another case of an incorrectly configured S3 bucket policy?

No, not this time. Here she gained access to a server with an incorrectly configured firewall and from there she conducted the entire operation.

Wait, how is this possible?

Well, let's start by logging into the server, although we have few details. We were only told that this happened through an “incorrectly configured firewall”. So, something as simple as the wrong security group settings or the configuration of the web application firewall (Imperva), or the network firewall (iptables, ufw, shorewall, etc.). Capital One only pleaded guilty and said that it closed the hole.

Stone said that Capital One did not initially notice the vulnerability of the firewall, but responded quickly as soon as it found out about it. Of course, this was helped by the fact that the hacker allegedly left the key identifying information publicly available, Stone said.

If you are interested in why we do not delve into this part, understand that because of limited information we can only speculate. This is pointless given that the hack depended on the gap left by Capital One. And if they don’t tell us more, we’ll just list all the possible ways that Capital One left its server open in combination with all the possible ways that someone could use one of these various options. These gaps and methods can range from wildly stupid oversights to incredibly complex patterns. Given the range of possibilities, this will turn into a long saga without a real conclusion. Therefore, we will focus on the analysis of the part where we have the facts.

So the first conclusion: know what your firewalls allow

Establish a policy or the right process to ensure that ONLY what is open is open. If you use AWS resources, such as Security Groups or Network ACLs, obviously the checklist for verification can be long ... but as many resources are created automatically (i.e. CloudFormation), you can also automate their audit. Whether it’s a makeshift script that scans for new objects for flaws, or something like a security audit in a CI / CD process ... there are many simple options to avoid this.



The “fun” part of the story is that if Capital One had closed the hole from the start ... nothing would have happened. And therefore, frankly, it is always shocking to see how really something quite simple becomes the only reason for the hacking of the company. Especially as big as Capital One.

So, the hacker is inside - what happened next?

Well, after breaking into the EC2 instance ... a lot can go wrong. You walk almost along the edge of a knife if you allow someone to go that far. But how did she get into the S3 bucket? To understand this, let's discuss the roles of IAM (IAM Roles).



So, one way to access AWS services is to be a User. Okay, this is pretty obvious. But what if you want to give other AWS services, for example, your application servers, access to your S3 buckets? For this, there are IAM roles. They consist of two components:

1. Trust Policy - which services or which people can use this role?
   
   
2. Permissions Policy - what does this role allow?

For example, you want to create an IAM role that will allow EC2 instances to access the S3 bucket: firstly, it sets up a Trust Policy for the role that EC2 (the entire service) or specific instances can take over the role. Assuming a role means that they can use role permissions to perform actions. Secondly, the Permissions Policy allows the service / person / resource that "took on the role" to do something on S3, be it access to one specific bucket ... or to more than 700, as in the case of Capital One.



Once you are in an EC2 instance with the IAM role, you can obtain credentials in several ways:

1. You can request instance metadata at http://169.254.169.254/latest/meta-data
   
   
   
   
   
   
   
   Among other things, at this address you can find the IAM role with any of the access keys. Of course, only if you are in an instance.
   
   
2. Use AWS CLI ...
   
   
   
   If the AWS command line interface is installed, it is loaded with the credentials from the IAM roles, if any. It remains only to work through the instance. Of course, if their Trust Policy were open, Page could do it directly.

Thus, the essence of the IAM roles is that they allow one resource to act FROM YOUR NAME on OTHER RESOURCES.

Now that you understand the roles of IAM, we can talk about what Page Thompson has done:

1. She gained access to the server (EC2 instance) through a breach in the firewall
   
   
   
   Whether it be security groups / ACLs or their own web application firewalls, the hole was probably quite easy to close, as stated in the official records.
   
   
2. Once on the server, she was able to act "as if" she was the server
   
   
3. Since the IAM server role allowed S3 access to these 700+ bucket, she was able to access them

From now on, she could only run the List Buckets



command, and then the Sync



command from the AWS CLI ...

---

Capital One Bank estimates damage from hacking in the amount of from 100 to 150 MILLION dollars . Preventing such damage is why companies invest so much in protecting the cloud infrastructure, DevOps, and security experts. And how valuable and cost-effective is the transition to the cloud? So much so that even in the face of more and more cybersecurity challenges, the overall public cloud market grew by 42% in the first quarter of 2019 !



The moral of this story: check your safety; conduct regular audits; respect the principle of least privilege for security policies.



(You can see the full legal report here).