BreakSPF, publié lors du NDSS 2024, examine comment l'infrastructure partagée peut avoir une portée trop large SPF autorisation. Sa leçon opérationnelle centrale est de se demander qui peut émettre du trafic à partir d'une adresse autorisée, et pas seulement si un enregistrement est syntaxiquement valide. Un résultat de recherche historique est une raison pour évaluer une configuration actuelle, et non une preuve qu'un fournisseur nommé reste vulnérable.
Séparez le résultat de la recherche du système actuel
L'article original étudie l'infrastructure accessible aux attaquants, les dépendances permissives SPF et le comportement du récepteur, y compris les chemins inter-protocoles. Sa discussion rapporte des corrections au cours de la recherche et prend en compte d'autres contrôles de filtrage. Lisez ces sections sur la portée et la divulgation ainsi que les principaux résultats. Article original de BreakSPF, sections VII à IX.
Ne transformez pas le nombre de domaines du journal en une estimation actuelle de la prévalence d'Internet et ne répétez pas un exemple historique comme une accusation actuelle. Cet article ne reproduit pas les expériences, n’analyse pas l’infrastructure tierce et n’évalue pas un fournisseur en direct. Ses recommandations ci-dessous constituent un plan d’examen défensif fondé sur le protocole et la question de recherche.
Identifier la limite d'autorisation
SPF évalue si l'hôte qui se connecte est autorisé pour l'identité SMTP évaluée. Son résultat n'établit pas qui contrôlait l'application qui a initié le message. Une plage autorisée peut être appropriée pour un service d'envoi étroitement contrôlé et inappropriée lorsque des locataires non liés peuvent générer un trafic équivalent sans imposer la propriété du domaine. RFC 7208 , sections 2, 4 et 11.
Inventoriez les domaines d’enveloppe réels de l’organisation, les dépendances SPF et les services d’envoi. Pour chaque dépendance, enregistrez son propriétaire, pourquoi elle est nécessaire et comment le service limite l'utilisation par les clients des identités d'expéditeur. Une large plage est un signal de révision, pas assez d'informations à elle seule pour déclarer une exploitation possible. Les chemins de réseau et les contrôles de service actuels sont importants.
Conserver l’alignement DMARC dans l’analyse
DMARC a besoin d’un chemin d’authentification aligné de passage. Si une autorisation trop large produit une passe SPF pour une identité alignée sur le domaine visible From, en ajoutant DKIM aux messages légitimes ne supprime pas en soi ce chemin SPF . À l’inverse, une réussite SPF pour un domaine d’enveloppe non lié ne satisfait pas à elle seule DMARC alignement. RFC 9989.
Une politique DMARC plus stricte exige la gestion des échecs ; il ne convertit pas un chemin aligné déjà passant en un échec. Corrigez les autorisations inutiles et évaluez les contrôles de domaine côté service plutôt que de traiter une étiquette de stratégie comme un remède complet. Préservez les expéditeurs légitimes grâce à des modifications échelonnées et examinées.
Travailler à travers une matrice d’examen limitée
Le grand livre des prérequis écrit ci-dessous stipule quatre champs indépendants : autorisation de la source SPF , capacité d'origine involontaire, accessibilité du chemin et alignement de l'identité SPF avec From. Aucune ligne n’est une constatation observée par le fournisseur.
- A : vrai autorisé ; capacité d'origine involontaire vraie ; accessible vrai ; aligné vrai. Faire remonter la validation autorisée actuelle de ce possible chemin SPF aligné ; ne pas étiqueter l'exploitation de production établie.
- B : vrai autorisé ; capacité vraie ; accessible vrai ; aligné faux. Ce chemin SPF particulier n’établit pas de passe DMARC . DKIM et d'autres preuves de messages réels restent à inspecter avant de décider du résultat complet DMARC .
- C : vrai autorisé ; capacité vraie ; accessible faux ; aligné vrai. Conservez le problème de configuration, mais aucun chemin d'envoi accessible n'a été démontré par ces prémisses.
- D : vrai autorisé ; capacité inconnue ; accessible vrai ; aligné vrai. Obtenir des preuves de contrôle de service ; une capacité inconnue n’est ni sûre ni exploitable.
Il s’agit de déductions narratives, et non d’un test d’évaluateur, d’exploit ou de récepteur en cours. Aucune infrastructure DNS ou cloud n’a été consultée. La section 7.4 de la RFC9989 nécessite DKIM valide pour p=reject domaines ; cette tâche de déploiement n’efface pas un chemin SPF déjà aligné.
Appliquer des atténuations à la couche responsable
Examinez et supprimez les autorisations obsolètes uniquement après avoir confirmé les dépendances de l’expéditeur. Interrogez les propriétaires de services sur l’application de l’identité et l’isolement. Les opérateurs d’infrastructure doivent évaluer les sorties de courrier involontaires et les contrôles des limites du protocole via leur processus de sécurité autorisé. Les destinataires doivent conserver des preuves d'authentification fiables et tester le comportement des politiques à l'aide de domaines et de destinataires contrôlés.
Pour une évaluation réelle, conservez DNS datés, les preuves de propriété du service, la portée des tests approuvée et les résultats de réception observés. Un examen de sécurité indépendant doit distinguer un risque de configuration d'un chemin démontré et d'un résultat de message délivré. La validation actuelle du fournisseur et la reproduction expérimentale restent en suspens ; la lecture de l'article original retenue soutient le résumé de la recherche, tandis que la matrice écrite illustre uniquement ses prérequis stipulés.