Best Practices for Configuring Your AWS Perimeter

by Sarah Harvey / October 18th, 2019

Could what happened at Capital One happen at your organization? As a business owner, stakeholder, or IT personnel, that’s the unavoidable fear that appears when you hear about the latest data breach. The Capital One data breach is one of the most damaging data breaches of 2019, and we’ll continue to learn about the repercussions for months to come. This data breach impacts 100 million individuals in the United States and 6 million in Canada. The compromised data was from businesses who filled out credit card applications, and Capital One reports that, “The largest category of information accessed was information on consumers and small businesses as of the time they applied for one of our credit card products from 2005 through early 2019.” Most importantly – we know that this breach could happen to any organization that’s not educated on how to properly configure your perimeter security groups. Let’s discuss web application firewalls (WAF), Server Side Request Forgery (SSRF) attacks, metadata, and how a misconfiguration could lead to a compromised AWS environment and stolen data.

Security Misconfiguration in AWS

Evidence from the Capital One case confirms that this data breach began with a misconfigured open-source WAF used in AWS. The intruder, Paige Thompson (a former AWS employee), launched a SSRF attack to manipulate the WAF into running commands it should have never been allowed to – including the command to communicate with the metadata service on AWS.

The Justice Department’s complaint outlines three commands that Thompson performed to abuse the misconfiguration and extract the compromised data, which was later found on a GitHub file:

AWS WAF uses IAM service-linked roles, meaning that an IAM role is linked directly to the AWS WAF. The first command that was executed leaked the security credentials for a specific WAF role with elevated privileges that had access to folders in Capital One’s AWS environment.
The second command that was executed, the “List Buckets Command,” used the compromised WAF role to list the names of Capital One’s folders in their S3 bucket. Thompson obtained access to over 700 folders.
The “Sync Command” was the final step in actually extracting the data from these folders and/or buckets because the WAF role that Thompson compromised already had the required permissions to do so.

The bottom line? The WAF role was probably assigned too many permissions to begin with, and that combined with the misconfiguration led to a successful SSRF attack that had detrimental consequences.

In a statement given to KrebsOnSecurity, Amazon argued, “The intrusion was caused by a misconfiguration of a WAF and not the underlying infrastructure or the location of the infrastructure. AWS is constantly delivering services and functionality to anticipate new threats at scale, offering more security capabilities and layers than customers can find anywhere else including within their own datacenters, and when broadly used, properly configured and monitored, offer unmatched security—and the track record for customers over 13+ years in securely using AWS provides unambiguous proof that these layers work.”

Mitigating Risks in AWS and Securing Your Perimeter

How could you mitigate potential risks and misconfigurations facing your AWS environment? Cloud security experts at KirkpatrickPrice challenge you to consider the following:

Understand and monitor the configuration of perimeter security systems (including WAFs). They need to be regularly reviewed to ensure that intended rule sets are functioning as designed.
Relying on a WAF, though, to catch exploits is no replacement for proper code creation. The WAF just masks poor code development. Mitigation should focus on good application development hygiene and the enforcement of secure coding practices.
Penetration testing can yield huge benefits for externally-facing web applications and infrastructure. The scope and rules of engagement for the penetration testing, though, must ensure that the testing will include exploits that are specific and unique to AWS environments.
You must protect your internal services. In the Capital One case, the reason the exploit was able to access the information was because of the metadata service. Learn about a proxy for the AWS metadata service here.

How to Strengthen AWS Environments

How do you validate that your AWS environment has been properly configured? How do you determine that your security and privacy practices are effective? How do you protect the metadata service? Who’s responsible for cloud security – you or the cloud provider? We’re afraid that organizations aren’t asking enough questions like these. As more data migrates to AWS, organizations must have processes in place to check their cloud security efforts. Whether that’s through consulting with an AWS Cloud Practitioner or CCSK, something like a SOC 2 audit, or advanced penetration testing, you need a third party’s perspective and expertise to gain assurance.

What consequences would you face if your clients’ data was discovered to be open to the public? We hope you’ll never have to find out. Let’s partner together to ensure that misconfiguration is not your enemy in your cloud environment.