How to handle Amazon S3 bucket pen testing complexity

When the AWS platform launched in 2006, Simple Storage Service, or S3, was one of the first services offered. Since then, S3 has become one of AWS' most popular and most essential services due to its hypermodular functionality and seamless integration with other services.

But Amazon S3 also made a name for itself as synonymous with data leaks and breaches due to misconfiguration after misconfiguration. Often, the culprit was publicly exposed Amazon S3 buckets. Credit cards, Social Security numbers and classified government or military documents have all been exposed in Amazon S3 security incidents.

"If you search for 'AWS breach' online, I guarantee that almost every one of the top 10 results would be an Amazon S3 bucket-related issue," said Benjamin Caudill, founder and CEO of Rhino Security Labs and co-author of Hands-On AWS Penetration Testing with Kali Linux.

Here, Caudill -- who is intimately versed in the broad appeal of S3, as well as its inherent weaknesses -- draws on his more than 10 years of offensive security experience and infosec research background to discuss the importance of S3 bucket penetration testing (pen testing) and the limitations of cloud security.

Editor's note: This transcript has been edited for length and clarity.

Why is penetration testing in AWS environments so integral to maintaining security?

Click to learn more about
Hands-On AWS
Penetration Testing
with Kali Linux by
Benjamin Caudill and Karl
Gilbert.

Benjamin Caudill: Penetration testing in AWS is important in so many different ways. The adoption of infrastructure-as-a-service platforms, like AWS, is like adding an entire new layer of technology that we've not previously had. Many network vulnerabilities being patched are no longer applicable or no longer as relevant if you have application flaws or cloud flaws.

If you have credentials as an attacker -- or, in the case of S3 buckets, even if you don't have credentials -- you can find any of those vulnerabilities, regardless of the traditional security protections that may be in place. This adds a different dynamic to the entire security model. Organizations could be doing all the traditional things right and still not eliminate many critical vulnerabilities in their environment.

In Chapter 7 of Hands-On AWS Penetration Testing with Kali Linux, you identify AWS S3 buckets as one of the most popular attack vectors on AWS. How can these attacks be prevented?

Caudill: There are many different protections and changes you can implement, any one of which would prevent S3 buckets from being leaked. Having the right permissions and configurations to block public access to all S3 buckets is one of the most straightforward methods to point out. Incorporating typical best practices, such as ensuring least privilege and separating public and private data, [is] also critical.

Defense in depth is another approach. Consider a vulnerability that defeats any one given protection. Defense in depth ensures you're still safe by implementing redundant controls or multiple different layers of protection against a given vulnerability.

In the heyday of S3 bucket leakage, there were some things in the AWS console and in the UI that made it easy to overlook the risk and the potential impact of exactly what you were doing. After many of these instances where buckets were being leaked publicly, Amazon finally made some changes to the UI to make it less confusing and to make the risk more clear -- big red letters, indicating the risks users were facing.

How do pen testing methodologies in traditional security infrastructures differ from those used to pen test AWS environments?

Caudill: The traditional definition of 'vulnerability' does not apply as well to AWS pen testing. We think of vulnerabilities as things that you patch or that you fix with code. In some cases, the security risks are on you as a user to handle. But other risks exist, over which users have no control over.

We regularly debate internally whether we should refer to our cloud findings as 'vulnerabilities' or as 'attack vectors.' If the vulnerability is the AWS API itself, is it a vulnerability, or is it a feature? We shared our entire book with Amazon prior to any public release, and its response was that it's 'working as intended.' So, when the AWS API is designed this way, when it is working as intended, can you still call it a 'vulnerability?' It's an ongoing question.

There are some built-in infrastructural weaknesses to AWS. Other than moving to another cloud provider or simply being aware of the risk, there is not really anything you can do about it. This is one of the more significant aspects that separates traditional pen testing with AWS pen testing. Not all of your findings are necessarily things that can be remediated. That's a scary concept when your whole job is being responsible for the security of your data.

Gartner estimated that up to 95% of cloud breaches occur due to human errors, such as configuration mistakes -- a trend that is expected to continue. How do you interpret this aspect of the human element in cloud breaches?

Caudill: When Gartner talks about the user side of cloud breaches, it's specifically referring to the AWS shared responsibility model. This model dictates that the cloud providers are responsible for the structural security of the cloud and the users are responsible for the security in the cloud. But what that actually means is not what most people understand it to mean.

Too often, AWS has a seductive feel to it that gets people involved, while overlooking the security complexity that comes with it.

I've witnessed users' fundamental misunderstanding that, 'I'm not worried about cloud security; I'm going to AWS because I'm getting security built in for free.' And, in some ways, that's true. But I think, in the really important ways, it's not that simple.

On a technical basis, cloud security is much different than application security and network security. This makes it hard to start using AWS and simultaneously be aware of all of the security complexities and responsibilities. Fundamentally, this does not line up with how people begin using the platform. Too often, AWS has a seductive feel to it that gets people involved, while overlooking the security complexity that comes with it.

What is the best way for ethical hackers to improve their S3 bucket pen testing skills or AWS pen testing skills in general?

Caudill: For pen testers, I think there's an inclination to get into pen testing directly. I think this reflects a misunderstanding of the value of building things in order to develop the skills to break things. My advice for pen testers would be: Learn how to build an application. Get familiar with how different APIs work together and all the challenges and quirks and nuances that go along with that. You'll be able to go much further faster with that background.

The process of building things to better break things -- cloud application or otherwise -- is really undervalued. Understanding how the applications are built and their common configurations can go a long way toward helping pen testers reverse-engineer, as would an attacker.

Communication is also a critical skill for pen testers. It's a two-way street. You must be able to clearly convey what you think and also be open to listening and understanding. This is, by far, one of the most important skills and one of the hardest to find -- making it a highly in-demand skill for security professionals.

About the author

Benjamin Caudill

Benjamin Caudill is a security researcher and founder of pen testing firm Rhino Security Labs. Building on 10-plus years of offensive security experience, Caudill directed the company with research and development as its foundation into a key resource for high-needs clients. He has also been a major contributor to AWS security research. With co-researcher Spencer Gietzen, the two have developed Pacu (the AWS exploitation framework) and identified dozens of new attack vectors in cloud architecture.

As a regular contributor to the security industry, Caudill has been featured on CNN, Wired, The Washington Post and other major media outlets.