On July 19, 2019, Capital One Bank received a message, of which is afraid every modern company – has occurred a data leak. 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 didn’t happen 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 Capital One started to know that something had happened.

Former Amazon employee is arrested, she faces a fine of $ 250 thousand and five years in prison … but there is still a lot of negativity. Why? Because many companies that have been hacked are trying to keep aside responsibility for strengthening their infrastructure and applications against 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 downloaded.

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 accepted all and said that they closed the issue.

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

If you are interested in why we do not go deep into this part, understand that because of limited information we can only speculate. This is pointless especially because the hack depended on the “hole” 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 options and methods can range from wildly stupid oversights to incredibly complex patterns. Because of the possibilities range, this will turn into a long story 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 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:

Trust Policy – which services or which people can use this role?

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, like 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:

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.

Use AWS CLI

If the AWS command line interface is installed, it is loaded with the credentials from the IAM roles, if any of them exist. 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:

• She gained access to the server (EC2 instance) through a hole 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.
• Once on the server, she was able to act “as if” she was the server
• 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 of the cloud infrastructure, DevOps, and security experts. And how valuable and cost-effective is the transition to the cloud? So much that even in the time 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. And contact the best professionals in cybersecurity to start right now!