logo

AWS-CF-1

S3 Origin Not Using Access Identity

  1. Home
Risk:
Moderate
CWE:
420

Cloudfront Distributions that do not use an S3 Origin Identity require the S3 bucket to use website hosting, splitting access controls across S3 and Cloudfront as well as implementing unencrypted communication for all traffic between S3 and Cloudfront.

Details

A commmon use case for AWS Cloudfront is to distribute static content stored in AWS S3 buckets. Utilizing an Origin Identity is the best way to manage this connection. AWS CloudFront, when reading from S3 buckets, has two options for reading the data stored in the bucket. The first, and most common, method is to enable website hosting on the S3 bucket and use CloudFront to read from with the internet-accessible S3 hosting endpoint. This endpoint acts as a web server provided by the AWS S3 service to serve the objects in the bucket over HTTP. However, this approach has several issues:

Plain Text Communication

The S3 service’s provided endpoint is unencrypted, meaning communication between AWS CloudFront and S3 occurs in plain text.

Weak Access Controls

Access control for these S3 website endpoints is weak, leaving your bucket potentially exposed to the internet if someone can guess its name. Since bucket names are globally unique across the whole of AWS, automated tools can easily search for unprotected buckets, which has resulted in the compromise of entire S3 buckets and most of an organisation’s information.

Our white paper Prominent Cloud Security Vulnerabilities details one such example where an unprotected S3 bucket leaked Terabytes of company and customer information.

Communication Transparency

Because communication between CloudFront and S3 is in plain text, any packet along the route could be intercepted and read, revealing the data being transmitted to any connected service monitoring the traffic. Using tools such as wireshark within network vicinity of the communicated packets will allow the full communicated data to be read.

Origin Identities

The second method to connect CloudFront to an S3 bucket is more secure. This method uses a unique CloudFront identity for the distribution, allowing it to authenticate as an authorized entity to access the bucket’s objects. Cloudfront Origin Identities do not require enabling website hosting on the S3 bucket, removes the requirement to directly expose the bucket to the internet.

The Origin Identity acts a separate identity within AWS that the Cloudfront service assumes, similar to how IAM Users and Roles are separately identified entities. By creating an Origin Identity and updating your S3 bucket policy to allow for access from this Origin Identity this provides explicit control over the access you give your Cloudfront Distribution to read content from your AWS bucket.

By restricting the bucket to only allowing this Origin Identity to access your bucket’s content, you would have ensured that access to the bucket is only available through CloudFront, allowing you to use features like AWS Web Application Firewall (WAF) and Cloudfront’s geoblocking to further restrict access to the objects based on specific parameters. By funneling all access through CloudFront, you concentrate all access control to one route and avoid the added complexity and vulnerabilities of managing multiple access paths including those with weaker access controls.

Remediation

SkySiege’s AWS Vulnerability Scan automatically detects this vulnerability across all AWS Regions with the report delivered the same day.

Creating a S3 Origin Access Identity is simple and - when done via the AWS Console - will automatically update the target bucket’s policy to allow for the identity to access the bucket. This works the majority of the time but has been known to cause issues with pre-existing bucket policies.

Once the identity is created it’s simple to configure the Cloudfront Distribution to utilise the Cloudfront Origin Identity for access:

  1. Navigate to the settings for the desired Distribution
  2. Select the Origins tab
  3. Edit the origin for your currently configured S3 bucket or create a new origin if one does not exist already
  4. Alter the setting under the Origin access heading to utilise either the Legacy access identities or the Origin access control settings, preferably the latter
  5. Select the created identity in the below dropdown and save the changes

Detection of insecure distributions is often the more complex part, especially when working across multiple AWS accounts. Our tools can automatically detect and report on misconfigured Distributions without secure S3 access.

SkySiege Vulnerability Assessment