というフレーズ DMARC bypass は非常に異なるイベントを記述することができます。過剰に認可されたソースからの有効なパス、結果が失敗したにもかかわらず配信されたこと、および実装エラーは、同じ失敗ではありません。反証可能な主張から始めます。どの身元が主張されたのか、どの証拠が信頼されたのか、どの決定が予想されたルールと異なっていたのか?
観察された決定を再構築する
作成者ドメイン、エンベロープ ドメイン、署名ドメイン、信頼できる認証結果、および受信者の性質を保持します。ポリシーと観察時間を記録します。配信されるメッセージ自体はDMARCパスを証明しません。受信者の処理にはローカル ポリシーが含まれており、ドメイン所有者が要求した処理は普遍的な配信を保証するものではありません。 RFC 9989.
同様に、コピーされた Authentication-Results string は受信側システムの決定を証明するものではありません。信頼できる認証サービスと関連するホップを確立します。 RFC 8601。唯一の証拠が合格を示すスクリーンショットである場合は、基礎となる ID と信頼コンテキストが利用可能になるまで、クレームを未解決として保存します。
過剰承認とルール回避を分離する
BreakSPF はどの程度寛容であるかを研究しています SPF 共有インフラストラクチャへの認証とアクセスにより許可されるもの スプーフィング。その脅威モデルは、攻撃者に適格なソース パスを与えます。受信者は、発行された承認を書面どおりに評価できます。 BreakSPF、セクション III.A および図 3.
攻撃者が制御するソースが許可された範囲内にあり、調整されたエンベロープ ID を使用する場合、通常のパス ルールは成功する可能性があります。弱点は、 DMARCの新しい定義ではなく、付与された権限またはサービス境界にあります。逆に、無関係な ID のみが認証され、作成者のドメインが一致していない場合、要求されたパスには別の説明が必要になります。
3 つの仮説結果を分類する
alerts@brand.testが 1 つ表示され、それ以外の場合は適格なDMARC評価があると仮定します。これらは書かれた仮説であり、観察された出来事ではありません。
- 認証の場合: ソース192.0.2.99は、規定されたSPF ip4:192.0.2.0/24範囲内にあります。 メール送信元 bounce@brand.test SPFに合格します。いいえ DKIM署名。調整されたSPFパスにより、メッセージ レベルのDMARCパスが生成されます。そのソースが意図しない送信者によって本当に制御可能であるかどうか、またそのソースに権限を付与した所有者は誰かを尋ねてください。
- ケースの処理: bounce@other.testからの MAIL はSPFに合格し、 DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed アライメント 結果。
- 証拠のケース: コピーされたヘッダーには合格と表示されますが、信頼できる受信者の発信元、評価された ID、および適用されたポリシーは不明です。プロトコル違反も信頼できるパスも確立されていません。元の記録と受信者側の記録を要求します。
許可された正の送信者192.0.2.10と外部ソース198.51.100.10は、最初のケースを調査するときに提案された制御を提供できます。仮想のip4:192.0.2.10/32 -allレコードは前者のみを許可します。この接頭辞の算術演算からは実際の運用上の変更は生じません。ここでは、パーサー、署名チェック、エクスプロイトは実行されません。
RFC9989セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject。調整されたSPFメカニズムの通過は、特定のメッセージの通過条件には十分ですが、SPF のみを強制する場合には推奨されません。
発見を実用的なものにする
再現された状態とまだ欠けている証拠に名前を付けてください。有益な発見は、指定されたソースが指定された権限によって許可され、責任のある所有者を特定していることを示しています。すべてのDMARC保護が無効になるわけではありません。実際のサービスがテナント ID を制限しているかどうか、ソースが実際に制御可能であるかどうか、受信側が要求された結果を適用したかどうかを確認します。
提案された緩和策をテストするときは、無害な承認済みのポジティブコントロールを保存してください。範囲を狭めたりコネクタを変更すると、正規の送信者が機能しなくなる可能性があります。ルート固有の変更承認と変更後の検証を要求し、ラボでテストされていないプロバイダーの動作を明示的に未解決のままにします。これにより、教育モデルを実稼働環境の脆弱性に誇張することなく、正確な修正がサポートされます。