Cloud Penetration Testing the Capital One Breach

By Alexander Getsin, Lead Author for Cloud Penetration Testing Playbook

Aligning the Capital One breach with the CSA Cloud Penetration Testing Playbook

In March 2019, Capital One suffered a unique cloud breach. 140,000 Social Security numbers and 80,000 linked bank account numbers were exposed, along with some 1 million Canadian Social Insurance Numbers. It isn’t the numbers that make the breach special and worth learning about.

The initial point of compromise in this breach was a misconfigured proxy (modSecuritymodProxy, a Web Application Firewall), employed by Capital One. The attacker used the misconfigured instance to steal credentials from the meta-data service of the cloud instance. This is arguably the first high-profile breach using this technique. Capital One had to deal with a novel attack that employed a cutting-edge technique exclusive to cloud environments. Despite their impressive efforts at cloud security, their chances were slim in this case.

Just a few months ago, the Cloud Security Alliance’s (CSA) Top Threats Working Group published the Cloud Penetration Testing Playbook. This playbook identifies this very attack technique. The playbook also describes 94 other public cloud attack vectors, concerns, considerations and test cases for testing and attacking public cloud environments and systems.

What was the Breach?

The initial compromise technique employed in this breach was the abuse of a particular feature of a misconfigured proxy (a web application firewall) employed by Capital One. The nginx server hosting the web application firewall accepts web requests meant for backend applications, processes and fulfills or responds to them as a proxy does. This specific nginx misconfiguration allowed requests to the meta-data service at 169.254.169.254.

AWS infrastructure services and consumers use the meta-data service to store environment variables. Some of the many variables and data stored in the AWS meta-data service (similar to GCP and Azure) are the temporary STS credentials that allow the instance to assume any role that has been passed to it. Anyone familiar with curl or a proxy client (such as Burp proxy) can generate requests to this meta-data service if they have local access to the instance, or if the instance is misconfigured to serve web requests to its local meta-data service.

The latter was the case: the vulnerable nginx WAF proxied web requests to itself and also served any other requests. The attacker called its iam/info meta-data to get available role names and then the temporary credentials meta-data to obtain the actual credentials at -

http://169.254.169.254/latest/meta-data/iam/securi...

At that point, the attacker was in. Amongst other privileges, the role associated with the WAF instance had S3 bucket privileges. It’s easy AWS CLI work from there.

What Made this Breach Special?

This is arguably the first high-profile breach using this technique. It is novel and special in a few other ways:

1. The breach depended on a misconfiguration of a non-cloud component (the WAF software) to target an attack vector unique to cloud instances
2. An ex-employee of the cloud service provider targeted clients of the cloud service provider

The more important point is that Capital One had to deal with a previously unexplored attack. AWS recognizes Capital One as a leader in cloud usage with impressive efforts at security. The fact that an ex-engineer of the CSP exploited the technical weakness only stands to show how exclusive the knowledge required, and how hard to counter this attack was.

This incident highlights increasingly sophisticated attacks that attackers can use to compromise cloud environments. The CSA Top Threats Working Group playbook provides guidance on how to test for such misconfigurations in your cloud infrastructure, reducing the knowledge gap.

What’s the Cloud Penetration Testing Playbook?

The Cloud Penetration Testing Playbook represents a collective effort to provide guidance for the penetration testing of systems in public cloud environments. It provides a set of testing objectives, as well as legal and compliance concerns. The overall document aims to educate key decision-makers on the complexities of penetration testing in a multi-stakeholder and vulnerabilities within a multi-layered information technology stack.

While this resource is activity-specific (penetration testing), it outlines the various methods by which attackers can and do target cloud environments. To protect information systems, defenders should be aware of the methods including those used by the Capital One threat actor.. The playbook covers most of the aspects and methodology of similar attack:

Initial compromise employed by the Capital One threat actor involved a misconfigured proxy server exposing temporary credentials residing in its meta-data service.

Covered in Pg 13 (of the Cloud Penetration Testing Playbook)

c. Test for spoofing of user identity and other entities

v. Steal credentials from meta-data of proxy or http forwarding servers (credentials in AWS meta-data)

Data exfiltration via export of EC2 snapshots

Covered in Pg 14 (of the Cloud Penetration Testing Playbook)

f. Test for Information disclosure (privacy breach or data leak)

ix. Steal virtual machine images and snapshots from storage accounts; analyze them for sensitive data (likeAzure vm vhd snapshots

Data exfiltration via download of S3 bucket objects

Covered in Pg 14 (of the Cloud Penetration Testing Playbook)

f. Test for Information disclosure (privacy breach or data leak)

iv. Exfiltrate data from publicly accessible datastore services (S3, RDS, RDS snapshots, Redshift clusters, elastic search domains) or private stores with cli / dumps (s3 aws cli get, dynamodump), and/or configure them accordingly for exfiltration).

What Should You Do About This?

This knowledge is now available. The playbook is a resource that CSA and Top Threats Working Group will continue to improve on. Please take a look at it and if you find it useful, consider contributing to the research here.

Grab the ‘Cloud Penetration Testing Playbook,’ stay vigilant.