Further Decomposing the Capital One Incident

Summary

Previously I discussed how to prevent a security incident similar to the one that occurred at Capital One earlier this year. In this post,I will expound further on what went wrong there from a data protection perspective and make recommendations on how to protect your data hosted in S3.

SSRF Vulnerabities

It has some come to my attention that the Capital One data breach may have been caused by an SSRF vulnerability in an EC2-based WAF appliance. If you do not know how an SSRF vulnerability could allow users to access your AWS account with an EC2 instance profile I highly recommend you read this post and follow along in your own AWS account. Seriously, do it right now.

Now that we are back and everyone knows how IAM Instance Profiles and the AWS metadata service can be exploited for profit and gain, let’s continue. It occurs to me that the strategies outlined in my previous post may have been insufficient to protect against this attack. So we will look at some other aspects of the security around this infrastructure and formulate a more robust Defense in Depth strategy.

Network Appliance Permissions

“A network appliance with a public IP should not be running with an instance profile.”

As far as we know, in the Capital One data breach, an exploit was taken advantage of on a EC2-based WAF appliance. A network appliance with a public IP should not be running with an instance profile. Let alone one that allowed access to all S3 data. Unfortunately, this is an easy mistake to make as many application teams will create a role for their application and give it to all the instances they manage. In the case of a data lake type application, that’s a lot of data. I am unsure of whether or not the Capital One application was appropriately permitted to access all S3 data, but for the purpose of this post, let’s assume it was as there are use cases to configure such an application.

Data Hosted in S3

“these S3 buckets should have had policies attached to them that only allow API calls from a VPC”

Like so much business data, the data breached in the Capital One attack was hosted in S3. The instance profile attached to the WAF allowed the instance to access all the data. Problem is, the attacker was able to gain access to the credentials and hijack the session of the instance. To protect against this malfeasance, S3 buckets should have policies attached to them that only allow API calls from a VPC. You can do that by adding a condition to the policies that denies requests not coming from the VPC.

{
   "Version": "2012-10-17",
   "Id": "Policy1415115909153",
   "Statement": [
     {
       "Sid": "Access-to-specific-VPC-only",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::<YOUR BUCKET>",
                    "arn:aws:s3:::<YOUR BUCKET>/*"],
       "Condition": {
         "StringNotEquals": {
           "aws:sourceVpc": "<YOUR VPC ID>"
         }
       }
     }
   ]
}

If the above solution had been attached to the S3 buckets that were hosting the data, the attackers requests for that data would have been denied. This is, of course, assuming the attacker did not have shell access to the machine. Which is what the “no EC2 instances with public IP addresses” rule could have prevented. Most data services similar to S3 will support such conditions. Alternatively, adding a VPC endpoint with a corresponding aws:sourceVpce condition would also be appropriate in this situation.

Conclusion

As you can see, AWS gives you the ability to create solid defense in depth security to protect your data hosted in S3. It is critical to lock down these buckets such that only internal traffic from a VPC is allowed. In fact, this should be a requirement on most non-public (website) buckets. It is not sufficient just to make the buckets private. Looking at it from a data perspective, the data should not be overly reliant on IAM permissions to protect itself from intrusion.

In addition, a configuration alert should be created which flags all EC2 instances with public IP addresses that are running with an instance profile. You should audit these instances and verify that all the permissions are absolutely necessary and that their are security controls in place that protect the data.

Avatar
Kerry Wilson
AWS Certified IQ Expert | Cloud Architect

Coming from a development background, Kerry’s focus is on application development, infrastructure and security automation, and applying agile software development practices to IT operations in the cloud.

Related