Prise de contrôle de sous-domaine : prévenir le DNS

Les ressources cloud sont temporaires ; les enregistrements DNS ont tendance à survivre. Lorsqu’un CNAME, A, NS ou MX pointe encore vers un service libéré, un attaquant peut parfois réclamer la cible et publier sous un hostname de confiance. C’est la prise de contrôle de sous-domaine.

Ce n’est pas d’abord un problème de scanner, mais de cycle de vie et de propriété. Le correctif durable relie DNS, provisioning et décommissionnement.

Comment la prise de contrôle devient possible

Une équipe crée un sous-domaine pour un bucket, une application PaaS, un CDN ou un portail support. La ressource est supprimée mais le DNS reste. Si le fournisseur autorise un autre client à reprendre le nom, l’attaquant contrôle le sous-domaine.

La cheat sheet OWASP de prévention rappelle qu’un enregistrement orphelin devient dangereux lorsque la ressource aval peut être réclamée.

L’impact peut inclure :

• phishing convaincant sur un domaine approuvé ;
• cookies exposés par une portée trop large ;
• contournement de CSP ou d’allowlists OAuth ;
• émission de certificat ;
• réception d’e-mails ou de réinitialisations ;
• atteinte à la marque et à la réputation.

Inventorier le DNS avec un propriétaire

Pour chaque enregistrement externe, stockez finalité, équipe, environnement, ressource cible, fournisseur, création et retrait prévu. Gérez DNS et ressource dans le même workflow infrastructure-as-code si possible.

L’inventaire doit répondre vite : qui confirme que cette cible existe encore ? Un enregistrement sans propriétaire actif est une dette prioritaire.

Comparez les noms observés avec l’énumération de sous-domaines et utilisez l’historique DNS pour dater les changements.

Détecter sans prendre de risque

Résolvez chaque chaîne et classez les échecs. Un CNAME en NXDOMAIN mérite une revue, mais ne prouve pas l’exploitabilité. Vérifiez les contrôles du fournisseur et les empreintes de réponse sans tenter de réclamer une ressource qui ne vous appartient pas.

Surveillez :

• cibles CNAME non résolues ;
• pages d’erreur indiquant une ressource absente ;
• IP libérées hors des plages approuvées ;
• délégations NS obsolètes ;
• MX vers un service retiré ;
• certificats inattendus dans la CT.

Exécutez ces contrôles continuellement et après chaque changement. Une validation événementielle est plus forte qu’un audit annuel.

Corriger l’ordre de décommissionnement

La séquence sûre est :

1. servir une redirection ou une maintenance si nécessaire ;
2. retirer ou modifier le DNS ;
3. attendre TTL et propagation ;
4. vérifier depuis des résolveurs externes ;
5. libérer la ressource cloud ou SaaS.

Supprimer la ressource en premier ouvre la fenêtre d’attaque. Encodez cet ordre dans les runbooks, revues et automatisations.

Réponse à incident

En cas de suspicion, retirez ou repointez immédiatement le DNS. Préservez réponse, certificats, résolutions et logs fournisseur. Ne réclamez la ressource que depuis un compte autorisé et selon les consignes du fournisseur.

Vérifiez cookies, CSP, redirections OAuth, e-mail et toute relation de confiance couvrant le hostname. Bloquez les URL via le scanner et la réputation, informez les utilisateurs si l’exposition est crédible et surveillez les certificats de remplacement.

Éviter les erreurs des scanners

Ne déclarez pas chaque NXDOMAIN exploitable. Ne créez jamais une ressource comme « preuve » sans autorisation écrite. Ne dépendez pas indéfiniment d’empreintes publiques : les services modifient leurs erreurs et contrôles.

Priorisez la possibilité de réclamation vérifiée, les relations sensibles et le trafic actif. Un hostname de laboratoire et un callback d’authentification approuvé par wildcard n’ont pas le même risque.

Métriques

Suivez enregistrements sans propriétaire, cibles orphelines, délai de correction, retraits réalisés dans le bon ordre et récidives par équipe. Le succès durable est la baisse des orphelins créés, pas la hausse des alertes.

Conclusion

La prise de contrôle est évitable lorsque DNS et ressource partagent un cycle de vie. Inventoriez, validez en continu et retirez le DNS avant le service. Associez énumération des sous-domaines et décommissionnement rigoureux afin que les noms de confiance ne survivent pas aux systèmes.