Cartographier la dépendance avant de nommer le risque
Une référence DNS obsolète peut laisser un sous-domaine pointant vers un service que l'organisation ne contrôle plus. La possibilité pour une autre partie de revendiquer ce service dépend des règles d'attribution et de vérification de domaine du fournisseur. Même en cas de risque de rachat, l’autorité qui en résulte ne contrôle pas automatiquement tous les courriers électroniques de l’organisation mère. Une enquête utile cartographie l'enregistrement exact, la dépendance externe et les relations de confiance qui le consomment avant de décider ce que l'exposition pourrait permettre.
Conseils de prise de contrôle de sous-domaine Azure de Microsoft décrit DNS suspendu références, protections spécifiques au fournisseur et nettoyage. Il prend en charge l'investigation des dépendances obsolètes, sans supposer que toutes les dépendances non résolues CNAME est exploitable. Cet article propose uniquement un examen défensif et une planification du changement. Aucune ressource tierce n'a été enregistrée, aucun nom n'a été revendiqué, aucun enregistrement DNS n'a été modifié et aucun message de test n'a été envoyé.
Distinguer références, délégation et contrôle effectif
RFC 1035 définit CNAME et Enregistrement N.-É. formats. Un CNAME pointe un nom DNS particulier vers un autre nom ; il ne s'agit pas en soi d'une délégation d'une zone entière. Une délégation de zone enfant a une portée différente car les serveurs délégués peuvent répondre aux noms dans cette zone. Une référence d'hébergement Web obsolète, un sous-domaine marketing délégué et un Sélecteur DKIM pointer vers un fournisseur nécessite donc des cartographies de dépendances différentes. Les traiter tous comme « le domaine a été repris » supprime les informations nécessaires à la remédiation.
Répertoriez le nom exact du propriétaire, le type, la valeur, la zone et l'opérateur faisant autorité. Enregistrez le compte de service ou le fournisseur censé contrôler la cible et les preuves de cette relation. Une cible indisponible est une observation concernant la résolution ou l'état du service, et non une preuve qu'elle est disponible pour qu'un autre client puisse la réclamer. Les réservations des fournisseurs, les jetons de vérification et les restrictions du cycle de vie peuvent modifier cette conclusion. Vérifiez la documentation actuelle et les registres de propriété autorisés sans tenter de revendiquer des ressources pour démontrer le risque.
Séparer le contrôle Web de l'autorité de messagerie
Le contrôle d'un point de terminaison Web peut affecter le contenu diffusé sous ce nom et toute application qui lui fait confiance. Cela ne permet pas nécessairement de changer le domaine parent SPF, publication arbitraire DKIM clés ou faire fonctionner ses boîtes aux lettres. À l’inverse, le contrôle d’une zone déléguée ou d’une cible de sélecteur relative au courrier électronique peut avoir un impact différent sur la sécurité. L’enquête doit identifier quels noms DNS le mécanisme de courrier électronique consulte réellement et qui peut modifier leurs réponses.
RFC 6376 décrit la récupération de clé DKIM à l'aide du sélecteur et du domaine de signature. Une dépendance de sélecteur obsolète n'est donc pas équivalente à un site Web obsolète et sans rapport CNAME . Les implications potentielles en matière de signature dépendent du matériel clé, du chemin de recherche et de la capacité à produire une signature valide ; ils ne doivent pas être affirmés simplement à partir d’une page Web cassée. Aucune clé privée ni test de signature n'est nécessaire pour l'examen des dépendances documentaires proposé ici.
Évaluez soigneusement l’alignement et les hypothèses héritées
RFC 9989 définit alignement et découverte de politiques pour DMARC. Les domaines associés peuvent interagir différemment selon un alignement détendu ou strict, de sorte que le domaine visible From et le domaine authentifié doivent être enregistrés exactement. Ne supposez pas que chaque sous-domaine est isolé de chaque identité parent ou que le contrôle d'un sous-domaine authentifie automatiquement le courrier arbitraire du domaine parent. Le mécanisme et la politique réels déterminent la relation.
Il peut également y avoir une confiance dans les applications en dehors des protocoles d'authentification. Une liste blanche interne, une association de marque, une URL de rappel ou une attente de l'utilisateur peut traiter un sous-domaine comme étant fiable. Documentez chacune de ces relations comme une dépendance d’application ou d’entreprise plutôt que comme une règle standard DNS . Microsoft prévient que les secrets ou informations sensibles envoyés à des sous-domaines en suspens peuvent être exposés. Il s’agit d’une raison pour examiner les applications dépendantes, et non d’une affirmation selon laquelle une telle exposition s’est produite dans l’organisation examinée.
Appliquer les protections des fournisseurs dans leur portée documentée
Les conseils d'Azure décrivent la vérification du domaine personnalisé App Service à l'aide d'un asuid Enregistrement TXT et un identifiant de vérification de domaine. Cela explique également qu’empêcher un autre abonnement de valider le domaine personnalisé est différent d’empêcher la création d’une instance App Service avec un nom de service correspondant. Il s’agit de protections spécifiques au fournisseur. Ils n’établissent pas que chaque service Azure, chaque enregistrement DNS ou autre fournisseur cloud utilise les mêmes règles de cycle de vie.
Les mêmes instructions décrivent les enregistrements d’alias Azure DNS couplant certains cycles de vie de ressources pris en charge à des références DNS , avec des limites sur les cibles prises en charge. Ne généralisez pas ce comportement aux enregistrements CNAME ordinaires ou à tous les fournisseurs. Pour chaque dépendance, enregistrez la protection applicable, où ses preuves actuelles sont conservées et ce qui reste non vérifié. Une protection documentée peut réduire une exposition particulière sans prouver que toutes les relations de confiance avec les applications ou les e-mails sont sécurisées.
Une feuille de calcul de changement d'enregistrement exact
Préparez un plan de modification approuvé avec l'ensemble d'enregistrements complet actuel, la différence prévue, la dépendance cible, le propriétaire de l'entreprise, les consommateurs actifs et le matériel de restauration. Incluez le motif du retrait ou de la correction, les contraintes actuelles du fournisseur, le plan de vérification et les critères de décision de restauration. Une suppression n’est pas automatiquement sûre simplement parce qu’un service semble inutilisé ; Le courrier en file d'attente, les sélecteurs actifs, les flux de travail des clients ou un service de remplacement peuvent toujours dépendre du nom.
Conservez la carte des dépendances séparée de l’enregistrement d’autorisation. Un chercheur peut identifier une éventuelle référence périmée sans être autorisé à la supprimer. Après une modification approuvée, l'équipe opérationnelle conserverait des preuves de recherche faisant autorité et récursives avec les heures, les noms et les types d'enregistrement. Les réponses mises en cache et l'état du fournisseur peuvent durer plus longtemps qu'un changement. La suppression à elle seule ne constitue donc pas une preuve de révocation universelle immédiate. Aucune comparaison, recherche ou restauration de ce type n'a été exécutée pour ce manuscrit.
Diagnostic fictif : un service de campagne à la retraite
Une organisation fictive retire une plateforme de campagne mais laisse deux références DNS : un site Web CNAME et un sélecteur DKIM CNAME . Un outil d'inventaire signale que la cible du site Web n'est pas disponible. L'équipe suppose initialement que les deux enregistrements créent un risque de rachat identique. La révision proposée mappe séparément les cibles, la propriété du compte du fournisseur, les règles de vérification de domaine personnalisé et les dépendances de signature d'e-mails. Le résultat du site Web indisponible n’établit pas l’état du sélecteur ni la capacité d’une autre partie à revendiquer l’une ou l’autre des ressources.
Le propriétaire du courrier vérifierait si le sélecteur prend toujours en charge les workflows de signature actifs ou en file d'attente avant de proposer le retrait. Le propriétaire du site Web examinerait le point de terminaison de la campagne et toute approbation d'application qui y est attachée. Les deux modifications proposées nécessiteraient un matériel de restauration exact et une vérification approuvée. Il s’agit d’un exercice de cycle de vie fictif, et non d’un dossier en suspens découvert, d’une revendication de ressources, d’une prise de contrôle réussie ou d’un départ terminé. Aucun identifiant de service ou identifiant de service réel n'a été collecté.
Fermez la frontière de contrôle avec des preuves
Un rapport défendable nomme la dépendance obsolète, son état de contrôle vérifié, le mécanisme par lequel la confiance pourrait être affectée et l'action corrective approuvée. Il distingue l’exposition potentielle de l’exploitation confirmée. Il enregistre également les incertitudes résiduelles, telles que les preuves incomplètes de propriété du fournisseur ou le comportement du cache non observé. Évitez de décrire une protection spécifique à un fournisseur comme une garantie universelle ou un enregistrement supprimé comme une preuve qu'une utilisation abusive historique n'a jamais eu lieu.
Le catalogue nécessite une différence d'enregistrement exact approuvée, une carte de dépendances, du matériel de restauration et des preuves de recherche après modification. Ces artefacts originaux restent ouverts. La feuille de travail proposée ne les satisfait pas et toutes les autres portes de libération restent ouvertes. L'examen par un spécialiste humain, l'applicabilité de la source, les itinéraires de production, l'accessibilité et l'approbation du propriétaire doivent être effectués avant la publication. L’objectif est de rendre le nettoyage plus sûr et plus précis sans effectuer de démonstration de prise de contrôle ni surestimer l’autorité de messagerie héritée.