By now we’re all aware of the breach at Capital One, which affected nearly 106 million U.S. and Canadian residents, due to an attacker bypassing a web application firewall (WAF) Capital One was using as part of its operations in the cloud. In a nutshell, the attacker was able to trick the WAF into sharing credentials with access to Capital One’s AWS operations, thus leading to the data breach. The WAF possessed excessive permissions – enough to view and copy information behind it in AWS S3 buckets.
Specifically, consensus has emerged that this is a Server-Side Request Forgery (SSRF) attack. Our aim here is not to conduct an attack post-mortem but rather think about how to best move forward. For a thorough, digestible review of the attack, please read Brian Krebs' excellent write up.
How it happened: a perfect storm
A few things came together to form a perfect storm of bad news to let a breach like this happen.
- For starters, the WAF that was in place did not possess the right rule set to stop the SSRF attack. Strike one. The OWASP top ten list tracks the most critical security risks to web applications that must be protected against, and it turns out the SSRF isn’t in the top ten. SSRF attacks will certainly get a lot more attention from here on out and we might even see them moving onto the top ten list.
- Also, there was the suggested vulnerability that allowed the well-crafted SSRF to leak credential back to the attack. Strike two.
- And finally the excessive permissions of the credentials allowed for broad S3 bucket access – to gain access to lots of sensitive data. Strike three.
We are left with a straightforward consideration: how do we prevent this in the future?
Keep your eyes on the ball
Imagine the on-prem network. If an organization has trouble patching critical vulnerabilities and they eventually get popped – should the network IPS take all the blame? Probably not.
In this case, WAFs should not bear all of the blame. Over-rotating on the fault a WAF did or did not have takes our eyes off of the cloud security ball.
What do we mean? We mean that strong cloud security goes beyond the technologies deployed.
For starters, security conscious application development is vital to ensure applications are not vulnerable to attack. Developers must understand threat models, what attacks are and how they work. And then build secure applications which is rooted in a culture of building in security from the outset. Having a secure software development lifecycle (SSLDC) that covers all parts of development from design to coding to review to testing for both the software as well as for the infrastructure that runs that software.
The breach also serves as yet another public service announcement for understanding the shared responsibility model in the cloud. It’s vital to understand, if you don’t already, where the providers’ responsibilities end and where the customers’ begin. This is how AWS describes shared responsibilities, which includes "...using IAM [Identity and Access Management] tools to apply the appropriate permissions."
Also, least privilege (or Zero Trust if you want to call it that) makes for more effective security postures. In this case, data segmentation in the cloud can be a pragmatic way to limit exposure by breaking up data into small pieces and surrounding those pieces with least privilege access.
Considerations moving forward
We have reflected on a few things to bear in mind moving forward to strengthen security postures in the cloud:
- Least privilege: Data segmentation with least privilege is a very good idea to bring Zero Trust principles into play. In this case, ensure data is not stored in larger buckets, but rather broken up into smaller chunks and placed in folders. Use IAM policy to extend least privileged user access to each folder, in order to limit data exposure. If necessary, call on native controls major cloud providers offer to help review and narrow IAM policies and permissions.
- Cloud threat detection: Use threat detection and monitoring to detect malicious and unauthorized behavior in cloud accounts and workloads. Cloud providers and many third-party security companies offer this. It’s possible that when something breaks through your preventative controls, detection is one of your last lines of defense.
- Web application firewalls: Ensure you are comfortable with the rule set in any WAF having a threat model that considers all types of attacks. Intelligent attackers are not just going to stick to the OWASP top 10.
Finally, what we are seeing here is an example of an attacker stringing together a number of issues, any one of which would not be deadly, but the sum of which can lead to a breach. I predict we see more of this type of pattern in the future – small vulnerabilities chained together to make one big breach.
As we move forward, let’s take what learnings we can from the incident and keep our eyes on the ball as we continuously harden our security postures.