Summary
This week a massive data breach at Capital One was announced. In this case, an internal actor was able to presumably use insider information to gain access to data stored in S3. In this article I will examine this data breach and provide best practices to prevent this from happening to your organization.What happened?
This breach has been covered in depth in many places. If you are not familiar with what happened, check out CNN. For more technical details, check out this article. To summarize, an ex-AWS employee that was working for Capital One was able to gain unauthorized access to an EC2 instance and get data from an S3 bucket. This data contained a lot of information about Capital One customers and they are estimating the damages to be from 100-150 million dollars.
This is a serious issue as Capital One has long been regarded as one of the premiere examples of a large financial company moving to the cloud. People are likely to see this and wonder how they can prevent something like this from happening, when Capital One couldn’t.
How could this be prevented?
We don’t know what method was used to connect to the servers, but I don’t think it is too much of a stretch to say it wasn’t over a protocol that was required for the application to function properly, typically HTTPS. A security group that only allowed necessary traffic may have been enough to completely prevent this attack.
However, we would like to have multiple layers to our security posture. After all, people make mistakes. So let’s assume someone made a mistake and pushed out a security group that is too permissive. My second recommendation is that you never expose EC2 instances to the public internet. Some may fairly ask, but how can we do this? Our applications need to be used by customers. The answer is to put some cloud native, AWS managed service in front of it. This could be an API Gateway, ELB, ALB, or NLB in this case.
My next recommendation for preventing this type of attack is to use serverless technologies. The attacker would have never been able to gain access to an instance and the AWS role and SDK therein if the instance never existed. Servers are a huge risk for these types of breaches. You should run your applications in Fargate or Lambda.
Governance Models
From a SecOps perspective, how could these vulnerabilities been caught? First, an AWS Config rule can easily catch open security groups. There are even managed rules for it. Installing these rules into your AWS account takes seconds. There is also a rule for not allowing EC2 instances to have a public IP address.
Second, enable GuardDuty on your accounts. Reports say the attacker used onion routing to hide their identity. It is likely that GuardDuty would have picked up and alerted on this traffic. Neither of these things are that difficult to do and I highly recommend these steps at a minimum on all the accounts in your organization.
Conclusion
This attack was interesting as it wasn’t the typical public S3 bucket issue that we have seen a lot in the past. But as I have demonstrated, AWS has made it easy to prevent attacks of this nature. Rest assured that you can prevent them from happening to your organization with the proper governance outlined above. If you have not setup AWS Config and GuardDuty (or similar solutions), I recommend you do so immediately.
