36c3
フィッシングメールは、「差出人」フィールドを確認するだけで見破れることもあります。しかし、いつもそうだとはかぎりません。実際、本物と見分けのつかない偽メールは作れます。そんなものを作れる攻撃者に標的とされたなら、たまったものではありません。上司や重要な顧客から届いたように見えるメールにリンクやファイルが添付されていたら、ほとんどの人は深く考えずにクリックするのではないでしょうか。クリックした人を責めるのは酷な話です。メールが偽物だと見分ける方法がないとすれば、特に。
しかし、そもそもなぜ、完璧な偽メールを作り上げることが可能なのでしょうか？第36回Chaos Communication Congressでアンドリュー・コンスタンティノフ（Andrew Konstantinov）氏が侵入テスト担当者向けに行ったメール認証に関する講演は、まさにこの問いに答え、なりすましメールからの保護の有効性について見識を与えてくれるものでした。
問題1：メールはよどみなく流れなければならない
電子メールは現代社会に不可欠なコミュニケーション手段であり、どの組織も日々の業務をメールに大きく依存しています。すべてが円滑に動いているうちは、メールの存在を特に意識しませんが、もしも突然メールが行方不明になり始めたら、その存在の大きさに皆が気づくことでしょう。そんなわけで、メールサーバーの管理者は一般に「確実性」を最優先としています。メールというものは、何があっても、確実に送信されて確実に宛先に届くべきものなのです。
ということは、あらゆる組織のメールサーバーは、世界各地のメールサーバーと可能な限り互換性がなければなりません。そしてここに問題があります。電子メールの標準は、恐ろしく時代遅れなのです。
問題2：メールプロトコルに認証手段がない
SMTPは、クライアント（メーラー）とサーバーの間、およびサーバーとサーバーの間でメールのやりとりに使われる主要プロトコルです。SMTPが初めて登場したのは1982年、最後にアップデートされたのは2008年でした。10年以上前のことです。古い標準にはセキュリティ上の問題があるものですが、SMTPも例外ではありません。
まずは、一般的なメールの構成を見てみましょう。
- SMTPエンベロープ：サーバー間の通信に使用される部分で、メーラーには表示されません。ここでは、送信者のアドレスと受信者のアドレスが指定されます。
- ヘッダー：メーラーに表示される部分です。「差出人」「宛先」「送信日時」「件名」など、どのメールにもあるおなじみの情報が含まれます。
- メールの本文：メールのテキストなどのコンテンツです。
メールメッセージの中身。画像出典
一番の問題は、SMTPに認証手段がないことです。送信者アドレスのフィールドはSMTPエンベロープとヘッダーの両方にあり、このフィールドに関しての全責任を送信側のサーバーが負っています。しかも、SMTPエンベロープ内の送信者アドレスは、ヘッダーの送信者アドレスと一致している必要がありません（利用者が目にするのはヘッダー内の送信者アドレスのみ）。
また、SMTPではメール1通につきヘッダーは1つと規定されていますが、厳密に適用されているわけではありません。メッセージに複数のヘッダーが含まれている場合、メーラーは単純にそのうち1つを選んで表示します。
問題の発生する余地が大いにあることは、プロのハッカーではなくても分かります。
SMTPプロトコルには、送信者として表示されている人から本当に送られてきたメールであることを確認する手段がない
問題3：届く偽物、出る偽物 — どちらも監視しなければならない
さらにややこしいのは、メールのやり取りに必ず送信者と受信者の2者が関わることです。このため、「認証手段がない」という問題から、さらに2つの問題が派生します。
1つは「受信したメールが表示されているとおりのアドレスから送られてきたものであることを確かめたい」問題。もう1つは「自分のアドレスから送信されたように見えるメールを、他人から送られないようにしたい」問題。残念ながら、SMTPはどちらの役にも立ちません。
SMTPプロトコルの乱用はあまりにも多く、こういった問題点を修正する新しいテクノロジーの開発が始まったのも当然の成り行きです。
修正の試み1：Sender Policy Framework
Sender Policy Framework（SPF）の背景にある概念は、かなりシンプルです。「受信側のサーバーは、メールを送信したサーバーのアドレスと、そのドメインに関連付けられているメールサーバーのアドレスが一致するかどうか、確認できなければならない」という考えです。
残念ながら、言うほど簡単ではありません。SMTPにはこのようなチェックを行う手段がないため、それを補う認証手段として登場したのがSPFですが、これが「Proposed Standard」（標準の提案。標準化過程の最初の段階）に至るまで10年かかりました。現在、SPFを使用しているのは上位100万サーバーの55%にすぎず、大半のサーバーはかなり緩いポリシーを採用しています。
SPFも、さまざまな問題に直面しています。アーキテクチャが乱雑なため構成ミスが起きやすい、同じアドレスにホストされている別のサーバーを使った迂回方法が存在するなど、枚挙にいとまがありません。致命的なのは、SMTPエンベロープ内にあるアドレスだけをチェックして、ヘッダーの「差出人」フィールドにあるアドレス、つまり実際に受信者が目にするアドレスを完全に無視する点です。
結果：
- SPFは、メールが本物のサーバーから来ているかどうかのチェックに役立つ。
- 受信者が目にするアドレスの偽造は可能。
修正の試み2：DomainKeys Identified Mail
DomainKeys Identified Mail（DKIM）は、違う角度からこの問題に取り組んでいます。DKIMは、メールのヘッダーと本文の一部を、秘密鍵を使って暗号的に署名します。署名の検証は、DNSサーバー内で公開される公開鍵を使って行います。
DKIMでは、メール全体が暗号化されるのではなく、正しくは暗号的に署名された補足情報がメールに追加されます。これが問題です。暗号化された部分の変更は困難ですが、署名を丸ごと削除して偽のメールを作り上げるのは簡単にできます。そして、こうした変更は検知できません。
DKIMは暗号鍵の発行と管理を行うので、実装しにくいという難点があります。また、DKIMの構成を誤ると、メール内のDKIM署名を維持したまま、ヘッダーと本文を完全に変えることが可能になってしまいます（英語）。
結果：
- DKIMではメールのデジタル署名が可能。そのため受信側サーバーは、本当に署名者から送信されたメールであることに確証を持てる。
- 暗号鍵の管理が必要なため、実装が困難。
- デジタル署名を削除し、他人の名前を使った偽メールを作成することが可能。
- 構成を誤ると、本物のDKIM署名を持つ偽メッセージを作成可能となってしまう。
修正の試み3：Domain-based Message Authentication, Reporting and Conformance
Domain-based Message Authentication, Reporting and Conformance（DMARC）は、長い名前とは裏腹に、SPFやDKIMよりも理解しやすいプロトコルです。端的に言うと、DMARCはSPFとDKIMがカバーしていないところを補う拡張機能です。
DMARCは、メール送信者が自分のドメインを使っているかどうかを確認します。これにより、DKIMメカニズムの欠陥が解決されます。また、SMTPエンベロープ内の送信者アドレスだけでなく、ヘッダーの「差出人」フィールド（実際にユーザーの目に触れるもの）に指定されたアドレスもチェックします。これでSPFの欠陥も修正できます。
しかし、DMARCプロトコルは比較的新しく、まだ正式な標準ではありません。該当するRFC 7489（英語）は、「Standard（標準）」でも「Proposed Standard」（標準の提案）」でもなく、単なる「Informational（情報）」に分類されています。本来ならもっと使われてよいはずですが、そうはなっていません。2万ドメインを対象にしたこの調査（英語）によると、2019年時点でDMARCを採用しているドメインは20%ほどで、厳格なポリシーを持っているのは8.4%にすぎません。
残念ながら、DMARCの採用は広がっておらず、多くの場合、他のポリシーとは併用されていない。画像出典
結果：
- SPFとDKIMのもっとも重大な問題が解決された。
- まだあまり採用が広がっていないため、本来の効果を発揮していない。
なりすましメールから身を守るには
まとめましょう。メールの偽装は今でも可能です。SMTPプロトコルはセキュリティを考慮して設計されたものではないので、攻撃者が偽造メールにどんな送信者アドレスでも指定可能なのです。ここ数十年で、ある程度の保護メカニズム（具体的にはSPF、DKIM、DMARC）が登場しました。これらのメカニズムが効力を発揮するには、できるだけ多くのメールサーバーで（正しく実装した上で）使われるようになる必要があります。理想的には、インターネット上の全メールサーバーに実装されるべきです。
最後に、メールを保護するための推奨事項をいくつかご紹介します。
- 少なくとも、SPFを導入する。適切に構成してください。また、抜け目のない攻撃者ならばSPFを回避可能であることを念頭に置いておきましょう。詳細は講演の動画をご参照ください（英語）。
- 保護を強化するためにDKIMを実装する。少々難しいかもしれませんが、検討する価値はあります。こちらも同じく、適切に構成してください。攻撃者がどんなことを狙ってくるかについては、こちらで詳しく解説されています（リンク先は英語）。
- 理想的にはDMARCを導入する。DMARCは、SPFとDKIMが抱える悪用可能な欠陥のほとんどを修正します。
- 受信メールの設定を確認する。
- エンドポイントとメールサーバーに、信頼できるセキュリティソリューションを導入することで、防御の層を厚くする。
ヒント