DNS Vulnerability: Dangling Domain Records
Vulnérabilité DNS : Enregistrements de Domaine Suspendus (Dangling Domains)
Description
Les domaines suspendus (dangling domains) surviennent lorsque les enregistrements DNS pointent vers des ressources qui ne sont plus actives ou sous le contrôle de l'organisation. Ces mauvaises configurations peuvent conduire au piratage de domaine, à des fuites de données et à des atteintes à la réputation. Les domaines suivants sont des préoccupations majeures dans la gestion des domaines suspendus :
1. Références aux Ressources Cloud
Les enregistrements DNS pointant vers des ressources cloud déprovisionnées posent des risques importants. Les mauvaises configurations courantes incluent : * Des enregistrements CNAME orphelins pointant vers des services cloud résiliés * Des enregistrements A ciblant des adresses IP libérées
# Enregistrement orphelin dangereux
app.example.com. IN CNAME terminated-app.cloudservice.com.
api.example.com. IN A 203.0.113.0 # Released IP
# Démantèlement approprié
# 1. Supprimer l'enregistrement DNS avant de libérer la ressource
# 2. Ou remplacer par un espace réservé contrôlé
app.example.com. IN CNAME service-offline.example.com.
2. Intégration de Services Tiers
Les enregistrements pointant vers des services tiers interrompus créent des vulnérabilités de sécurité : * Délégations de sous-domaines abandonnées * Points de terminaison de service expirés
# Configuration risquée
analytics.example.com. IN CNAME client-xyz.analytics-service.com. # Service discontinued
track.example.com. IN CNAME example.abandoned-tracker.com. # Company defunct
# Configuration sûre
# Toujours maintenir un inventaire interne des dépendances de service
analytics.example.com. IN CNAME active-client.current-service.com.
3. Gestion des Sous-domaines
Un nettoyage inapproprié des sous-domaines conduit à des scénarios potentiels de prise de contrôle (takeover) : * Environnements de développement/pré-production oubliés * Sous-domaines d'applications héritées * Environnements de projet inactifs
# Sous-domaines vulnérables
dev.example.com. IN CNAME old-project.github.io. # Repository deleted
stage.example.com. IN CNAME staging.heroku.com. # App removed
beta.example.com. IN A 198.51.100.1 # Server decommissioned
# Gestion appropriée des enregistrements
# Audit régulier et suppression des sous-domaines inactifs
dev.example.com. IN A 203.0.113.10 # Internal development server
staging.example.com. IN CNAME current-stage.example.com. # Active staging environment
4. Enregistrements de Serveur de Messagerie
Les enregistrements liés à la messagerie abandonnés peuvent conduire à l'usurpation d'e-mails (spoofing) et à l'hameçonnage (phishing) : * Enregistrements MX obsolètes * Références de serveur de messagerie obsolètes
# Configuration dangereuse de la messagerie
example.com. IN MX 10 legacy-mail.example.com. # Server decommissioned
mail.example.com. IN A 203.0.113.50 # Released IP
# Configuration sécurisée
example.com. IN MX 10 primary-mail.example.com.
example.com. IN MX 20 backup-mail.example.com.
5. Enregistrements de Validation de Certificat
Les enregistrements de validation de domaine abandonnés posent des risques de sécurité : * Enregistrements de défi ACME obsolètes * Enregistrements CNAME de validation de domaine oubliés
# Enregistrements de validation risqués
_acme-challenge.example.com. IN TXT "abandoned-validation-token"
validate.example.com. IN CNAME validate.oldcertprovider.com.
# Configuration propre
# Supprimer les enregistrements de validation après l'émission du certificat
# Utiliser la gestion automatisée des certificats
6. Enregistrements de Découverte de Services
Les entrées de découverte de services obsolètes peuvent exposer l'infrastructure interne : * Enregistrements SRV pour des services interrompus * Références de points de terminaison de service obsolètes
# Enregistrements de service exposés
_ldap._tcp.example.com. IN SRV 0 0 389 old-dc.example.com.
_xmpp._tcp.example.com. IN SRV 0 0 5222 chat.example.com.
# Nettoyage approprié
# Supprimer ou mettre à jour les enregistrements de service lors du démantèlement
_ldap._tcp.example.com. IN SRV 0 0 389 current-dc.example.com.
Ces mauvaises configurations de domaines suspendus peuvent entraîner des incidents de sécurité graves, notamment : * Attaques de prise de contrôle de domaine (domain takeover) * Exfiltration de données via des points de terminaison piratés * Campagnes d'hameçonnage utilisant des domaines légitimes * Atteintes à la réputation de la marque * Exposition de détails de l'infrastructure interne
Les organisations doivent mettre en œuvre un audit DNS régulier, maintenir des inventaires de services et suivre des procédures de démantèlement appropriées pour prévenir les vulnérabilités de domaines suspendus.
Recommandation
Pour atténuer les risques associés aux domaines suspendus, tenez compte des recommandations suivantes :
-
Commencer par un Inventaire des Domaines : Commencez par un audit complet de tous les domaines et sous-domaines :
# Exemple de format d'inventaire de domaines domain: example.com subdomains: - app.example.com -> AWS CloudFront - api.example.com -> Azure App Service - mail.example.com -> Google Workspace owner: DevOps Team -
Mettre en Œuvre des Niveaux de Surveillance Progressifs : Mettez à l'échelle la surveillance en fonction de la criticité du domaine : | Type de Domaine | Fréquence de Contrôle | Raison | |---------------------|-----------------------|----------------------------------| | Critique Production | Toutes les 5 min | Services essentiels à l'activité | | Orienté Client | Toutes les 15 min | Impact sur l'expérience client | | Outils Internes | Toutes les heures | Support des opérations internes | | Développement | Toutes les 6 heures | Environnements non critiques |
-
Audit Régulier des Domaines :
- Valider toutes les connexions aux ressources cloud
- Vérifier les dépendances des services tiers
- Vérifier l'exactitude des enregistrements DNS
-
Surveiller les certificats de sous-domaine
-
Meilleures Pratiques de Sécurité :
- Utiliser des identifiants cloud dédiés pour la gestion DNS
- Implémenter un RBAC strict pour les modifications DNS
- Activer la journalisation d'audit pour toutes les modifications DNS
-
Maintenir des flux d'approbation des modifications DNS
-
Procédures Opérationnelles :
- Documenter tous les détails de propriété du domaine
- Créer des listes de contrôle pour le démantèlement des services
- Maintenir la cartographie des ressources cloud
-
Tester les mesures de prévention de prise de contrôle de domaine
-
Stratégie de Démantèlement Planifiée :
- Commencer par l'identification des ressources
- Documenter toutes les dépendances
- Surveiller les connexions actives
- Supprimer les enregistrements DNS
- Archiver les détails de configuration
Ces recommandations permettent de garantir une gestion appropriée des domaines et de prévenir les vulnérabilités liées aux domaines suspendus tout en maintenant l'efficacité opérationnelle.
Liens
- Dangling Domains: Security Threats, Detection and Prevalence
- Dangling DNS and the dangers of subdomain hijacking
- Dangling DNS Record
Normes
- SOC2_CONTROLS:
- CC_6_1
- CC_6_6
- CC_6_7
- CC_6_8
- CC_7_1
- CC_7_2
- CC_8_1
- CCPA:
- CCPA_1798_150
- GDPR:
- ART_25
- ART_32
- HIPAA_CONTROLS:
- SECURITY212
- SECURITY213