国会という公の場を使って1通のメールの真偽が問われたのは記憶に新しい。前回のコラム「メールは信頼できても信用できない」でも取り上げたとおり、普通のメールを本物だ、偽物だと証明することは非常に難しい。ましてや国会で取り上げられたような黒塗りのメール文面だけでは技術的に真偽を問うことは困難だ。
プリントアウトされた黒塗りメールの真偽を見分けるのは難しいが、普段受信しているメールならば偽装メールを見破ることもできる。手元に届けられた普通のメールを例にして読み解いていこう。
メールは1つのテキストデータでできている
あなたがOutlookなどのメールクライアントで読んでいるメールは、実際には「メールメッセージ」と呼ばれるテキストデータが整形されたうえで表示されているものである。文章以外に画像やアプリケーションなどの添付ファイルが付いていたとしても、元のメールメッセージはただのテキストで構成されている。そのテキストを、メールクライアントが解釈して、個別のデータに分解したりバイナリファイルなどに変換したりしている。
メールメッセージは大きく分けて「ヘッダ」と「ボディ」で構成されている。ヘッダには、送信者(From)やあて先(To)、件名(Subject)などの付随情報が含まれている。ボディにはいわゆるメール本文となるテキストや、テキストに変換されたバイナリデータが含まれている。この2つは空行(CR+LF)で分けられている。
メールメッセージについて解説したものは多いので、詳細はほかの文献などに譲る。ここでは偽装を見破るポイントを学んでいこう。
見破るポイントはヘッダにあり
前段でメールメッセージの構造の概要について説明した理由は、偽装を見破るポイントがヘッダに含まれているからだ。まずは、ヘッダについての最低限の仕組みを知っておこう。
ヘッダは、ヘッダフィールドと呼ばれる情報で構成されている。これは、「To」や「Subject」、「Received」などで始まる情報であり、メールがサーバを経由するごとに追加されていく仕組みになっている。
図2を見ながら説明すると、最初のヘッダ(1)は送信者のメールクライアントが作成したものである。送信後は、基本的にSMTPサーバと呼ばれるサーバを経由するごとに、新たなヘッダが既存のヘッダの上に追加されている(2)〜(4)。例外として、受信者側のPOPサーバやメールクライアントが付けるヘッダがあるが、これは既存のヘッダの下に追加されることが多い(5)。
図2 ヘッダ情報(画像をクリックすると別ウインドウで拡大します)
1:送信者側のメールクライアントが付けたヘッダ
2:送信者側のSMTPサーバが付けたヘッダ
3:受信者側のSMTPサーバが受信した際に付けたヘッダ
4:受信者側のSMTPサーバがローカルに転送する際に付けたヘッダ
5:受信者側のPOPサーバが付けたヘッダ
偽のヘッダは簡単に付けられる
ヘッダを偽装することがどれぐらい簡単なのかを知っておこう。最も手軽に偽装できるヘッダフィールドは、差出人を表す「From」だ。多くのメールクライアントでは、「From」に指定する内容を、差出人の「名前」と「メールアドレス」という項目で任意に設定できる。つまり、ウソの内容も入力可能ということだ。
実際に自分のメールクライアントの「名前」と「メールアドレス」の設定を適当に書き換えて、自分あてにメールを送ってみるといい。受信したメールの差出人は先ほど適当に書き換えた内容になっているはずだ(一部の環境では送信できない場合もある)。
最初のヘッダは書き換え放題
これ以外にも図2の(1)に入るヘッダは差出人側のメールクライアントが作成するので、差出人が自由に書き換えられる項目が多い。ただし、「Content-Type」など一部の項目は、メールを正常に表示するために適当に書き換えるわけにはいかないものもある。
不思議に思うかもしれないが、あて先に当たる「To」や「Cc」といった項目も自由に書くことが可能である。メールの仕組みでは、あて先に書いてあるメールアドレスには送信せず、まったく関係のないメールアドレスに送信するといったこともできる。
これは「Bcc」を使ってメールを送信した場合を考えると分かりやすい。試しに自分あてに「Bcc」を使ってメールを送信して、その受信メールのヘッダを見てほしい。「Bcc」というヘッダフィールドは載っていないはずである。
メールの送信を担うSMTPサーバにとっては、メールメッセージ内のヘッダの差出人やあて先部分に何が書かれていようが関係がないのだ。実際にどのように送信しているかということに興味があるならば、SMTPというプロトコルのエンベロープという仕組みについて調べるとよい。
最初のSMTPサーバは相手側の手の中にある
送信者側のSMTPサーバが付けるヘッダも送信者側が偽装できる可能性が高いヘッダである(図2の(2))。
ISPなどが用意しているSMTPサーバを使う場合には、ヘッダをサーバ上で自由に改変することはできないが、送信用のSMTPサーバを自前で用意すれば、自由に書き換えることができるようになってしまう。
この中で特に偽装メールで書き換えられやすいのは、1番目の「Received」ヘッダフィールドである。その理由は、ここに送信側、受信側のSMTPサーバのドメイン名やIPアドレス、メールを受け取った時間といった情報が含まれているためである。これらはメールの発信元を特定する重要な情報として扱われるのだ。
偽装者は、先に述べた方法で差出人を表す「From」の項を書き換えただけでは信ぴょう性に乏しいので、「Received」の項も合わせて偽装することで信ぴょう性を少しでも上げるのだ。少しばかりメールに詳しい人ならば一番下の「Received」の項目だけを確認し、「このメールは正しい」と誤認してしまうかもしれない。
偽の「Received」ヘッダフィールドを付けるには
偽装メールを送信できてしまうポイントは、最初のヘッダが自由に書き換え放題だというところにある。差出人のメールクライアントが作成する図2の(1)の部分に、偽の「Received」も含めてしまえばいい。
偽装者が(1)〜(3)までの情報をヘッダフィールドに含めておく。経由するSMTPサーバでは、偽装されたヘッダの上に新たなヘッダを追加していくことになる。一見すると偽装した「Received」も本物のように見えるというわけだ。なお、実際に送る手順は紹介しない。
メールのヘッダという情報の偽装が簡単だということが少しお分かりいただけたかと思う。もちろん、最後に紹介した方法で送った偽装メールでも見破ることができる。その見破る方法や疑われにくいメールを送る方法は、次回のコラムで紹介する。
と、ここで終わってしまうと猜疑心ばかり残ってしまうので、メールのヘッダの中で比較的信頼できる情報のことも少し触れておく。
比較的信頼できる情報とは、受信者側のSMTPサーバが付けた情報である。図2でいうと(3)〜(4)のヘッダである。これは受信者側の環境なので、送信者側が自由にすることはできない。多くのメールメッセージでも、上から1つ目か2つ目までの「Received」ヘッダフィールドは受信者側のSMTPサーバが付けたものである。
メールクライアントでヘッダを見てみよう
皆さんが使っているメールクライアントでは、普段はヘッダ情報の一部しか表示されていないだろう。例えば、Outlook Expressでメールを開いてみると、送信者やあて先、件名しか表示されていない。
ヘッダ情報をOutlook Expressで見るには、メニューから[ファイル]>[プロパティ]>[詳細]とたどる。
メールメッセージ全体を見るには、さらに[メッセージのソース]ボタンを押す。
Webメールでもヘッダを表示できるものもある。Googleが提供するGmailを使っているならば、メールを開いて[詳細オプション]を開き、[オリジナルを表示]をクリックすると、メールメッセージのソースが表示される。
Profile
上野 宣(うえの せん)
1975年京都生まれ。情報セキュリティを世に広げるべく、講演や執筆活動とさまざまな方面で活動中。近著に「今夜わかるメールプロトコル」、「今夜わかるTCP/IP」、「今夜わかるHTTP」(共に翔泳社)がある。
- 今夜こそわかる安全なSQLの呼び出し方 〜 高木浩光氏に聞いてみた
- 「わざと脆弱性を持たせたWebアプリ」で練習を
- Perl Mongersはセキュリティの夢を見るか?
- 誰がシステムのセキュリティを“大丈夫”にするのか
- 技術は言葉の壁を越える! Black Hat Japan 2008&AVTokyo2008(後編)
- 技術は言葉の壁を越える! Black Hat Japan 2008&AVTokyo2008(前編)
- キャンプに集まれ! そして散開!
- 売り上げ重視か、それともセキュリティ重視か!? 「安全なウェブサイト運営入門」
- CeCOS IIにみるネット犯罪のもう一方の側面
- セキュリティ対策の行き着くところは……最終手段? 京都に究極のセキュリティ対策を見た
- 人はオレを情報の破壊神と呼ぶ せめて、ハードディスクの最期はこの手で……
- セキュリティ社会科見学:インターネット物理モデルでセキュリティを考えた
- セキュリティ自由研究:この夏、グミ指を作ってみないか
- Webアプリケーションを作る前に知るべき10の脆弱性
- セキュリティを教える人に知ってほしい 基本が詰まった1冊
- セキュリティのバランス感覚を養うための1冊
- 暗号化仮想ドライブで手軽にファイルを暗号化
- Windows管理者必携、Sysinternalsでシステムを把握する
- 今夜分かるSQLインジェクション対策
- 「取りあえず管理者アカウントで」という思考停止はもうやめよう
- CSSクロスドメインの情報漏えいの脆弱性「CSSXSS」とは
- 偽装メールを見破れ!(後編)
- 偽装メールを見破れ!(前編)
- メールは信頼できても信用できない
- 危機管理体制を整えよう! 個人情報漏えい後の対応ガイドライン
- メールアドレスを漏えいから守る方法
- 「Whoppix」を使ってペネトレーションテストをやろう
- 「ぼくはまちちゃん」 ――知られざるCSRF攻撃
- 25番ポートの攻防
- 平田です。届いてますか?
- 魔法の鍵と最後の鍵
- 個人情報保護法を論理的に読み解く
- 安全確保のために東京は明るく! 大阪は暗く!
- 言論の自由とセキュリティコミュニティ
- 標的にされる無防備なコンピュータ
- セキュリティ担当者には想像力が必要
- 端末を持ち歩くことの危険を意識せよ! 〜 「ノートPC=自動車」論 〜
- 脆弱性のあるサイトとセキュリティ技術者の関係
- いまこそ一般教養としてセキュリティを!
- 大事なことは製品でもなく知識でもなく……
- 治安の悪化で改めて痛感したこと
- Blasterがもたらした多くの“メリット”
- 企業でのセキュリティ資格の意味合いは?
- 人はミスをするものと思え、故に事前対策が重要
- オレオレ詐欺に学ぶソーシャル対策
- あらゆる人にセキュリティ教育を
- 猛威を振るうSARSウイルスに思ったこと
- 痛い目に遭って考えた、ビジネス継続性の重要さ
- 責められるべきはMSだけだろうか?
- セキュリティ技術者を「憧れの職業」にするには?
Copyright © ITmedia, Inc. All Rights Reserved.