Rhino Security Labs

AWS Penetration Testing Services

Identify AWS Security Misconfigurations and Impacts

Penetration testing (or pentesting, for short) on the AWS cloud is unique, bringing its own set of security considerations. While some vulnerabilities are mitigated through Amazon’s security measures, the complexity of these services leaves many companies exposed. One of AWS’ strongest features is the immense flexibility that is provided to the users in setting up the environment. While the flexibility is great to have, it’s also a significant security concern. 

Rhino Security Labs’ AWS penetration testing services are aimed at specifically these needs, identifying the configuration and implementation flaws which often go unchecked.

Traditional security infrastructure and AWS clouds differ in various ways. From setup and configuration to identity and user permissions, the technology stacks could not be more distinct.

The most noticeable difference is the ownership of the systems, meaning Amazon requires formal permission for penetration testing, carried out on approved dates. The purpose of this policy is since the testing is affecting Amazon-owned infrastructure, the attacks of ‘ethical hacking’ would violate acceptable use policies (and may provoke incident response actions by the AWS team).
By making these testing windows clear, we ensure both a thorough and safe security assessment.

Also exceptional is the architecture of AWS and its set of powerful APIs. Deeply integrated into the AWS ecosystem, our security engineers test for a range of AWS-specific misconfigurations, including the following:

• EC2 instance and application exploitation
• Targeting and compromising AWS AMI keys
• Testing S3 bucket configuration and permission flaws
• Establishing private cloud access through Lambda backdoor functions
• Covering tracks by obfuscating CloudTrail logs

Blackbox Engagement

A common approach to pentesting AWS infrastructure thus far has been from an external perspective, testing for externally available resources with misconfigurations such as S3 buckets.

While this is a good step in securing your AWS infrastructure, it only looks at the environment at a surface level.  There are a number of ways we have compromised AWS keys in our engagements, and similar examples in the media…

  • Remote code execution on an EC2 instance with an IAM instance profile attached
  • Misconfigured Github that containing AWS keys
  • AWS keys compromised through sophisticated social engineering tactics

Post-Exploitation Assessment

In an AWS Post Exploitation Assessment the client provides a secured account on the AWS management console to the Rhino assessment team. By enabling this view into specific implementation details, our AWS experts can provide guidance on security details otherwise inaccessible to attackers.

This approach is designed as a more informed, audit-style engagement, and distinct from the blackbox style. If you’re looking for an in-depth security assessment of your AWS infrastructure, we recommend this approach.

Can I get Pentesting on any Amazon Service?
Generally, yes. There’s essentially two categories of cloud offerings:

  • User-Operated Services – These cloud offerings are primarily created and configured by the users themselves, with little or no interaction with the hosting provider (such as EC2). Generally speaking, these can be thoroughly tested and have few restrictions except for denial of service (DDoS) and related disruptions to business continuity. All security checks require the proper forms and process, as mentioned above.
  • Vendor Operated Services – Cloud offerings which are owned/operated by the by the vendor, and provided ‘as a service.’ Examples would be Gmail, Dropbox, Salesforce, and AWS services like Cloudfront. That’s not to say implementations of these don’t have vulnerabilities, but just that the testing focuses on implementation and configuration, rather than the infrastructure testing which is owned by the provider.

As we demonstrated with the S3 buckets, there are many misconfigurations, permissions, and implementation flaws which can make an individual instance vulnerable to compromise, but penetration testing on those platforms doesn’t involve attacking the cloud provider infrastructure itself.

Do I need to Alert Amazon of Pentesting?

Yes, Amazon has strict requirements about testing against your AWS infrastructure. Two of the primary requirements are outlined below. For more details, we have a page detailing how to go about filling out the AWS penetration testing form that can be found here.

  • Does the company performing the penetration testing have an NDA in place with AWS? Fortunately Rhino does have one an NDA in place from previous work with the AWS team.
  • Penetration Testing Request Form – AWS requires that anyone performing penetration testing on an AWS environment submit a request form. Important note; You must be logged into the root account associated with the environment to submit the form.

Make the process from penetration testing your AWS cloud environment as simple and efficient as possible.

We can walk you through the entire process, and it will help us to understand a better idea of your security assessment needs.