How Attackers Can Misuse AWS CloudFront Access to Make It ‘Rain’ Cookies

AWS offers many different services, each with different configuration options. With so many options available, there are numerous possibilities for attackers who get some kind of access to AWS to perform harmful actions. Because of this, and motivated to write about AWS security by the article “Getting into AWS cloud security research as a n00bcake”, I would like to explore some unconventional ways (at least unconventional to me) an attacker might use to harm an AWS account after getting access to it. In this first article, I’ll focus on Amazon CloudFront, “a content delivery network (CDN) service built for high performance, security, and developer convenience.” Amazon CloudFront can pull content from various sources, like S3, EC2, API Gateway, and on-site locations.

Figure 1. Amazon CloudFront diagram from https://aws.amazon.com/

CloudFront is often the first point of contact for user traffic. If an attacker can manipulate CloudFront, they might steal critical data. Let’s examine two possible attack scenarios:

Scenario 1: Cookie Theft via CloudFront Function

Imagine a simple setup: CloudFront fetches an ‘index.html’ file from an S3 bucket when a user asks for it. We’ll imagine here the user previously authenticated itself and has valid session cookies.

Figure 2. Request and response flow for the first scenario

What if an attacker gets enough permissions to change the CloudFront configuration and create a function? They could:

1. Prepare a Function with a Cookie Check: The attacker sets up a function that checks for a specific cookie, in my example, "x-custom-header". If this cookie isn't found in the user's request, the function changes the content that CloudFront sends back.
2. Inject Malicious Content: This modified content will be a webpage that links to a malicious JavaScript controlled by the attacker. This script has a few tasks:
   - Steal users' cookies or other sensitive data.
   - Set the "x-custom-header" cookie in the user's browser.
   - Redirect the user back to the original page they requested.
3. Loop Prevention: The "x-custom-header" cookie is critical here. Without it, the user would continuously be redirected to the malicious page whenever they try to access the original page, creating an infinite loop. The function ensures that users experience the malicious content only once by setting and checking for this cookie. For loop prevention, it will be also important to disable the cache.
4. Data Collection: The attacker prepares another server (or the same from where the malicious Javascript is served) to gather the stolen data.

Figure 3. Request and response flow after compromise

Let’s see a real-life example. In this demonstration, when the user returns to index.html after going to the fake registry page ( just a random cookie generator ), the malicious function changes the response, and the user is directed to the harmful webpage, which just looks like a redirection. Their data is stolen there, the “x-custom-header” cookie is set, and they are redirected back to the original page. This entire process is so quick that users are unlikely to notice.

Figure 4. Vision from both the attacker and the victim in a demonstration

Scenario 2: Data Exfiltration via Lambda Function Modification

In this setup, CloudFront uses a Lambda@Edge function. This function redirects visitors without a session cookie to the login page. Just like in the example from AWS Example: Redirecting unauthenticated users to a sign-in page.

Figure 5. Request and response flow for the second scenario

If an attacker can change the CloudFront and the Lambda code, they could:

1. Modify the Lambda function to send user data to a server they control.
2. Steal users’ session information without them realizing it.

Figure 6. Request and response flow after compromise

Let’s see again another demonstration. Here, when the user goes to the website, it is redirected to the login page ( again, just a random cookie generator ). After that, it goes back to the index.html. As we can see, without the user noticing, all requests are sent by the lambda to the attacker server.

Figure 7. Vision from both the attacker and the victim in a demonstration

Conclusion

Attackers don’t necessarily need permissions to AWS services like IAM, EC2, RDS, or DynamoDB to execute a severe attack. Moreover, once either of the scenarios has been executed (whether it’s a Lambda modification or function alteration), detection becomes challenging. These “small” alterations are not the typical changes that configuration monitoring tools can normally catch. Also, it’s vital to remember the shared responsibility model when using AWS. While AWS ensures the security of the cloud, security in the cloud is the responsibility of the user. This means overlooked settings are the user’s responsibility, not AWS’s.
AWS has so many services, and each has various settings. Any of these can be a weak spot if not managed carefully; therefore, monitoring all changes in our AWS setup is essential.

Optional: Testing in a Controlled Environment

For those interested in testing the above, I’ve shared Terraform files in this GitHub repository to help you set up the basic infrastructure. Moreover, you’ll find code samples showcasing how an attacker might compromise the setup as described above.