Cloud security, specifically AWS security, is once again in the news. This time it’s a major breach at banking giant Capital One. With 100 million customers affected, it ranks as one of the largest data breaches to date. Capital One now joins a long list of companies that have fallen victim to risks that are inherent to AWS and other cloud security platforms.

In order to teach others about the security risks in AWS, we at Rhino Security Labs created CloudGoat. CloudGoat is a “Vulnerable by Design” AWS deployment tool that offers focused, curated, high-quality learning experiences for people interested in learning about AWS security. Each scenario is a standalone learning environment with a clear goal (or set of goals), and CloudGoat is able to start up, reset, or shut down each scenario independently and securely. CloudGoat is also a good tool for walking non-technical folks through the how and why of AWS hosted data breaches. 

In this post, we discuss what we know about the Capital One breach, as well as the new CloudGoat scenario that was inspired by this breach.

By now, most readers are likely aware of the Capital One breach affecting 100 million customers that was disclosed last week. For those who aren’t, the following is a brief synopsis of what happened, according to the US Attorney’s Office for the Western District of Washington.

At some point between March 12, 2019 and July 17, 2019, an unauthorized user accessed data stored in AWS S3 buckets belonging to Capital One. The unauthorized user exfiltrated the data and stored it on GitHub under their real name, Paige Thompson, as well as boasting about the data theft in a Slack channel and on twitter using the pseudonym “erratic”.

Someone previously unknown to Capital One became aware of the data theft, either through the online boasting or GitHub upload. They sent an email to the responsible disclosure email address at Capital One.

Once aware of this, Capital One conducted an investigation, determined that there had, in fact, been a breach, and alerted the FBI. In the early hours of July 29th, “erratic” was arrested in their home in Seattle and is being held at a Federal Facility in SeaTac, Washington, charged with “computer fraud and abuse”.

Based on the latest information from charging documents and media outlets in this still-developing story we now believe that the data breach occurred because of a misconfigured AWS service allowing server-side request forgery. 

The charging documents break it down into 3 steps:

1. The attacker used some method to obtain AWS keys for an IAM role called “*****-WAF-Role” (the full role name is redacted in the charging documents)
2. The attacker used the stolen AWS keys to list S3 buckets that were accessible to that role.
3. The attacker used the AWS CLI S3 “sync” command to recursively copy data from the “*****-WAF-Role” accessible buckets to some other location. 

During our AWS penetration tests, we often see these kinds of misconfigurations.

The type of misconfiguration that allowed for this security breach is seen so often in AWS penetration tests by Rhino Security Labs researchers that it was included at the re-launch of CloudGoat 2 during re:Inforce as one of the scenarios. This scenario, titled “ec2_ssrf”, can be found on our GitHub here.

Today we are releasing a new CloudGoat scenario, “cloud_breach_s3”, which is inspired by the Capital One breach. This scenario was designed to re-create the conditions the breach occurred under as best as we could tell in the early hours of the breach.

For detailed instructions for preparing your AWS account and configuring CloudGoat, you can refer to our CloudGoat 2 announcement post.

The diagram below shows the basic flow of the cloud_breach_s3 scenario.

After creating the scenario, the attacker is presented with the IP address of an EC2 instance which is acting as a reverse proxy. Using a custom host header, the attacker exploits the proxy and makes a request to the meta-data service to enumerate an IAM role name and then another request to extract the EC2 instance’s Access Key ID and Secret Access Key. 

The attacker then configures an AWS CLI profile using the discovered keys and adds the aws_session_token to the profile. From there, the attacker can list a bucket then use the AWS CLI S3 command “sync” to recursively copy data from the bucket.

It is important to note that the initial step taken by “erratic” in the actual Capital One breach is still unclear. It’s possible the initial step is better represented by the first step of the “ec2_ssrf” CloudGoat scenario. 

During the hours after the initial breach disclosure, the Rhino team discussed possible vectors that “erratic” could have taken. Because we already had an EC2 SSRF based scenario, we decided to create a scenario that represented another possible route. All of the steps after the first in “cloud_breach_s3” are the exact steps taken by “erratic” according to the charging documents.

This likely won’t be the last time a major breach occurs due to misconfigured Amazon services. To understand the risks associated with using AWS and other cloud platforms, companies must understand the Shared Responsibility Model.

The “Shared Responsibility Model” is a framework used by AWS to explain the division of responsibility for security between AWS and users of the platform. This framework dictates that AWS is responsible for the “Security of the Cloud”, while the user is responsible for the “Security in the Cloud”.

AWS’s responsibilities, or the “Security of the Cloud”, include the infrastructure of the cloud platform, for example the hardware the runs in the data centers. The user’s responsibilities, or the “Security in the Cloud”, include the security of their applications that run on top of the cloud infrastructure. 

It is often assumed that cloud platforms are simply secure and full responsibility falls on the provider of the platform. This is a critical misunderstanding that Rhino Security Labs researchers see again and again during penetration tests. 

To be clear, we are not speculating that Capital One misunderstood the Shared Responsibility Model. In fact, the Capital One team is well-known for being leaders in Cloud Security. The point that we’re trying to make is that if a top-notch team like Capital One can fall victim to simple configuration mistakes, anyone can. Because these simple configuration mistakes are so easy to make, it’s important that users understand exactly what they are responsible for in AWS.

There’s no magic bullet when it comes to security in cloud environments. Cloud defense requires a creative and tactical mindset. The best way to understand AWS security is by working with the platform–there’s no substitute for hands-on experience. 

For those just starting out or not technically inclined, this can present a high barrier to entry. We hope that by providing a tool that allows the community to gain hands-on experience exploiting AWS that we can help continue to grow security awareness in the cloud community.

CloudGoat is a tool for the community and we welcome and encourage contributions. If you have an idea for a scenario based on a historical breach or interesting research, please let us know!