Critical Information Disclosure Vulnerability via CNAME (AUTOMATED SCAN)

Hi there,

If you haven’t read my latest post, go take a look, it’s worth it DATA BREACH: 500.000 US passports found via an IDOR vulnerability.

How I Prevented a Data Breach by Reporting an IDOR in a System Exposing over 500,000 US Passports

Background

I have been doing research on DMARC and SPF policies recently, I found 100’s of misconfigured DMARC’ and SPF policies that allow users to impersonate email addresses and spoof them. This is considered a low-medium vulnerability, however, it can really affect customers/employees/students if we are talking about a school. I was able to submit 45 valid reports in a time frame of 5 hours with my automated tool, GITHUB. However, today I am not here to talk about DMARC policies, that’s a topic for another day. If this is something you want to read about, let me know in the comments.

Doing research on this, and reporting these types of vulnerabilities taught me 2 things:

1. They are widespread
2. Not all bug bounty programs accept it (due to the nature of them = common vulns.)

My opinion on how companies treat this vulnerability:

I believe DMARC vulnerabilities should be given a much higher impact rating in bug bounty programs. An attacker could exploit these vulnerabilities to launch highly sophisticated phishing campaigns, using spoofing techniques that can cause serious damage. Just think about it — people can easily fall for these scams and end up giving away sensitive information or clicking on harmful links. As long as the email lands in their inbox is game over. People — regular people — are not checking DKIM signatures or email metadata (you can easily find out that it’s a spoofed email by checking this). Companies should be more serious about these vulnerabilities.

Building this small Python script led me to think of other automation I could use to find more vulnerabilities doing passive recon: Subdomain Takeover vulnerabilities and even NS Takeover vulnerabilities. So I dug deep into both of those and created two automated tools.

Two differences between Subdomain Takeovers and NS Takeovers with DMARC and SPF vulnerabilities:

1. They are not “very common”
2. More companies accept these as valid bugs

1 thing in common:

1. Low hanging fruit

With that in mind, let’s jump to what we are all here for. How I found a Critical information disclosure vulnerability.

HAPPYHACKING

I wrote a cool automation tool that does the following:

1. Receives a list of URLS
2. Check if the URL has a CNAME record (if it has it could be prone to Subdomain Domain Takeover (SDT))
3. Filters them between potentially vulnerable and not vulnerable

Cloudflare CNAME's are not vulnerable to SDT
trafficmanager.net could be vulnerable to SDT
fastly.com could be vulnerable to SDT

4. Print all those potentially vulnerable domains and those that are not vulnerable whatsoever

5. Creates 2 files:

Full report/{company_name}.txt > in this report you have the full report
CNAME_report/{company_name}.txt > in this file you have a plain list of CNAME's found

Great, you have a good high-level overview of what my tool does.

How did I find the critical information disclosure? I scanned a list of subdomains of X company, my tool: Subdomain-Takeover-Checker gave me the CNAME list with potential vulnerable domains. I found many CNAME domains that belong to the company:

EXAMPLE — NOTHING VULNERABLE HERE FYI

Focus on this subdomain and its CNAME for a second:

Subdomain: bottle.tesla.com
CNAME of botte.tesla.com: prod-1-us-E23.vol.tesla.com

What I usually do with the list of all the CNAMES is I scan them again:

cat cname.txt | httpx -sc -ip -server -title -wc > cname_test.py

My mind is looking for 404 errors that could indicate that the resource is dead so I can proceed to test for SDT.

However, what if the CNAME the subdomain is pointing to has valuable information? Or is a deprecated endpoint, or it does not have protection?

Yeah, I hope you are catching the idea here.

I found this interesting 200 HTTP response for my random Subdomain: prod-1-us-E23.vol.tesla.com and fuzzed it.

My preferred fuzzing method:

ffuf -w facundo.txt -u https://tesla.com/FUZZ -mc all -c -v \
-H "User-Agent: Mozilla/5.0" -H "Accept: */*" \
-X GET -r -t 100 -p 0.1-1.0 -maxtime 3600 -o results.json -of json -od results \
-mc 200,301,302,307,401,403,500 -ac -recursion -recursion-depth 2 -rate 50 \

FYI: facundo.txt is my wordlist which you can find on my Github.

And I found a live endpoint: /docker-compose.yml

BANG!

While looking for SDT I ran into this beauty!

Successfully reported.

If you want to learn more about Subdomain Takeover Vulnerabilities I recommend reading these 2 articles:

https://medium.com/@DrakenKun/how-to-find-subdomain-takeover-using-httpx-dig-5c2351d380b4

What I learnt from reading 217* Subdomain Takeover bug reports.

Thank you for reading, send me a LinkedIn request, happy to connect with you on LinkedIn!