From ddf10733e6a0681c5cdaf2d7b07d2f364c702baf Mon Sep 17 00:00:00 2001 From: Nick Frichette Date: Thu, 24 Feb 2022 15:00:55 -0600 Subject: [PATCH] Fixed syntax/format for S3 subdomain takeover article. This resolves #128 --- ...aned_ cloudfront_or_dns_takeover_via_s3.md | 21 ++++++++----------- 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/content/aws/exploitation/orphaned_ cloudfront_or_dns_takeover_via_s3.md b/content/aws/exploitation/orphaned_ cloudfront_or_dns_takeover_via_s3.md index f0769bb3..e84ccee9 100644 --- a/content/aws/exploitation/orphaned_ cloudfront_or_dns_takeover_via_s3.md +++ b/content/aws/exploitation/orphaned_ cloudfront_or_dns_takeover_via_s3.md @@ -1,9 +1,14 @@ --- author: Houston Hopkins -title: Simple Route53/Cloudfront/s3 subdomain takeover -description: Techniques for taking over subdomains or hostnames that use Cloudfront and/or a DNS record to serve content from Amazone S3 +title: Simple Route53/Cloudfront/S3 Subdomain Takeover +description: Techniques for taking over subdomains or hostnames that use Cloudfront and/or a DNS record to serve content from Amazon S3 --- +Research Example: [Patrik Hudak](https://0xpatrik.com/subdomain-takeover-basics/) +Link to Tool: [dwatch](https://github.com/houey/dwatch) +Link to Tool: [ctfr](https://github.com/UnaPibaGeek/ctfr) +Link to Tool: [Amass](https://github.com/OWASP/Amass) + Utilizing various enumeration techniques for recon and enumeration, an attacker can discover orphaned Cloudfront distributions and/or DNS Records that are attempting to serve content from an S3 bucket that no longer exists. There are numerous tools to do this, but I have been using dwatch combined with CTFR Essentially you need a list of domains to check. Create a domain list using CTFR or amass or the like, and then utilize a tool like dwatch to test each host to look for a specific error page that contains the text "NoSuchBucket" @@ -28,7 +33,7 @@ This alone can be enough to stop the bucket from being taken over by anyone else

demo purposes only.

``` -Root Causes of this issue are typically due to a hygiene realted issues where an s3 bucket was deleted while content was still being served by Cloudfront or by a DNS Record CNAME (Route53 or otherwise). +Root Causes of this issue are typically due to a hygiene realted issues where an S3 bucket was deleted while content was still being served by Cloudfront or by a DNS Record CNAME (Route53 or otherwise). There are other nuanced conditions with Cloudfront, although rare, that can cause the similar takeover susceptibility. @@ -38,12 +43,4 @@ Always create in this order **S3 -> Cloudfront -> DNS** Always Sunset/Delete in this order **DNS -> Cloudfront-> S3** -Likewise, if you are testing, and something doesn't work, dont forget to clean up! - - - -* **Original Research**: [Patrik Hudak](https://0xpatrik.com/subdomain-takeover-basics/ -* **Link to Tool**: [GitHub](https://github.com/houey/dwatch) -* **Link to Tool**: [GitHub](https://github.com/UnaPibaGeek/ctfr) -* **Link to Tool**: [Github](https://github.com/OWASP/Amass) -* **H/T**: [fng, ebelties, 0xpatrik, vysecurity, Amazon Cloudfront Service team] +Likewise, if you are testing, and something doesn't work, dont forget to clean up! \ No newline at end of file