SpamChannel: 200万以上のドメインからスプーフィングメールを送り、事実上サタンになる [PDF]

 (media.defcon.org)
1 ポイント 投稿者 GN⁺ 2023-09-24 | 1件のコメント | WhatsAppで共有
  • DEFCON 31 2023の発表 SpamChannel は、Cloudflare Workerでメールを送ろうとする試みの中で、200万以上のドメインを対象としたスプーフィング問題を扱う
  • 中核となる実験は、メール送信を手作業ではなく プログラム方式 で処理し、Workerのデプロイフローに接続するところから始まる
  • Cloudflare Workersは、JavaScript、TypeScript、WASMベースの サーバーレスコンピューティング 環境として紹介される
  • 基本手順は npm create cloudflare@latest でプロジェクトを作成し、npx wrangler deploy でデプロイする流れ
  • Workersからメールを送る手がかりは、Cloudflareブログの MailChannels連携 の記事へとつながる

SpamChannel発表の出発点

  • SpamChannel は、DEFCON 31 2023でMarcello Salvati(@byt3bl33d3r)が発表したPDFで、200万以上のドメインからスプーフィングメールを送るというテーマを扱う
  • 発表の目標は、次の条件でメール送信を実装すること
    • メールを プログラム方式 で送る
    • Cloudflare Worker経由で送る
  • 法的責任に関して「犯罪をするな」という 免責事項 が含まれる

Cloudflare Workersとメール送信の手がかり

関連記事

1件のコメント

 
GN⁺ 2023-09-24
Hacker News のコメント

  • 発表動画: https://www.youtube.com/watch?v=NwnT15q_PS8
    またはこちらにもあります。私の Firefox では動画形式が再生できませんでしたが、VLC では再生できました: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF は、この発表で扱われたものよりはるかに多くの形で壊れています。メールセキュリティ強化／到達率支援エンジニアとして働いている立場から言うと、助言は常に SPF よりも DKIM + DMARC に集中すべき、というものです
    レガシーな理由から SPF は依然として必要ですが、到達率やなりすまし防止でこれに依存すべきではありません
    スライド 54 は DKIM + DMARC がこの攻撃には役立たないとしていますが、完全に正しいわけではありません
    委任したすべての送信者に DKIM を設定した場合にのみ、DMARC の p=reject ポリシーを安全に有効化でき、そのレベルに達すれば SPF で ? のニュートラル修飾子を使い、サードパーティ送信者について SPF を外し始めることができます
    たとえば v=spf1 include:relay.mailchannels.net ~all は v=spf1 ?include:relay.mailchannels.net ~all になります
    こうすると MailChannels から来たメールは、DMARC 対応の受信者には SPF がニュートラルとして扱われ、DKIM を使うようになり、古いレガシーメールサービスもニュートラルの結果は受け入れるべきです
    完璧な解決策ではありませんが、そもそもメールは 100% 信頼可能にも安全にもなり得ません

    • では、SPF の問題が何なのか気になります。TCP では送信元 IP の偽装はかなり難しいため、DKIM が SPF よりどんな利点を持つのか、ずっと疑問でした
      私は SPF を $myIP だけ許可するよう設定してきました。私のドメイン名でスパムを送るには、まず ISP かレジストラを侵害する必要があり、そのレベルなら私のドメインの TLS 証明書も取得できるでしょう
      複数の送信システムを許可リストに入れなければならない大組織でも、DKIM レコードを偽造できない状況で、正当な SPF 送信者の 1 つになりすます方法が何なのか分かりません
      投稿された発表のように、誰でも公開で使える IP 範囲を許可リストに入れるケースは、単に愚かな設定です
      メール交換全体を偽装するには、数バイトのメール 1 通にテラバイト級のトラフィックが必要で、STARTTLS が強制されれば不可能になります

  • 私たちは本番環境で Cloudflare Workers + MailChannels を使っています。ぞっとします
    すでに CF Workers から実サーバーへ移す作業を進めていましたが、今度は MailChannels からも離れる必要がありそうです
    セキュリティリスクは利便性に見合いません

    • 2023 年 6 月以降は、DNS に _mailchannels レコードを公開しない限り、Workers から MailChannels 経由でメールを送れません
    • 明確にしておくと、この問題は MailChannels が、送信ドメインの検証済み所有者であるかどうかについて送信者を認証していないことにあります。CF Workers が問題なのではありません

  • 「DKIM 署名はないが DKIM を実装しているドメインから来たすべてのメールにバナーを表示する」というのは、私の理解ではほとんど不可能です。あるドメインがDKIM を実装しているかを確実に知る方法がないからです
    理論上は "_domainkey.example.com" に DNS クエリを投げて、NXDOMAIN か NOERROR かを見ることはできます。後者は通常、サブドメインが存在することを意味し、したがって DNS に DKIM キーがいくつかあることを意味し得ます
    しかしセレクタ名は分からず、そのキーが有効状態なのか、後で有効化しようとしているものなのかも分かりません
    1 つのドメインに認証済み送信者が複数いて、一部は DKIM 署名を使うが一部は使わない、ということもあり得ます
    すべての DNS サーバーが標準をきちんと守っているわけではないため、NXDOMAIN/NOERROR の区別もおおむねしか機能しません

    • メールトラフィックの統計的に有意な割合を見ているプロバイダーなら、すべて、またはほぼすべての DKIM セレクタを見ることができます
      引用された文は、MailChannels から来たメールのうち DKIM 署名のないものを拒否しよう、という意味に見えます

  • 「MailChannels の主要顧客は、自分たちが送信するメールのドメインを所有していない Web ホスティング事業者だ」というのは、ここしばらく聞いた言い訳の中で最もひどいものです
    Web ホスティング事業者は通常、ホスティングしているドメインを「所有」してはいませんが、どのドメインをホスティングしているかは明らかに把握しています。ドメインを顧客アカウント／ディレクトリへルーティングすることこそ、Web ホスティングの中核です
    必要なのは、cPanel のような統合でドメイン一覧を報告し、各ドメインをランダム生成キーにひも付ける程度です
    これはすべて、エンドユーザーを煩わせることなく自動化できるし、そうすべきです

    • メーリングリストはどうするのか？メール転送は？

  • DMARC 仕様が進化して、検証に SPF ではなく DKIM だけを使うようにできる方法があるとよい。残念ながら、Google Calendar の招待のようなものは今でも DKIM に失敗する

    • 次の DMARC リリースには、DMARC 検証から SPF を除外するオプションが入る可能性が高い。Google チームが IETF DMARC メーリングリストでこれを推している:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      ドメイン所有者が DMARC を使いながらも、「自分のドメインのトラフィックを本当に認証する仕組みは DKIM だけにしてほしい」と指定できるので、とても良いアイデアだと思う
      業界には、SPF の解釈時点でしか分からない基準で認証を動的に調整する SPF マクロのように、SPF と DMARC の弱点を回避する方法が多い
      しかし、どんな回避策も「自分のドメインでは DKIM だけを使ってください」と言うことには及ばない

  • 最近、自分のドメインのメール設定を実際に経験した。特に「自分の機器からメールを送るにはビジネスアカウントでなければならない」と決めている ISP のせいで、気が狂いそうなほどもどかしかったので、こういう話は本当に腹が立つ
    私はネットワークの責任ある一員になろうと必死に努力し、自分のシステムを正しく整えるために、現在の最新水準まで掘り下げて徹底的に調べた
    それなのに、ああいう人たちが存在するだけでなく、事実上 オープンリレーのように軽く運用していて、インターネットのほぼ半分がそのツケを払っているなんて、あきれてしまう

  • 要するに、多くの SPF レコードに含まれている オープンリレーを発見したという話

    • SPF レコードで自らを開放していた 200 万ドメインのうち、DKIM/DMARC レコードを設定していたのは 1,000 未満で、しかも DKIM を構成して放置していた場合でも、Gmail では依然として認証済みとして通過する
    • それよりさらに悪い。プラットフォーム自体が ドメイン所有権の検証を試みさえしておらず、誰の名前でも送信できた
    • 厳密に言えばオープンリレーではない。MailChannels がスパムとフィッシングを積極的に制御していなければ、インターネット上に存在できなかったはずだ
      DEFCON の発表は巨大な穴の存在を証明したのではなく、インターネットメールの初期から存在していた事実を示したものだ
      S/MIME や DKIM のようなメッセージ署名を使わなければ、送信者ドメインを十分に認証することはできない
      DKIM があっても、DKIM 再送攻撃によって広範な悪用が可能になる

  • ARC ヘッダーがスパムスコアに与える影響が興味深い。個人メールサーバーを運用している立場としては、意味のない ARC ヘッダー一式を自分のメールに追加するだけで到達率を上げられるのだろうか？

    • そうではないと言いたい。もしそれが本当なら、複数のプロバイダーに分散している私の全受信箱がスパムであふれているはずだからだ
      組織的で知識のあるスパマーたちは、この手のものをすべて掘り下げているだろうし、突破に利用しているに違いない
    • メール業界では、ARC を大手受信者のスパムフィルターを迂回する 完全な方法とは見なしていない。DEFCON の発表者は、そのような判断を下す準備が不足していた

  • これは 2022 年 5 月にもすでに確認されていたようだ: https://news.ycombinator.com/item?id=30533032

    • CEO はこう言っていたようだ:
      「私たちは広範なスパムおよびフィッシング検出能力を持っており、悪用に対処できる」
      ああ、なるほど :D