
セキュリティ動向チェック
Security&Trustウォッチ(38)
偽装メールを見破れ!(前編)
上野宣
2006/3/29
国会という公の場を使って1通のメールの真偽が問われたのは記憶に新しい。前回のコラム「メールは信頼できても信用できない」でも取り上げたとおり、普通のメールを本物だ、偽物だと証明することは非常に難しい。ましてや国会で取り上げられたような黒塗りのメール文面だけでは技術的に真偽を問うことは困難だ。
プリントアウトされた黒塗りメールの真偽を見分けるのは難しいが、普段受信しているメールならば偽装メールを見破ることもできる。手元に届けられた普通のメールを例にして読み解いていこう。
■メールは1つのテキストデータでできている
あなたがOutlookなどのメールクライアントで読んでいるメールは、実際には「メールメッセージ」と呼ばれるテキストデータが整形されたうえで表示されているものである。文章以外に画像やアプリケーションなどの添付ファイルが付いていたとしても、元のメールメッセージはただのテキストで構成されている。そのテキストを、メールクライアントが解釈して、個別のデータに分解したりバイナリファイルなどに変換したりしている。
メールメッセージは大きく分けて「ヘッダ」と「ボディ」で構成されている。ヘッダには、送信者(From)やあて先(To)、件名(Subject)などの付随情報が含まれている。ボディにはいわゆるメール本文となるテキストや、テキストに変換されたバイナリデータが含まれている。この2つは空行(CR+LF)で分けられている。
![]() |
| 図1 メールメッセージの構成 |
メールメッセージについて解説したものは多いので、詳細はほかの文献などに譲る。ここでは偽装を見破るポイントを学んでいこう。
■見破るポイントはヘッダにあり
前段でメールメッセージの構造の概要について説明した理由は、偽装を見破るポイントがヘッダに含まれているからだ。まずは、ヘッダについての最低限の仕組みを知っておこう。
ヘッダは、ヘッダフィールドと呼ばれる情報で構成されている。これは、「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」(共に翔泳社)がある。 |
| Security&Trust記事一覧 |
TechTargetジャパン
- Facebook タイムライン利用時の「鉄則」 (2012/2/9)
ユーザーインターフェイスの変更措置に伴い浮上した、Facebookの「過剰な情報提供」のリスクと対策とは - 無料サービスなら通信内容を記録してもいいの? (2012/1/13)
無料の公衆無線LANサービスが、ユーザーに無断で通信履歴を記録していたことが判明し、話題に - 攻撃はまるでレーザービーム (2011/12/26)
2011年に話題となった標的型攻撃は「人」という弱点ををねらい打ちにしました。では、人に教育さえしておけば防げるものなのでしょうか? - 見せたくないなら「持たせない」が鉄則! (2011/12/15)
逆コンパイル対策で難読化したのに、大事なデータが解析されちゃった? Androidアプリのセキュリティの道は深い
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -






