DKIMリプレイ攻撃の原理と対策

DKIMリプレイ攻撃とは

正規ドメインの有効なDKIM署名が付いたメールを手に入れ、「そのまま」あるいは「署名を壊さない範囲で加工して」別の多数の受信者へ再送する攻撃

署名は壊れないため、DKIMもDMARCもpassしてしまう

正規以外のIPから送信するとSPFはfailするが、DMARCはDKIMのアライメントだけでpassするため、正規ドメインの評判をそのまま借りて迷惑メールフィルタを抜けることができる

なお、リプレイ攻撃による脅威はDKIMを規定したRFC6376においても既知の問題として議論されている（§8.6）

DKIMリプレイ攻撃の流れ

Content-Typeによる差し替え型攻撃

成立条件

• 署名付きメールを入手できる アカウント登録、問い合わせフォーム、通知メール、SaaS の招待機能などで、正規ドメインで署名されたメールを自分宛てに送らせられる

• 攻撃に使えるコンテンツを作れる 名前欄やメッセージ欄など、攻撃者が書いた文字列が署名済みの本文や件名に入る

さらに攻撃が成立しやすくなる条件

• 署名範囲の指定がゆるい・甘い l= を使っていると本文の末尾に追記できる 重要なヘッダを過剰署名（oversigning）していないと、Subjectなどを変更・追加でき、表示側が加工されたヘッダを読んでしまう

考えられる対策

送信側（ドメインを持つ側＝騙られる側）

• From、To、Subject、Date、Reply-To、Content-Typeなどをh=に重複して指定し（oversigning）、ヘッダの改ざん、追加を防ぐ

• l=を使わない

• 利用者が内容を書けるメールは、主ドメインと別のサブドメインやセレクタで署名する。あわせて、自由に書ける文字列を制限し、送信数にも上限を設ける

• 悪用を見つけたら、該当するセレクタの公開鍵を失効させる

• （補助策）x=で有効期限を短く、鍵を定期的にローテーションする ※ RFC6376ではx=タグをリプレイ対策として位置付けていない。また、期限切れの署名をPERMFAILにするのは「してよい」（MAY）であって義務にはなっていない。

受信側

• 同じ DKIM 署名（b= の値）が短時間に大量に届いたら、リプレイとして検知

• 署名後の改変を厳しく処理する 未署名の From や Subject の重複、l= を超えた本文の信頼を下げるなど

• 署名範囲が著しく狭い署名を厳しく処理する

参考

IETFで検討が進められているDKIM2ではリプライ攻撃への耐性についても議論されている

https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/