← ब्लॉग पर वापस

सबडोमेन टेकओवर: स्टेप-बाय-स्टेप डिटेक्शन और प्रूफ़ ऑफ़ कॉन्सेप्ट गाइड

सबडोमेन टेकओवर्स बग बाउंटी प्रोग्राम्स में सबसे विश्वसनीय रूप से रिप्रोड्यूसिबल हाई-सेवेरिटी वल्नरेबिलिटीज़ में से एक हैं। जब एक CNAME रिकॉर्ड किसी अनक्लेम्ड सर्विस की ओर पॉइंट करता है, तो कोई भी अटैकर उस सर्विस को रजिस्टर कर सकता है और आपके ट्रस्टेड डोमेन के तहत मैलिशियस कंटेंट सर्व कर सकता है — कुकीज़ चुराते हुए, फ़िशिंग करते हुए, और CORS रिस्ट्रिक्शंस को बायपास करते हुए।

---

सबडोमेन टेकओवर को समझना

यह हाई सेवेरिटी क्यों है

• कुकी थेफ़्ट — उन कुकीज़ को जो .company.com तक स्कोप्ड हैं, अटैकर के कंट्रोल्ड कंटेंट पर भेजा जाता है
• CORS बायपास — APIs जो भरोसा करते हैं *.company.com पर, वे अटैकर के सबडोमेन पर भी भरोसा करेंगे
• फ़िशिंग — अटैकर के कंटेंट के साथ लीजिटिमेट कंपनी डोमेन = हाई-ट्रस्ट फ़िशिंग
• CSP बायपास — अगर company.com अपने CSP में अपने सबडोमेन्स को व्हाइटलिस्ट करता है
• OAuth रीडायरेक्ट — अगर सबडोमेन एक रजिस्टर्ड redirect_uri है
• ईमेल डिलीवरी — अगर सबडोमेन ईमेल भेजने के लिए उपयोग होता है (SPF/DMARC)

---

फ़ेज़ 1: एसेट डिस्कवरी

सबडोमेन एन्युमरेशन

# Passive enumeration
subfinder -d target.com -silent -all -o passive_subs.txt

# Active brute force
amass enum -active -d target.com -o active_subs.txt

# Certificate transparency
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  jq -r '.[].name_value' | sort -u | tee ct_subs.txt

# Combine and deduplicate
cat passive_subs.txt active_subs.txt ct_subs.txt | \
  sort -u > all_subs.txt

DNS रेज़ॉल्यूशन चेक

# Check which subdomains resolve
cat all_subs.txt | dnsx -silent -resp | tee resolved_subs.txt

# Find CNAMEs
cat all_subs.txt | dnsx -silent -cname -resp | tee cnames.txt

# Example output:
# legacy.target.com -> company.azurewebsites.net
# api-old.target.com -> company.github.io
# status.target.com -> company.statuspage.io

---

फ़ेज़ 2: डैंगलिंग CNAMEs की पहचान करना

मैनुअल वेरिफ़िकेशन

# Check if the CNAME target is unclaimed
dig +short legacy.target.com
# Returns: company.azurewebsites.net

# Check if that hostname responds
curl -v -H "Host: company.azurewebsites.net" \
  https://company.azurewebsites.net 2>&1 | head -20

# Look for "takeover fingerprints":
# Azure: "404 Web Site not found"
# GitHub Pages: "There isn't a GitHub Pages site here"
# Heroku: "No such app"
# AWS S3: "NoSuchBucket"
# Fastly: "Fastly error: unknown domain"

न्यूक्लेई के साथ ऑटोमेटेड डिटेक्शन

# Nuclei has built-in subdomain takeover templates
nuclei -l all_subs.txt -t takeovers/ -silent

# Or use subjack
go install github.com/haccer/subjack@latest
subjack -w all_subs.txt -t 100 -timeout 30 \
  -ssl -c ~/go/src/github.com/haccer/subjack/fingerprints.json \
  -o takeover_results.txt

Can-I-Take-Over-XYZ रेफ़रेंस

can-i-take-over-xyz रिपॉज़िटरी 500+ सर्विसेज़ के लिए फ़िंगरप्रिंट्स मेंटेन करती है। चेक करने के लिए मुख्य सर्विसेज़:

सर्विस	फ़िंगरप्रिंट	टेकओवर?
GitHub Pages	"There isn't a GitHub Pages site here"	✅ हाँ
AWS S3	"NoSuchBucket"	✅ हाँ (सेम रीजन)
Azure Web Apps	"404 Web Site not found"	✅ हाँ
Heroku	"No such app"	✅ हाँ
Shopify	"Sorry, this shop is currently unavailable"	✅ हाँ
Fastly	"Fastly error: unknown domain"	✅ हाँ
Pantheon	"404 error unknown site"	✅ हाँ
Wordpress.com	"Do you want to register..."	✅ हाँ
Zendesk	"Help Center Closed"	✅ हाँ
Surge.sh	"project not found"	✅ हाँ

---

फ़ेज़ 3: प्रूफ़ ऑफ़ कॉन्सेप्ट (सेफ़)

GitHub Pages टेकओवर PoC

# Step 1: Confirm dangling CNAME
dig +short blog-old.target.com
# Returns: targetcompany.github.io

# Step 2: Check fingerprint
curl -s https://blog-old.target.com | grep -i "github"
# Returns: "There isn't a GitHub Pages site here"

# Step 3: Create PoC repository
# Create GitHub repo: targetcompany.github.io (if available) or
# Create GitHub Pages with custom domain matching CNAME target

# Step 4: Add CNAME file in repo
echo "blog-old.target.com" > CNAME

# Step 5: Add responsible PoC page
cat > index.html << 'EOF'
<!-- SECURITY RESEARCH - SUBDOMAIN TAKEOVER PoC -->
<!-- This page is hosted by a security researcher -->
<!-- to demonstrate a subdomain takeover vulnerability -->
<!-- No malicious actions are being performed -->
<h1>Subdomain Takeover - Security Research PoC</h1>
<p>This subdomain (blog-old.target.com) is vulnerable to takeover.</p>
<p>Researcher: [your handle]</p>
<p>Reported: [date]</p>
EOF

AWS S3 बकेट टेकओवर PoC

# Confirm dangling CNAME
dig +short assets-legacy.target.com
# Returns: target-legacy-assets.s3.amazonaws.com

# Check response
curl -v https://assets-legacy.target.com 2>&1 | grep -i "NoSuchBucket"
# "The specified bucket does not exist" -> Vulnerable!

# Extract region from response headers or try:
# us-east-1 is default if no region header

# Create PoC bucket (SAME NAME as CNAME target)
aws s3 mb s3://target-legacy-assets --region us-east-1

# Enable static hosting
aws s3 website s3://target-legacy-assets \
  --index-document index.html

# Upload responsible PoC
echo "<h1>Subdomain Takeover PoC - Security Research</h1>" | \
  aws s3 cp - s3://target-legacy-assets/index.html \
  --content-type text/html --acl public-read

इम्पैक्ट को डॉक्यूमेंट करना

# Demonstrate cookie access (ONLY with test account YOU control)
# Create a test account, set cookies, visit your PoC page
# Screenshot showing document.cookie contents
# This proves cookie theft scope

# Document with screenshots:
# 1. DNS lookup showing dangling CNAME
# 2. Fingerprint response (NoSuchBucket, etc.)
# 3. Your PoC page hosted at the subdomain
# 4. Browser showing the legitimate domain + your content
# 5. (Optional) Test cookie access from own test account

---

फ़ेज़ 4: परमानेंट फ़िक्सेज़

इमीडिएट रेमेडिएशन

1. डैंगलिंग CNAME हटाएं — अनक्लेम्ड सर्विस की ओर पॉइंट करने वाला DNS रिकॉर्ड डिलीट करें
2. या सर्विस को रीक्लेम करें — सर्विस प्रोवाइडर पर टारगेट होस्टनेम को फिर से रजिस्टर करें
3. समान डैंगलिंग रिकॉर्ड्स के लिए सभी अन्य सबडोमेन्स को ऑडिट करें

लॉन्ग-टर्म प्रिवेंशन

# Automate continuous subdomain monitoring
# Check all CNAMEs weekly for dangling status

#!/bin/bash
# monitor_dangling_cnames.sh
while IFS= read -r subdomain; do
  cname=$(dig +short CNAME "$subdomain" | head -1)
  if [ -n "$cname" ]; then
    # Resolve the CNAME target
    ip=$(dig +short "$cname" | tail -1)
    if [ -z "$ip" ]; then
      echo "DANGLING CNAME: $subdomain -> $cname"
      # Send alert
    fi
  fi
done < subdomains.txt

---

A रिकॉर्ड्स और NS टेकओवर्स

A रिकॉर्ड टेकओवर्स (इलास्टिक IPs)

# Check if A record points to a cloud IP that's unallocated
dig +short api-legacy.target.com
# Returns: 52.xxx.xxx.xxx

# Check if the IP belongs to AWS
curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "import json,sys; \
  [print(p['prefix'], p['region'], p['service']) \
  for p in json.load(sys.stdin)['prefixes'] \
  if '52.xxx.xxx' in p.get('ip_prefix','')]"

# If AWS IP, try to claim it by spinning up EC2 with that IP
# (Only do with explicit permission)

NS टेकओवर (सबसे क्रिटिकल)

---

FAQ

क्या एक सबडोमेन टेकओवर हमेशा एक क्रिटिकल वल्नरेबिलिटी होती है?

सेवेरिटी सबडोमेन के फ़ंक्शन और ट्रस्ट लेवल पर निर्भर करती है। बिना किसी कुकी स्कोप वाला एक मार्केटिंग सबडोमेन मीडियम हो सकता है। एक सबडोमेन जो OAuth रीडायरेक्ट URI के रूप में लिस्टेड है, CORS पॉलिसीज़ द्वारा भरोसेमंद है, या रूट डोमेन तक स्कोप्ड कुकीज़ प्राप्त करता है, क्रिटिकल है। हमेशा उन असली अटैक पाथ्स का आकलन करें जो सबडोमेन को कंट्रोल करने वाले किसी अटैकर के लिए उपलब्ध होंगे।

क्या मैं बिना परमिशन के रिसर्च के दौरान सबडोमेन टेकओवर कर सकता हूँ?

यह पूरी तरह से आपके bug bounty प्रोग्राम के नियमों पर निर्भर करता है। कई प्रोग्राम्स रिस्पॉन्सिबल डिस्क्लोज़र पेज के साथ PoC टेकओवर्स की अनुमति देते हैं। कुछ इसे स्पष्ट रूप से प्रतिबंधित करते हैं। अगर संदेह हो, तो टेकओवर किए बिना DNS एविडेंस (डैंगलिंग CNAME + फ़िंगरप्रिंट रिस्पॉन्स) प्रदान करें। इसका एक स्क्रीनशॉट शामिल करें कि आप क्या करने में सक्षम होते अगर आपने सर्विस रजिस्टर की होती।

प्रोग्राम्स को रेमेडिएट करने में कितना समय लगता है?

सबडोमेन टेकओवर्स को क्रिटिकल की तरह ट्रीट किया जाना चाहिए — रेमेडिएशन सिंपल है (DNS रिकॉर्ड डिलीट करें) और असली अटैकर एक्सप्लॉइटेशन का रिस्क हाई है। ज़्यादातर प्रोग्राम्स एक्टिव सबडोमेन टेकओवर्स के लिए सेम-डे या नेक्स्ट-डे रेमेडिएशन की उम्मीद रखते हैं।