mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-29 14:13:20 -08:00
Migrate to using mdbook
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
# AWS - CloudFront Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proposes a couple of different scenarios where a **Lambda** could be added (or modified if it's already being used) into a **communication through CloudFront** with the purpose of **stealing** user information (like the session **cookie**) and **modifying** the **response** (injecting a malicious JS script).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Create** the malicious **function**.
|
||||
- **Associate** it with the CloudFront distribution.
|
||||
- Set the **event type to "Viewer Response"**.
|
||||
|
||||
Accessing the response you could steal the users cookie and inject a malicious JS.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
|
||||
- **Modify the code** of the lambda function to steal sensitive information
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user