 |
企業がすべきフィッシング詐欺対策（2）
正しいメールを正しいと通知する方法の落とし穴
亀田 治伸日本ベリサイン株式会社
システムエンジニアリング部 部長代理
2005/8/5
前回は、フィッシング詐欺に用いられているメール送信元の偽装を取り上げました。また、 「不正なものの反対は『正しい』ではなく、『正しい』か『グレー』のどちらかである。このため正しいものを正しいと判断する技術が必要だ」という話をしました。
企業は、フィッシング詐欺に対する防御方法をユーザーに啓蒙すると同時に、メールを安全に利用するための対策を講じる必要があります。メールを安全に利用するためには、不正なメールを不正であると判断する方法と正しいメールを正しいと通知する方法の2つが挙げられます。前者はパターンマッチングを利用する方法ですが、フィッシング詐欺対策として必ずしも効果的ではありません。
今回は、正しいメールを正しいと通知する方法について解説します。ところで、「正しい」とは何をもって「正しい」と判断するのでしょうか。
それには、メールを送信したサーバを正しいと信頼する方法と、メールを送信した人間を正しいと信頼する方法の2種類があります。前者に属するのが「SenderID」と「DomainKeys」で、後者に属するのが「S/MIME」です（S/MIMEを利用する方法については、次回で紹介します）。
 |
SenderID |
SenderIDはMicrosoftが中心となって推進している技術です。これは、「メールの送信者の欄に設定されているドメインがDNSサーバに登録されているか」「メールを送信したメールサーバのIPアドレスがDNSサーバに登録されているか」を確認する技術です。
 |
| 図1 SenderIDの仕組み |
つまり、DNSサーバに登録されていないメールサーバから送信されたメールはユーザーに配信しない、ということです。例えば、私がMicrosoftのビル・ゲイツ氏と偽り、普段の業務環境から差出人を
| From: "Bill Gates" <bgates@microsoft.com> |
と設定してメールを送ったとしましょう。
このメールが配信されたメールサーバは、MicrosoftのDNSサーバに問い合わせを行います。メールの差出人のドメインであるmicrosoft.comはDNSとして存在していますが、私が使用したメールサーバのIPアドレスはMicrosoftの管理するDNSサーバには登録されていませんので不正なメールと分かります。
しかしながら、SenderIDにもいくつか問題点があります。代表的なものとしてドメインポイズニングという攻撃手法があります。先ほどの例ですと、私がMicrosoftが管理するDNSサーバに対して攻撃を行い、エントリを書き換えることに成功としたとします。その結果、私が使用するメールサーバのIPアドレスがMicrosoftのDNSサーバに登録されるため、ユーザーは偽メールを正しいメールとして受信してしまいます。
この場合一番問題となるのは「ユーザーに間違ったメールが配信されてしまった」ということを通知する手法が存在していないということです。自社のDNSサーバが書き変えられたときに、世界中のサーバ管理者に一括で注意喚起できる仕組みは残念ながら存在していません。
次の問題点ですが、SenderIDはドメインが存在していればユーザーに対してメールを配信してしまいます。仮に私が「hogehoge.com」というドメインを取得したとしましょう。そして
| From: "Bill Gates" <bgates@hogehoge.com> |
とヘッダに指定したメールをhogehoge.com専用メールサーバから送信したらどうなるでしょうか。OutlookExpressだとこう表示されます。
 |
| 図2 hogehoge.comから送信したメール |
果たしてユーザーは気付くでしょうか。恐らく気付かない人もたくさんいるでしょう。なぜなら、そのようなユーザーは「SenderIDにより不正なメールが届かない」と思っているからです。
責任関係のあいまいさも問題の1つです。DNSサーバやメールサーバが書き換えられ、ユーザーに不正なメールが送信され、ユーザーが「SenderIDだから正しいはずだ」と判断してしまった場合、誰が責任を取るべきなのか。この点があいまいでありSenderIDが抱える問題点の1つです。
もちろん、その有効性から、SenderIDはフィッシング詐欺において名前を無断使用される可能性のある企業はいち早く導入すべきかもしれません。しかし、相手側（メールの受信側）のサーバの対応が必須となります。このため、対応範囲（効力）がユーザーまで届いていることを保証できません。
つまりSenderIDはあくまでサーバ-サーバ間のソリューションであり、メールの送信者や受信者はそこに介在していないことに留意する必要があります。
|
DomainKeys |
DomainKeysは、Yahoo!が提唱している送信者認証技術で、http://antispam.yahoo.com/domainkeys（英文）に詳しく解説されています。
SenderIDと異なる最大の特徴は、メールサーバ（MTA）に対する開発やプラグインのインストールが必要となることです（SenderIDは受け側のメールサーバのみ対応が必要）。これは、外部に送信されるメールのヘッダ情報に、メールサーバが電子署名を付与するためです。プラグインはSendMailやYahoo!などが積極的に開発、配布していますので簡単に入手できます。
| 【プラグインの配布サイト】 http://domainkeys.sourceforge.net/ |
電子署名にはPKIのテクノロジーが使用されていますが、電子証明書は使用されていません。この点がDomainKeysにおいてよく誤解される点ですので注意する必要があります。
PKIは公開鍵と秘密鍵という鍵ペアを用いますが、一般的に電子証明書は公開鍵の持ち主を証明するために後から付与されたデータです。公開鍵と同じ意味で使用される場合が多くありますが、厳密には電子証明書と公開鍵は別物です。DomainKeysでは電子証明書を使用せず公開鍵と秘密鍵のみを使用し電子署名を行います。
 |
| 図3 DomainKeysの仕組み |
電子署名について簡単におさらいをします。PKIでは、「公開鍵で暗号化されたものは秘密鍵で復号（解読）可能であり、秘密鍵で暗号化されたものは公開鍵で復号（解読）可能」という特徴が電子署名に利用されています。秘密鍵はそのユーザー（DomainKeysの場合はサーバ）だけが保持し、厳重に管理され他人が簡単に触ることはできません。これに対して公開鍵は配布用で、他人に渡す用途で使用されます。
インターネット上に巨大な公開鍵が登録されているデータベースがあると仮定してください。そこに私が使用している日本ベリサインのメールサーバの公開鍵が登録されているとします。私がYahoo!のAさんへメールを送る際に、日本ベリサインのメールサーバがメールのヘッダ情報および本文に対して、メールサーバが保有する秘密鍵で暗号化した情報を付与します。これが電子署名データとなります。
メールを受け取ったYahoo!のAさんのメールサーバは、メールヘッダの差出人の情報を確認します。「@verisign.co.jp」となっています。そして「@verisign.co.jp」を管理しているメールサーバの公開鍵を先ほどの巨大なデータベースに取りにいきます。公開鍵を取得したら電子署名データを復号します。
復号し中身が解読できた時点で、Yahoo!のメールサーバはこのメールの差出人が正しいドメイン（メールサーバ：@verisign.co.jp）から送付されたと確認できます。なぜなら@verisign.co.jpを管理しているメールサーバが保有する秘密鍵は、そのサーバのみが使用可能であり、公開鍵で復号に成功したということは@verisign.co.jpを管理している日本ベリサインのメールサーバが確かに暗号化を行った、すなわち、日本ベリサインのメールサーバが確かにそれを送付した、という確認となるからです。
では、その公開鍵を管理する巨大なデータベースは誰が準備するのが最もいいのでしょうか。どこかの企業が提供するならば、ユーザーは使用料を支払う必要があるかもしれません。従って、既存のインフラを使用するのが理想的です。DomainKeysではDNSサーバを使用することを提唱しています。
|
送信サーバを信頼することの限界 |
SenderIDの仕組みとDomainKeysの仕組みを見比べてみるとほとんど同じです。つまり両者は非常に似たものともいえます。このためSenderIDとDomainKeysはいくつかの同じ問題を抱えています。
まずDNSサーバが認証の要になっているという点です。このため、ドメインサーバへの直接攻撃に対する手立てがありません。また双方共にドメインが存在していればユーザーにメールが届くという点、ユーザーの意識しないところでサーバ同士がやりとりを行っているため、ユーザーに対する責任分解点が非常にあいまいな点などSenderIDの問題点がすべて当てはまります。
DomainKeysが抱える問題の1つとして、メーリングリストにおけるSubjectの変更や、文字コードの変更における本文の変更に対応できないという点があります。
DomainKeysではメール本文とメールヘッダに電子署名を使用していますが、電子署名は同時にその内容が改ざんされていないかという判別を行う特性も持っています。このため、よくあるSubjectに個別の文字列を付与するメーリングリスト（「テスト」→「[mlxxxx]:テスト」などに変更）ではメールが送信されてから改ざんされていると判断されてしまい認証が失敗してしまいます。
また、メールの文字化けを防ぐためにWebメールや一部のメールサーバなどで見られるメールの文字コードセットの自動変換は、表示されるメール本文など見た目には変更がなくても数学的な値は全く別のものになってしまうため、これも改ざんと判断されてしまいます。
SenderIDもDomainKeysも、これらの問題を解決するための追加仕様策定やモジュールの公開がなされるでしょう。しかし、いま身の回りに発生しているフィッシングの問題は、特に金融機関を中心とした大企業には切実な問題であり、その仕様策定の完成を待っている時間はありません。従って企業は、何か別の対策を施さなければいけません。
双方の送信者認証技術とも、実際に存在しているドメインから送られてきたメールであれば、仮にそれが悪意に満ちたメールだったとしてもユーザーに届いてしまいます。1999年4月のレジストラの自由化以降、残念ながらドメインは偽名と捨てメールアドレスで簡単に取得できてしまいます（全てのレジストラではありませんが、それが可能なレジストラが存在することは事実です）。
また、これらはサーバ側のソリューションであり、ユーザーは自身で判断を行うすべがありません。それゆえ、3つ目の送信者認証技術であるエンド・トゥ・エンドの「S/MIME」に注目が集まっています。次回は、 「S/MIME」を使ったソリューションを紹介します。
| 関連リンク | |
| 本物と偽物のサイトを組み合わせるフィッシング詐欺 | |
| いまさらフィッシング詐欺にだまされないために | |
| フィッシング詐欺対策として企業が負うべき責任 | |
| Sender IDはスパム対策の切り札となるか!? | |
| S/MIMEでセキュアな電子メール環境をつくる！ | |
 |
Security&Trust記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
