In recent weeks, there have been a number of AWS (Amazon Web Services) breaches revealing several different types of vulnerabilities including leaky S3 buckets, misconfigurations and compromised AWS environments. Techniques for assessing these vulnerabilities and strategies for attack are specific to AWS Cloud and require specific knowledge and approach. For organizations seeking to improve their security and reduce the chance of a breach, this post covers some AWS penetration testing essentials.

As we address this topic, however, it is important to note upfront that because of the legal considerations of a cloud environment, pentesting AWS must focus on user-owned assets, identify and accesses management user permissions configuration, and use of the AWS API’s integrated into the AWS ecosystem. For example, targeting and compromising AWS IAM Keys, Testing S3 bucket configuration and permission flaws, establishing access through Lambda backdoor functions, and covering tracks by obfuscating Cloudtrail logs. This approach means that the client-side components are tested—not the actual AWS instance.

The rapid adoption of AWS services has contributed to the complexity of enterprise environments. As a result, organizations are finding that is increasingly important to challenge existing AWS security measures to immediately identify potential issues. Here are a few scenarios which help illustrate why penetration testing in AWS environments is so important to maintain security:

• Flawed understanding of the ‘shared responsibility model’ leading organizations to underestimate the risk that they are responsible for.
• Failures across fundamental AWS security checks including ‘open-wide security groups’ and excessive permissions.
• Failures in multi-factor authentication requirements, implementation or operation. The latter is particularly vexing when you consider how effective social engineering attacks, credential sharing and privilege escalation are.
• Extending compliance requirements, reporting, and visibility to the cloud. To maintain compliance efforts that impact the datacenter (specifically FedRAMP, HIPAA, PCI-DSS, etc.), organizations must take steps to highlight, resolve, and remediate any compliance gaps that effect their applications, infrastructure, and operating systems.
• Addressing zero-day vulnerabilities. Identification and remediation of the zero-day vulnerabilities is an essential part of maintaining good security posture in the cloud.

Validating the AWS security implementation in the cloud should be part of a comprehensive security plan. As part of supporting the shared responsibility model, AWS recognizes the need for organizations to penetration test the applications, instances and operating systems. AWS has an established program to permit penetration testing. Partnering with an organization that is familiar with the program and the rules that govern it is a critical success factor that organizations need to look for when considering an engagement.

The methodologies used to pentest traditional security infrastructure and the AWS Cloud differ in a multitude of ways. Most of these differences refer back to the ownership of the systems. Since Amazon owns the core infrastructure, the methodology invoked used in traditional ‘ethical hacking’ would violate the AWS acceptable use policies and potentially invoke incident response procedures by the AWS security team.

AWS offers over 90 different cloud hosting services that include offerings such as compute and storage, content delivery, security management, network infrastructure, and physical hosting facility for tenant organizations. The benefits of using AWS cloud services include the ability to quickly, and efficiently scale web service needs on a reliable, and flexible platform. At the same time, organizations are able to offload the maintenance and upfront fixed costs associated with network-connected hardware.

While the underlying AWS platform cannot be pentested, it is essential that you test your organization’s configuration of the AWS platform and the additional application code or assets living in your environment can be tested.

While there are a number of common  AWS-specific vulnerabilities we often see, some are more regular than others.  Below are the top 5 vulnerabilities we see when testing against this architecture:

1.   Testing S3 bucket configuration and permissions flaws
2.   Targeting and compromising AWS IAM keys
3.   Cloudfront/WAF Misconfiguration Bypasses
4.   Establishing private-cloud access through Lambda backdoor functions
5.   Cover tracks by obfuscating Cloudtrail logs

When partnering with a pentest provider, be sure to understand their approach and their end deliverables to ensure that they will find the risks that matter to your business and share that detail in a way that enables your organization to take action.

AWS permits security testing for User-Operated Services, which includes cloud offerings created and configured by the user. Here are a few examples:

• AWS EC2 instance excluding tactics related to disruption of business continuity such as launching Denial of Service (DOS) attacks
• The implementation and configuration of Vendor Operated Services,
• AWS services such as Cloudfront and the API Gateway configuration may be pentested but the hosting infrastructure is off limits.
  • Areas of the AWS Elastic Cloud Computing (EC2) service including:
  • The Application Programming Interface (API) (e.g. HTTP/HTTPS)
  • Various Web and mobile applications that hosted by your organization
  • The application server and associated stack (e.g. programming languages such Python, React)
• Virtual machines and operating systems

This is not an exhaustive list of what can be penetration tested, however, these areas are commonly included during an AWS pentest. With these 5 tests, organizations can identify and close significant gaps in their security approach.

Many of AWS services are based on the Software-as-a-Service (SaaS) model, which means the end user does not own the environment and cannot be pentested in the same way as a traditional on-premise environment or Infrastructure-as-a-Service (IaaS) model. However, the configuration and identity of those SaaS services can be tested from a blackbox engagement or even through a security audit.

Additional things that cannot be pentested within the AWS cloud due to legal and technological constraints:

• Services or applications that belong to AWS (IE: SaaS offerings as previously addressed);
• The physical hardware, underlying infrastructure, or facility that belong to AWS;
• EC2 environments that belong to other organizations (such as partners or vendors)
• Security appliances that are managed by other vendors without their permission;
• Amazon’s small or micro Relational Database Service (RDS).

There are many independent and COTS tools that are developed uniquely to the cloud environment and help with understanding misconfigurations and flaws in AWS. Rhino Security Labs recently released a tool around enumerating AWS S3 buckets called Buckethead.

The following basic tools can also help identify basic flaws:

• AWS Inspector (designed for the security of apps deployed on AWS)
• Nmap (network discovery and service enumeration)
• Rhino Security Lab’s BucketHead (Identifying misconfigured AWS S3 Buckets)

While conducting basic testing with available free tools is a good way to start addressing vulnerabilities and taking care of low-hanging fruit, they only scratch the surface when it comes to uncovering your true risk. Partnering with an experienced, independent third party to conduct your AWS assessment with move you to a better security position than you are likely to achieve on your own.

AWS environments are often highly complex and securing data in the cloud can be difficult. Penetration testing is an essential step to maintaining compliance and reducing your attack footprint. As part of your overall cloud strategy, be sure to make penetration testing a priority and work with a partner that knows the AWS ropes.  Reach us here for a quote on pentesting your AWS environment.