AWS Security Configuration Review and Best Practices

In fact, the Cloud Security Alliance’s Top Threats to Cloud Computing 2024 Report ranks the following concerns as the top three:

1. Misconfiguration and inadequate change control
2. Identity and Access Management (IAM)
3. Insecure Interfaces and APIs

To safeguard AWS environments, HackerOne offers a methodology-driven AWS security configuration review delivered via a Pentest as a Service (PTaaS) model. This approach connects organizations with a heavily vetted cohort of a global security researcher community for a comprehensive, end-to-end evaluation. Frequently performing dedicated reviews, using a community-driven PTaaS is crucial to finding vulnerabilities in your AWS resource configurations.

AWS Security Config Testing Methodologies

HackerOne’s AWS testing methodologies are grounded in the principles of the CIS Amazon Web Services Foundations Benchmark Level One and the Security Pillar of the AWS Well-Architected Framework. Additionally, our testing processes adhere to the standards required for CREST certification/accreditation, ensuring comprehensive and reliable assessments across various cloud environments, including AWS. Organizations using AWS can now better protect against risk and attacks with highly skilled AWS-Certified experts with specialized, proven expertise in vulnerabilities specific to the products and services in your AWS cloud environment.

Each security configuration review engagement by HackerOne focuses on the AWS services and configurations most critical to an organization’s cloud infrastructure security, including: 

Common AWS Vulnerabilities

The AWS operates with a Shared Responsibility Model that outlines the division of security responsibilities between AWS and its customers. AWS is responsible for the security of the underlying cloud infrastructure, while customers are responsible for the security of their data, applications, and configurations within the AWS environment. With the vast number of potential combinations of AWS services and their configurations, it can be easy to overlook vulnerabilities that can arise from misconfigurations.

IAM Misconfigurations

Service Control Policies (SCP) set broad, organization-wide permission boundaries. They define the maximum level of permissions that can be granted to an organization, organizational unit or account. SCPs enforce limits on what can be accessed or modified across your AWS environment.

By default, the FullAWSAccess policy is applied organization-wide, granting unrestricted access to all entities unless specific restrictions are configured.

On the other hand, the Identity and Access Management (IAM) service policies define the permissions of users, roles, and users within a certain user group. IAM allows for more precise and customized access control within the defined limits set by SCPs. A lack of Multi-Factor Authentication (MFA) and password/access key mismanagement can result in unauthorized access to your AWS account. 

Excessive permission configurations can also lead to unauthorized access to resources. For example, the incorrect usage of wildcard characters (*) within these policies could lead to privilege escalation attack vectors. To illustrate, the following policy file JSON block could be abused:

This policy configuration allows the iam:AttachUserPolicy action for all users within the AWS account. This means any user could attach any IAM policy to any other user in the account, including themselves. With this excessive permission configuration, a user could grant themselves a policy that includes administrative functionality.

During the HackerOne security review, IAM policies will be thoroughly assessed to verify adherence to the principle of least privilege, ensuring that users and services are provisioned with only the minimum permissions required for their specific roles and functions.

Security Group & Network ACL Misconfigurations

A security group acts as a virtual firewall to AWS resources such as Elastic Cloud Compute (EC2) instances by controlling inbound and outbound traffic based on rule sets. Whereas a network access control list (ACL) applies inbound and outbound rules to an entire Amazon Virtual Private Cloud (VPC) subnet or group of subnets.

The rules of both security measures enable you to allow or deny traffic based on criteria such as the traffic source and destination, protocol, and port or port range.

Misconfigurations of both security groups and ACLs could result in unfiltered ingress and egress network traffic leading to unauthorized access of critical systems such as internal applications or databases. Overly restrictive configurations can be just as problematic as they could block legitimate users or resources from accessing necessary resources.

As part of the HackerOne security assessment, Security Groups and Network Access Control Lists (NACLs) will be meticulously evaluated to identify potential misconfigurations. The review will focus on ensuring that these network controls implement the principle of least privilege, allowing only necessary traffic while blocking unauthorized access to maintain a robust security posture for resources.

S3 Misconfigurations

Amazon Simple Storage Service (S3) is an AWS data storage service that uses “buckets” as containers to store objects.

By default, new buckets, their access points and stored objects are private by default. Public access is granted to buckets through access control lists, access point policies, and bucket policies.

However, unintentionally making private buckets public or accidentally storing sensitive information in a bucket that is intended to be public can expose sensitive data to anyone who can obtain the bucket’s URL, leading to significant data breaches. Even private buckets may be compromised without proper authentication, encryption, and operation permission configurations in place.

The consequences of such data breaches can result in financial loss, legal ramifications, regulatory compliance violations, and damage to an organization’s reputation.

S3 buckets can also be used to carry out a subdomain takeover. A subdomain takeover vulnerability occurs when a subdomain points to a service that is no longer used. In this case, that service is S3.

When creating a bucket, the given name is combined with an Amazon S3 URL which is referred to as an endpoint.

Since buckets are accessible over the web, they can be used to store web assets such as images, videos or even entire static websites. For buckets configured to host websites, the bucket name is used as a subdomain to the region-specific endpoint. Depending on your region, the website endpoint will either use a dot or hyphen as a delimiter character in the region portion, such as:

• http://[bucket-name].[s3-website–region].amazonaws.com
• http://[bucket-name].[s3-website.region].amazonaws.com

Once claimed, the bucket name is reserved and cannot be reclaimed unless the original bucket is deleted. A DNS CNAME record can then be created to alias an arbitrary subdomain to the canonical S3 URL.

Once an organization deletes a bucket and the associated bucket name is released – if the CNAME record is not removed as well, anyone could reclaim the bucket name and host arbitrary content under the original organization’s subdomain. This can also lead to additional vulnerabilities in cases when external references still source content from the now-compromised subdomain.

HackerOne’s security assessment will examine S3 bucket configurations to identify potential misconfigurations, ensuring proper access controls, encryption settings, and versioning are in place to protect sensitive data stored in the cloud.

CloudTrail Misconfigurations

AWS CloudTrail tracks and logs every API call made to every resource in your AWS account, enhancing security by ensuring compliance with internal policies and regulatory standards. It provides continuous monitoring and generates log files of events allowing you to identify suspicious activities.

While CloudTrail is automatically enabled, the default configuration will only provide a log file of the past 90 days of events of only one event type. Manual configurations must be made in order to persist log files, log events in all regions, log additional event types, enable log file integrity and implement access control to the S3 buckets they are stored in.

AWS Configuration Review Best Practices

Careful Scoping

Having the right scope is crucial to a successful pentest—what is being tested can be just as important as how it is being tested. An AWS environment can be vast, with various resources and services distributed throughout. Combining an AWS Config review with both internal network and web application penetration testing for cloud-hosted systems offers a comprehensive security assessment. This integrated approach provides pentesters with a holistic view of the environment, leading to more effective and thorough results.

By strategically selecting targets within your cloud environment, you can ensure quality time can be dedicated towards your most critical cloud assets. This curation can mean the difference between an inconsequential configuration review and a valuable review that discovers high-impact vulnerabilities. HackerOne assesses your assets in order to provide guidance on which ones to include and delivers a quote tailored to your specific requirements.

Skills-Based Tester Matching

Traditional consultancies often rely on in-house pentesters with general skills. However, AWS configuration review requires specialized knowledge of the AWS environment and cloud security practices.

With HackerOne, customers gain access to a diverse pool of elite, vetted security researchers who bring a wide range of skills, certifications, and experience specific to AWS. The HackerOne platform tracks each researcher’s skill set based on their track record and matches the most suitable researchers for each engagement. The community-driven PTaaS approach delivers comprehensive coverage, versatility, and the highest-quality results tailored to the products and services of your AWS environments.

Case Study: An “Erratic” Breach

In 2019, Paige Thompson, a former AWS engineer exploited a misconfigured web application firewall (WAF) protecting an EC2 instance of Capital One. This led to the exfiltration of the sensitive private credit card application data of 106 million individuals.

Due to the WAF misconfiguration, external malicious requests were able to reach internal resources. Thompson, who went by the username “erratic” online, was able to query the AWS metadata service once she bypassed the firewall. The metadata service returned information about the IAM role that was attached to the EC2 instance, including a temporary access token for the role. The user role has excessive privileges that allowed Thompson to list and access the S3 buckets containing the sensitive data.

Even though the data was encrypted, the role also allowed for decryption, which led to Thompson downloading nearly 700 S3 buckets worth of credit card application data.

HackerOne PTaaS for AWS Cloud Review

By choosing HackerOne as your partner in pentesting, your organization can fully benefit from the community-driven PTaaS model. The HackerOne Platform streamlines the entire pentest process to deliver the greatest return on investment in risk reduction.

With the integration of HackerOne in the AWS Security Hub, AWS customers can sync all vulnerability findings into a single console for management and prioritization. The Security Hub findings can also be compared to those found by the HackerOne community, in order to match duplicates, understand status, and plan remediation.

Our diverse community of AWS-Certified security researchers brings the expertise needed to thoroughly audit your AWS cloud environment configurations for vulnerabilities. You will extend your attack surface coverage and be able to address vulnerabilities arising from cloud misconfigurations. Instead of switching pentest vendors to find diverse testing expertise, you find it all in this talented community of certified hackers. Contact the HackerOne team today to get started.