SPF (やDMARC) を突破する攻撃手法、BreakSPF

SPF レコードで許可されている IPアドレスの実態がクラウドやプロキシ等の共用サービスのものであるケースは多く、それらの IPアドレスが第三者によって利用できる可能性があることを悪用し、SPF 認証を pass、結果的に DMARC 認証まで pass して詐称メールを送信できてしまうことを指摘した論文が公開されています。

この論文では、上記のような SPF の脆弱な展開に対する攻撃手法を BreakSPF と呼び、関連するプロトコルや基盤の実装に対する分析と共に、その内容が体系的にまとめられています。

本記事では、その論文を参照しながら、簡単に概要をまとめておきます。

BreakSPF の論文

2024年2月26日にセキュリティに関する国際会議、NDSSが開催されており、その中で発表された論文の1つのようです。

BreakSPF の概要

冒頭で挙げたように、SPF レコードで許可されている IPアドレスの実態がクラウドやプロキシ等の共用サービスのものであるケースは多く、それらの IPアドレスが第三者によって利用できる可能性があることを悪用し、SPF 認証を pass、結果的に DMARC 認証も pass して詐称メールを送信できてしまう場合があります。

論文中、この 共用された IPアドレスの可用性に由来する攻撃手法を BreakSPF と呼んでいます。

以下は、BreakSPF を用いて admin@meeting.tencent.com を詐称したメールが Gmail に送信された際、SPF pass (からの DMARC pass) となり、正規のメールであるかのように Inbox に配送される様子を示した画像です。

論文から分かること

自動翻訳を頼りながら、論文を一通り読んでみました。

調査の結果、23,916 のドメインが BreakSPF に対して脆弱であり、microsoft.com、qq.comといった有名なドメインも含まれることが分かったそうです (論文の公開前に各ドメインの管理者や事業者等に連絡され、ある程度は修正済み)。

このように、実在するドメイン等の調査結果も含め、関連するプロトコルと基盤の実装に対する分析と共に BreakSPF が成立するシナリオを体系的に考察することにより、攻撃者寄りの視点で電子メールに関連するエコシステムを把握することができます。

以下のような点が分かりました。

• BreakSPF を成立させるためのシナリオ
• BreakSPF を実現できてしまう電子メールに関連するエコシステムの実状
• 特にクラウドやプロキシ、CDN 等における共用 IP アドレス と SPF の相性の悪さ
• HTTP プロキシや CDN を踏み台に SMTP 通信を行うクロスプロトコル攻撃の存在

以下のようなことを感じました。

• ドメイン所有者が適切に SPF レコードを管理することの重要性
• 共有 IP アドレスを利用したサービスを提供する事業者に求められる IP アドレス、ポート管理の厳格さ
• 異なるレイヤにある要素に依存した認証技術には抜け道が生じやすいこと
• SPF や DMARC のスコープの限界を考えつつ、IPv6 普及により共有 IP アドレスを無くせる構成を実現して実質的に無害化できたら

BreakSPF の背景

この BreakSPF が成立する背景には、個別の新たな脆弱性の発見があるという訳ではなく、SPF のプロトコルや現在普及している実装の特性に由来する事情があります。

私としては、SPF のスコープ内、つまりプロトコル自体の脆弱性というよりは、こんな風に使われる (普及する) と危ないよね、という実装や展開上の脆弱性であるという認識です。

SPFは、IP アドレスとエンベロープFromの紐づけ

SPF では、各ドメインの管理者が、自ドメインをエンベロープ From アドレス (MAIL FROM、5321.From) に使用する電子メールを送信して良いホストを DNS レコード (SPF レコード) として宣言します。

SPFの検証を行うメール受信者は、その DNS レコードのホスト情報に基づいて最終的に IP アドレスによる判断を行うため、該当する IP アドレスを第三者が使える状況にある場合、第三者はその DNS ドメインをエンベロープ From アドレスとして使用する電子メールを送信 (詐称) できてしまいます。

SPF is an IP-based authentication protocol that binds senders’ IP addresses with the identity to be authenticated. However, this trust model is fragile because anyone who controls the IP addresses listed in an email domain’s SPF record can send spoofing emails on behalf of that dom

出典：BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet

SPFと、IP アドレスが共用されるサービス

SPF レコードで許可されている IPアドレスの実態がクラウドやプロキシ等の共用サービスのものである場合、上記のような詐称をできてしまう可能性があります。

論文では、以下のような5種類の共有インフラで利用される IP アドレスが挙げられています。

• クラウドサービス
• プロキシサービス
• サーバレス機能
• CI/CD プラットフォーム
• CDN

いずれも広く普及しているサービスであり、誰でも簡単に利用できるものです。

近年のクラウドサービスの普及も、IPアドレスが共用されている機能については BreakSPF の危険性を高めます。

例えば、自ドメインの SPF レコードに Google (Gmail) や Microsoft (Microsoft 365) 等のクラウドサービスで指定された送信元ホスト情報を includeするケースもあるでしょう。指定された送信元ホスト情報により解決された IPアドレスが、そのクラウドサービスにおいて共用されている場合には、同じクラウドサービスを利用する誰かが送信したメールが自ドメインを詐称した際、SPF 認証を pass する可能性があります。

メール送信サービスに関しても、メール送信時に使用する IP アドレスがドメイン間で共用されている場合には同様です。

SPF レコードの include の例として、1件の include により、最終的に複数のクラウドサービスのホストが指定されるケースが挙げられています。

SPFの実装と、BreakSPF

上記の背景から、SPF レコードで許可されている IPアドレスを第三者である攻撃者が取得できる場合に、BreakSPF が成立します。

論文では、その詳細がまとめられています。

なお、SPF 認証が pass になると、前述のように DMARC 認証を pass させることも可能になります。その場合、送信ドメイン認証とは別に動作するスパムフィルタ等により検知されなければ、正規のものと見分けがつかないメールが受信者のもとに届くことになるでしょう。

直接的には受信者 (メールの宛先) が被害を受けるように見えますが、巡り巡って送信者 (共用 IP アドレスの管理元)、送信元ドメインにも影響が出ることもあると思います。

BreakSPF の対策

論文では、”VIII. DISCUSSION” で “IP addresses are not suitable for identity authentication.” と指摘しつつ、”IX. MITIGATION” でいくつかの対策が挙げられています。

ドメイン所有者側でできる対処と、そうでないものがあります。

• IP アドレスを共用するクラウドサービス等において、外向けのメール送信用ポート (25/tcp、465/tcp) の通信を禁止
• 自ドメインの SPF が BreakSPF の影響を受けるかチェック (この論文の調査結果をもとに用意されたオンラインチェックツールあり ※)
• DMARC レポートの活用

※チェックツールは、入力したドメイン名に対し、SPF レコードの構文上の問題の有無や、今回の実験で収集した各サービスの IP アドレス (the IP addresses we obtained through the cloud service in our experiment) を含むかどうかのチェック、また DB 内の他ドメイン (other well-known domain names in our database) の SPF レコードとの共通部分の計算を行うようです。ただし、チェックに用いられる IP アドレスの情報や DB 内の他ドメインの情報は、おそらく最新のものではなく、実験時点のものかと思います。

また、基本的な対策として以下も挙げられます。

• SPF レコードで指定する送信元ホスト情報は必要最低限とし、常に最新の状態に

個人的には、すぐに根本解決することは難しいものの、事業者側で IP アドレスの可用性を保ちつつある程度セグメンテーションするような対策や、IPv6 アドレスの普及と共有 IP アドレスの段階的廃止等が進めばと思いました。現状は、電子メールと IP アドレスのレイヤが違うことによって生じる設定のギャップを埋めるために、何かしら設計や運用上の配慮が必要であると理解しています。

(補足) 環境によって、(DMARC 認証のために) DKIM 認証を利用し、SPF 認証を利用しない (少なくとも共用 IP アドレス分は pass させない) よう設定するという判断もあると思います。また共用サービスであってもオプションとして自ドメイン専用の固定 IP アドレスを利用できる場合には対策になります。

気になった点

全体的なことは論文に書かれているので、私が気になった点をいくつか挙げておきます。

SPF の誤設定が多い

BreakSPF とは直接関係ありませんが、SPF レコードの設定不備が指摘されています。

SPF レコードの 8.4%で以下の不備があったとのことです。

不備のうち、SPF 認証時に実行できる DNS 検索回数の上限である 10回を超えるものが多かったようです。

また、742 ドメインで SPFの設定が pass (どんな IP アドレスでも許可) になっていたとのこと。

Microsoft、Google の利用率が高い

下表では、SPF レコードで include されているドメインのランキングです。

これは、単に MS と Googleが多いなと思っただけです。

SPF レコードで指定されている IP アドレスが多い

50% 以上のドメインで、SPF レコードに含まれる IP アドレス数は 65,536 を超えていたそうです。

管理上、ある程度冗長な設定になるケースはあるでしょうが、必ずしもこんなに多くの IP アドレスは必要ないはずですね。

外向けのメール送信用ポートを利用できるサービスが多い

多くのサービスで、外向けのメール送信用ポート (25/tcp、465/tcp) の通信が許可されている、あるいは設定や申請により可能になるようです。

有名ドメインも BreakSPF の影響を受ける (たぶん修正済)

microsoft.com を含む多くの有名ドメインも、BreakSPF の影響を受けることが確認されています。(論文発表前にある程度修正済みのはずだと思いますが)

表にはありませんが、trendmicro.com 等も該当していたようです。

HTTP プロキシや CDN を踏み台に SMTP 通信を行うクロスプロトコル攻撃

HTTP 通信に埋め込まれた SMTP コマンドを、HTTP プロキシや CDN 等の HTTP 転送機能を通過して攻撃対象のサーバに送信することができてしまうケースがあることを利用した攻撃手法が示されています。

上図は、HTTP Body への埋め込み、HTTP Request への埋め込み、HTTP Header への埋め込みの3種類の例を説明したものです。

HTTP と SMTP の構文が似ているということにも由来するようです。

ドメイン情報とIPアドレスの収集

調査対象として、実在するドメインや IP アドレスが使用されています。

具体的には、Tranco (Webサイトランキング) のトップ100万ドメイン (と、Farsight DNSDB によるそのサブドメインも合わせて 700 万ドメイン超) の SPF レコードと、前述の5種類の共有インフラを利用することで収集した 87,430個のIPアドレスを用いて、BreakSPF 実験を実施するというものです。

広範な調査であり、収集した IP アドレスは地理的にも分散しています。

BreakSPF のフローの体系化

前述の調査対象ドメイン (やそのサブドメイン) の SPF レコードで許可されている IP アドレスが、収集した IP アドレスと一致 (Hit) し、その IP アドレスから外部にメール送信できれば、BreakSPF を実行できる可能性があります。

論文では、BreakSPF を実行する手順のパイプラインが示されています。

収集したデータの蓄積や検索に関し、効率化の工夫点も挙げられています。

SPF における IPv6 の利用率は 2.2%

この実験では、IPv6 アドレスは扱われていません。

IPv6 アドレスを SPF レコードに指定しているドメインは 2.2% だったようです。

In this experiment, we ignored IPv6 addresses for the time being, since the IP addresses declared in SPF records are still dominated by IPv4 addresses. According to our measurement, only 2.2% domains configure IPv6 addresses in their SPF records

出典：BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet – NDSS Symposium

(参考) M3AAWG の SPF 管理に関するベストプラクティスの記載

2017年に出ている M3AAWG のベストプラクティスでも同様の危険性が指摘されているので、引用しておきます。

4. Recommendations
4.1 Implementation
1.Only authorize IPs or ranges that are actually sent from.
It is important to explicitly whitelist only those IPs that send mail from the domain. Specifying additional IPs creates vectors for abuse.
This is especially important on large shared infrastructure, where it is possible to accidentally authorize all users of the shared infrastructure to send on behalf of the domain. Ensure that only hosts that actually send email for the domain are authorized.

出典：M3AAWG Best Practices for Managing SPF Records

(参考) 関連論文

この論文を書かれた方によるその他の論文も参照されていたので、記載しておきます。

まとめ

本記事では、BreakSPF の論文を参照しながら、簡単に概要をまとめてみました。

共用インフラを使用する際には注意が必要ですね。