高木浩光＠自宅の日記

目次はじめに 連絡先:blog@takagi-hiromitsu.jp

訪問者数本日: 718 昨日: 2178

2005年11月18日

■ オレオレ証明書の区分改訂版

はてなキーワードに「オレオレ証明書」の項目ができていた。ここにある冒頭の「(特にPKI上不適切な場面で使われる)自己署名証明書。」という定義は私の定義とは異なる。自己署名とは限らないし、不適切な場面とも限らないからだ。そのためその下にある第一種〜第五種の区分の記述と矛盾が生じている。

私の定義では、クライアント側で認証パスを辿れない（検証できない）証明書のすべてをオレオレ証明書としている。それは、サーバ側の設定ミスかもしれないし、設定が正しくても今まさに通信路上で攻撃を受けているのかもしれない。証明書の発行の意図に関係なく、クライアントから見れば等しく「オレオレ」と言っているようにしか見えない。

攻撃を受けている場合を除いて、クライアント側でオレオレ証明書となる場合の、その原因別の区分を9月3日の注釈で書いていた。他に第六種もあったので追記して以下に再掲する。

第一種オレオレ証明書: 不特定多数に利用させることを想定していて、ルート証明書もサーバ証明書もインストールさせるつもりのないもの。
第二種オレオレ証明書: 不特定多数に利用させることを想定していて、ルート証明書かサーバ証明書をインストールするよう促しているが、インストール方法として安全な手段が用意されていないもの。
第三種オレオレ証明書: 不特定多数に利用させることを想定していて、ルート証明書かサーバ証明書をインストールするよう促しており、安全なインストール方法が用意されているもの。
第四種オレオレ証明書: 特定の者だけに利用させることを想定しているもの。
第五種オレオレ証明書: 正規の認証局から取得したサーバ証明書であるが、一部のクライアントでその認証局がルートとして登録されていないもの。
第六種オレオレ証明書: 正規の認証局（中間認証局）から取得したサーバ証明書であるが、中間認証局の証明書をサーバに設置していないため、クライアントが認証パスを検証できないもの。

ここではSSLのケース（サーバとクライアント）で示したが、同様に、S/MIME や、コード署名、その他文書への署名等のPKIにおいても同様となる。

■ Phishing被害者の実例

まつもとゆきひろさんがPayPalを騙るphishingに引っかかってしまったそうな。たいへんだ。

以前、phishingの話題でテレビ局の取材を受けたときに、「実際に被害に遭った方をご存じないですか？」と相談された（映像に使う必要がるのだろう）のだが、あいにく紹介できる人がなかった。もし次の機会があったら、まつもとさんを紹介しよっと。きっと臨場感たっぷりに状況を語ってくれるに違いない。

■ ISPのパスワードを破ってメールを奪回する子供向けゲーム

「どうしよう…あんなメール出さなければよかった…」「なんとかメールを取り戻してみよう！」と、 4つの「ISP」のうちいずれか2か所の「パスワード」を素早くクラックしてメールを奪回するという、子供向け教育ゲーム（警察庁ご謹製）。

本日のリンク元 TrackBacks(2)

2005年11月22日

■ 攻撃者視点ではなく開発者視点での解説を

8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が出ていた。タイトルからして意味がわからない。「合法的に近づける」とは何だ？英文の直訳か何かか？

その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解しないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。

この例では、「userid=-20298745283」がクエリストリングにあたる。クエリストリングはURL内に含まれているため、誰でも見ることができる。従って、ユーザーのちょっとした出来心やいたずら（例えば「この数字の最後を1つだけずらせばどうなるかなー？」）によって、脆弱性が露見することも多い。

この例であれば、誰が見ても明らかなように、「userid」のパラメータがユーザー管理に使用されており、数字を変えればほかのユーザーになりすませるのではないかと想定できるのだ。このクエリストリング内の情報を任意に書き換え、Webサイト管理者にとって想定外の結果を引き起こすのが、パラメータタンパリングである。

Web アプリケーションファイアウォールの必要性第2回多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

いいかげんなことを言ってもらっては困る。URLに「userid=1234」と書かれているからといって、その値がセッション追跡（ユーザのログイン状態の管理）に使われているとは限らない。

たとえば、表示するページのIDを指定するパラメタとして処理されている場合だってある。blogやSNSのWebアプリケーションなどがまさにそうだ。具体的には、

http://d.hatena.ne.jp/?userid=HiromitsuTakagi

というURLがあるときに、「HiromitsuTakagi」以外のIDでログイン中の人（もしくはログインしていないゲスト）がこのページにアクセスした場合には、「HiromitsuTakagi」の日記ページが普通に表示され、「HiromitsuTakagi」の IDでログインしている人がアクセスした場合には、編集権限付きの画面として表示されるというのは、ごく普通のことだ。

URLパラメタにユーザIDらしきものがあるとき、直ちにそれが脆弱性であると推定してよいのは、ログイン時にcookieが発行されていない場合である。にもかかわらず、記事の続きを見ると、

この例におけるパラメータが、ユーザー認証が行われた後、ユーザーが送信するURLのクエリストリングに付与されており、何度ログオンし直しても同じ値であった場合、ほぼ間違いなく固定のユーザーIDとして使用されている。こういう場合、通常Webアプリケーションは、ログオンごとに動的に生成されるセッションCookieを併用した設計となっている。

このとき、攻撃者はセッションCookie生成のメカニズムを知ろうとするだろう。

とあり、cookieでセッション管理されている場合を想定しているようだ。わけがわからない。

このとき、攻撃者はセッションCookie生成のメカニズムを知ろうとするだろう。もっとも、クエリストリングに重要な情報を入れてしまうこと自体、以下の危険性が指摘できる。

1. Webブラウザのキャッシュ
2. リファラ（Referer）
3. プロキシやファイアウォール

この話題を出すなら、「URLにユーザID」というストーリーではなく、URLにセッションIDの例で説明するのがよい。

記事の2ページ目も微妙におかしい。

まず、「Cookieポイズニング（Cookie Poisoning）」という用語がおかしい。 Cookieであろうが、POSTのhiddenパラメタであろうが、URLパラメタであろうが、それはパラメタの部位が異なるだけであって、ブラウザが勝手な値を送信してくるという脆弱性の理屈は全く同一であり、それぞれを、poisoningだの、 manipulationだの、tamperingだのと呼び分けるのがくだらない。（いずれも manipulationで統一すればよい*1。）

そもそも、Cookie Poisoningとは本来別の意味で用いられる用語だった。たとえば、2000年2月に発表された CERT Advisory CA-2000-02 を見よ。次のように書かれている。

Attacks May Be Persistent Through Poisoned Cookies

Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code.

CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests

これはクロスサイトスクリプティング脆弱性について最初に発表された文献だが、その様々な脅威を列挙する中で、この部分は、cookieをセットする JavaScriptが埋め込まれたときに、ユーザのブラウザに悪意あるcookieがセットされて、それが永続的に当該サイトへの攻撃となる場合があることを述べている。

このように、poisoningとは本来、被害者のコンピュータに攻撃者が毒を盛ることを指す用語だろう。「DNS Cache Poisoning」だってそうだ。自分のブラウザのcookieの値を変更して脆弱サイトに攻撃を仕掛ける行為を、「Cookie Poisoning」と呼ぶのは臍で茶が沸いてしまう。

どうにもこう、攻撃者視点の人達（つまり「ハッカー」）は、問題の本質を理解していないことが多い。「こうやればああなる（場合がある）」ということをただ知っているだけなのだろう。おどろおどろしい言葉を無駄に使いたがる傾向もある。

続いて、ページの最後に、

この後、sendボタンをクリックすればあらゆる商品を自分の好きな金額で購入することができる。ここでは商品1から3まですべて100円に書き換えている。

この攻撃からサイトを守るには以下の方法がある。

金額など、改ざんによる誤った処理がされる可能性のある内容をCookie として格納しないようサーバプログラムの仕組みを変える
サーバなどでCookieを暗号化し、人間が判読できないようにする
Web アプリケーションファイアウォールの必要性第2回多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

とあるが、正統な解決方法である次が抜けている。

アクションを実行する（注文を確定させる）最後のページで、再度データベースから商品番号で単価を検索して使用する。

そもそも、単価をcookieに入れるというこの種の作り方は、セッション追跡機構のないWebアプリケーション構築手法をとらざるを得ない場合（ユーザ登録機能がなく、単発で住所入力をして注文するタイプのサイト）によく使われるものであって、注文画面の途中経過ページにおいて、必要な情報を前のページから引き継いで画面表示させることで、ページ毎にデータベースを検索するというコストを削減するためにやっていることだ。だから、その前提があるときに、「cookieとして格納しないよう」というのは解決策ではない。

さらに記事の3ページも問題が多い。

クロスサイトスクリプティング（Cross Site Scripting）

（略）

この攻撃は性質上、広範囲に広がりやすい。非常に大きな被害を出した複合型ワーム「Nimda」もクロスサイトスクリプティングを感染手段の1つとして採用していた。感染するとNimdaはHTMLファイルを書き換え、JavaScriptと攻撃プログラムを挿入する。そしてほかのユーザーが、そのWeb サーバ上のページを閲覧するだけでNimdaに感染してしまうのだ。

Web アプリケーションファイアウォールの必要性第2回多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

おいおい、Nimdaがクロスサイトスクリプティング脆弱性を突いて広がったなどというのは初耳だ。それは全く事実でない。

これは二重に間違っている。まず第一に、Nimdaワームに感染したWebページというのは、ページコンテンツが改竄されたことによって発生した。改竄される原因は、IISの脆弱性を突かれた場合と、サイト内部のネットワークでNimda感染が広がってローカルにファイルが改竄されたものだった。これらはいずれも、クロスサイトスクリプティング脆弱性と関係がない。第二に、そもそもNimda 騒動の原因は、JavaScriptを使用せずとも攻撃できるところに本質があった。 Nimdaは、.eml形式のファイルに攻撃コードを仕込んで、それをWebサイトに置き、そこへのインラインリンクを設けておくことにより、そこを閲覧した者が感染してしまうというものだった（半年前の脆弱性パッチを適用していなかったブラウザは）。たしかにJavaScriptも使われてはいたが、これは、感染していく様子を見えにくくするために、画面外にポップアップウィンドウを出してそこで実行させるという攻撃者のちょっとした工夫にすぎず、それは問題の本質ではない。

クロスサイトスクリプティング脆弱性の脅威を大袈裟に表現したいあまりに、「この攻撃は性質上、広範囲に広がりやすい」などと言おうとして無理が生じたのだろう。説明すべきは、cookieを盗まれると何が起きるかという点なのに、その説明がない。

続く4ページ目はもっとひどい。

バッファオーバーフロー（Buffer Overflow）

（略）

Webアプリケーションにおけるバッファオーバーフローの脆弱性は、以下のようなページで発生しやすい。
<form action=http://test.fubar.jp/search.cgi method="get" name="search">
<input type="text" name="search" value="" size="45"></td>
<form>
このソースでは、検索フィールド「search」に入力できる文字列は45文字までに制限されているので、Webブラウザ上から46文字以上のタイプをしても入力されない。しかし、このHTMLをダウンロードし、以下のように書き換える。
<form action=http://test.fubar.jp/search.cgi method="get" name="search">
<input type="text" name="search" value="" size="1099511627776"></td>
<form>
これによって同じ検索フィールドに1GBの文字を入力することができ、バッファオーバーフロー攻撃が可能になる。これはクライアント側のWebブラウザのチェック機構に依存して、HTML上でデータ長の制限を行っているために発生し得る問題点である。チェック機構をクライアント側に依存してはならない。

Web アプリケーションファイアウォールの必要性第2回多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

おいおい、size属性は画面表示上の入力欄の大きさを示すだけだよ。 maxlengthの間違いなのだろうが、「maxlength="1099511627776"」というのはあまりに滑稽だ。なぜなら、この属性は指定しなければデフォルト値は無限大だからだ。

「ダウンロードして書き換える」などということも問題の本質では全くない。バッファオーバーフロー攻撃を仕掛けるなら、直接HTTPポートにTCP接続して、 POSTでどんなデータでも送ればよい。

「1GB」というのも滑稽だ。バッファオーバーフローはなにも「巨大なデータを送る」ことに本質があるわけではない。実際、Slammerワームはたった376 バイトのデータでバッファオーバーフロー攻撃を実現するものだった。

ようするに、なんとなくの感覚的イメージで脅威を伝えようとしているのだろう。

バッファオーバーフロー攻撃からサイトを守るには以下の方法が有効である。

Apacheにおける「LimitRequestBody」などを設定し、Webサーバであらかじめ受け入れる送信データ量の制限を設定しておく

特定のサイズ以上のデータが送られてきたらクライアントにエラーを返すようなコーディングを行う

という説明には危険性さえある。Slammerのように 376バイトで突けるバッファオーバーフロー脆弱性があったらどうするのだ？バッファサイズはなにも1024 バイト以上あるとは限らない。32バイトとかのバッファで境界を無視したプログラミングをしている例はいくらでもあるだろう。

SQLインジェクションもクライアントから送られる入力データを入念に検証していないWebアプリケーションにおいて発生する。攻撃者はメタキャラクタを入力データに挿入し、Webアプリケーションを経由して不正なクエリをデータベースに送信する。

べつに、「入念」とかそういう問題じゃない。インジェクション系の脆弱性は、変数の出力時に、文脈を無視した文字列連結のコーディングをしているところに原因があるのであって、セキュリティ以前に、正常系として、任意の入力に対して正しく動作するプログラミングをしていれば、普通に解決するはず（だが、できていない実態がある）というところに問題の本質がある。

SQLインジェクションも特殊文字を悪用することによって行われるので、ユーザー名やパスワードの文字種制限やサニタイジングが有効である。

パスワードに「'」を使わせないつもりなのか？パスワードには強度確保のために記号を入れるのが常識なのに？

「サニタイジング」という便利な言葉は、問題の本質から目を背け、場当たり的な対処方法という安易な説明を誘発してしまうので、有害だ。

これについては、「サニタイズ言うなキャンペーン」実施中ということについて説明しないといけないと思っているが、時間がないのでまだ書いていない。

この記事は冒頭で、次のように書かれいてた。

前回の内容に対して、周囲からいくつか質問をもらった。「こんなこと書いていいのか？」というものである。つまり、誰もが簡単に攻撃を行えることを示すことによって、かえって被害を増加させるのではないか、という懸念を持たれたわけだ。今回の記事では、より多くの攻撃手法を説明していくため、本論に移る前にこういった質問に回答しておきたい。

Web アプリケーションファイアウォールの必要性第2回多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

そりゃそうだろう。それは、記事が攻撃者視点で書かれているからだ。加えて、正統で妥当な解決方法がないかのような書きっぷりだからだ。素人は問題の本質が見えないままショックを受けてしまう。

この種の批判を浴びた攻撃者視点の人はこう弁明するに違いない。「攻撃方法を知らずして対策ができますか？」と。それはその通りであるが（必要ではあるが）、そのような態度に胡坐をかいていてはいけない（十分ではない）。より適切な説明方法があるのだということを理解してもらいたい。

もっとも、この記事は「Webアプリケーションファイアウォール」の宣伝であるためこのような書き方になるのかもしれない。つまり、技術を理解する立場にない対策担当者が相手であるために、怖いということさえ伝わればよいというのかもしれない。しかし、素人も直感的に何かおかしいということに気付くものだ。いつまでも攻撃者視点でばかり煽っていると、業界全体の信用を損ねることになりかねない。

ひと昔前なら攻撃者視点での解説にも意義があった。しかし、対策の必要性自体は既に理解が広まった（が対策の方法が普及していない）現在では、もうそういうのはいらない。

私も時間がある限り書けるものは書いていくつもりだが、開発者視点で解説できる執筆者がもっと増えてほしいと思う。セキュアな開発をちゃんとやっている開発者はたくさんいるはずだ*2。

さてこの連載の次回は以下の内容になるのだそうだ。それはそれで重要な解説なのでたいへん楽しみだ。本当にWebアプリケーションファイアウォールで対策になるのかどうかが明らかになるかもしれない。

次回から、これらWebアプリケーションの脆弱性をセキュアプログラミングではなく、WAFのような外部機器にて防御していく手法について説明していく。

Web アプリケーションファイアウォールの必要性第2回多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

*1 連載の第一回の記事には「マニピュレーション」と書かれているが、 manipulationぐらい日本語で言え。

Hiddenフィールドマニピュレーションは、「隠しフィールド操作」などと訳されることがあるが、そうすると意味が不明瞭になるため

との釈明があるが、意味不明瞭になるのは「hidden」を訳したからであって、「操作」を「マニピュレーション」にしないと意味不明瞭になるというのは、関係者の単なる思い込みでしかない。「hiddenフィールド操作」でよい。もっとも、これは攻撃手法の用語であって、脆弱性の原因を指す用語としては、「パス名パラメタの未チェック」とか、「推測可能なセッション追跡パラメタ」などと表現するのが正しい。

*2 WAFによる解決という手段は、万が一のプログラミングミスの保険として、開発者にとっても必要なものであろう。そのように位置付けたうえで解説し、何が解決できて、何ができないかを説明する必要がある。そのためには、開発者の視点なしには無理だろう。ネットワーク管理者の理解でWAFの設定がきちんとできるのだろうか。

本日のリンク元 TrackBacks(2)

2005年11月25日

■ ウイルスバスター2006はトレンドマイクロの定義で言うところのスパイウェアである

星澤さんがウイルスバスター2006のスパイウェア疑惑について、11月2日から書いていらしたが、18日になってもトレンドマイクロから回答が得られないとお困りのご様子だったので、21日の午前、私も聞いてみることにした。

一般的に、ユーザからの問い合わせが多くなる商品を販売している会社では、この種の重要事項の問い合わせ（たとえば脆弱性の指摘など）が、ユーザの一般的な質問に紛れ込んでしまい、判断のできる肝心な担当者へ情報が伝わらないということが起きがちなものだ。そこで、大代表に電話をし、個人情報保護担当者と電話で話したいと伝えた。（トレンドマイクロの個人情報保護方針にはメールアドレスしか書いてない。）すると「システムの都合でここから個人情報保護担当者には電話をつなげない」と言われるわけだが、その対応は想定の範囲内なので、「折り返しお電話いただければと思います」と主張したところ、しばらく後に、個人情報保護担当の方から自宅にお電話いただくことができた。

いろいろ質問したところ、正確に回答するためにメールで回答したいとのことだった。そして、今日、メールでの回答が到着した。

以下は、私がした質問の内容と、それに対応する回答（先方のご希望に沿って正確を期すため、回答の部分は原文のまま変えずに引用する）である。

質問: 送信しているデータはURLの全体なのか一部なのか？

回答: トレンドマイクロのサーバ（以下弊社サーバ）にはパラメータも含めた全ての情報を送信します。ユーザが意図的にメールアドレスなどをＵＲＬに入れた場合やセキュリティ上問題のあるWebベースのアプリケーション（URLにパスワードや重要な情報がそのままの形で出てしまうようなサイト）にアクセスした場合、FORMの隠しフィールドやリンクにこれらの情報が埋め込まれたページが表示され、ユーザーが明示的に入力しなくても、ＵＲＬリンクのクリックやＦＯＲＭの入力を行ったときに、それらの付随する（明示的に入力されていない）データも結果として送信されることはあります。ただし、弊社サーバに保存されるのはＵＲＬだけで、パラメータは保存されません。

質問: 送信しているデータは、復号可能な暗号化を施したものか、それとも一方向性関数でハッシュしたものか？

回答: （秘密鍵で複合化（原文ママ）するタイプの）暗号化処理をしています。

質問: 暗号アルゴリズムは何か？鍵長は何ビットか？（https サイトのように、ユーザの情報を送信する暗号化通信では、鍵長が何ビットであるかが表示されるようになっているのだから、自動的にユーザの行動情報を送信するウイルスバスターも、鍵長をユーザが知ることができるようになっているべきではないか？）

回答: これ以上の情報は弊社として社外秘扱いの情報としておりますため回答できません。あしからずご了承ください。

質問: ウイルスバスターはトレンドマイクロの定義で言うところの「スパイウエア」に該当するのではないか？

回答: [URLフィルタ機能]ならびに[フィッシング詐欺対策ツールバー]の実装に関して、お客様に対して十分な説明が無かったことに関しましては、弊社といたしましても謙虚に受け止め、今後、弊社ホームページならびに製品ヘルプ等へ本仕様に関する情報を明記を行い、お客様に対して情報開示を行っていきたいと考えております。

（これは回答になっていないので、「はい」または「いいえ」で回答するよう、再度問い合わせ中。）

さて、トレンドマイクロの用語集に掲載されている、スパイウェアの項目を見てみる。

スパイウェア

「スパイウェア」は不正プログラムには分類されないグレーゾーンのプログラムです。ユーザのコンピュータの動きや個人情報を監視し、この種の情報をユーザの許可またはユーザに知らせることなしに送信するアプリケーションであり、動きとしては情報漏洩型ハッキングツールに似ていますが、一般的なソフトウェア会社によって作成されている、セキュリティポリシーが開示されている、セキュリティに致命的な情報を流さない、などの条件により特に不正なものとは断定できないものです。逆に言うと「スパイウェア」と呼ばれているものは特に致命的な情報を漏らすことはない、とも言えます。致命的な情報を漏らすものはハッキングツールに分類され、当然検出の対象となります。

ウイルス対策基礎知識 - 用語集, トレンドマイクロ株式会社

まさに、ウイルスバスター2006は「スパイウェア」である。

スパイウェアという言葉の定義が広すぎるあまりに、事業者間で紛争が起きていることは、英語圏からのニュースで伝えられてきたところだ。他社製品をスパイ呼ばわりするわけだから、紛争が起きても不思議でない。

だが、ウイルス対策ソフトベンダーは、そうした紛争のリスクを承知の上で、意識的にあえて「スパイウェア」を広い意味で定義してきたのだと思われる。

なぜなら、上の定義で「ハッキングツールに分類」されるようなマルウェアの場合、ユーザのコンピュータに本当に仕込まれていることは、そう多くはないだろう。そうすると、（狭い意味の）「スパイウェア」対策ソフトをせっかく開発して販売しても、何も検出されないことがほとんどであっては、ユーザがそのソフトのありがた味を感じることができない。つまり、できるだけ広い範囲で検出するようにしないとビジネスにならない。

実際どうだろうか。初めてスパイウェア対策ソフトを動かしてみたときに、何十個ものスパイウェアが検出されたと*1 思ったら、単にcookieの検出だったなんてことを経験した人は多いだろう。cookieのようなものまで「スパイウェア」ということにしてしまうことは、対策ソフトベンダーにとってはビジネス上必要なことだったのだろう。

そういう経緯のあるウイルス対策ソフトが、自分自身が「スパイウェア」の挙動をしているのである。

ソニーBMGの音楽CDがrootkitまがいのものをインストールするという騒動でも明らかになったように、「何をやってはいけないのか」という常識が、セキュリティコミュニティにはあっても、一般企業の全部にまでは浸透してないということがある。そうした「常識」は必ずしも法律で定めらるわけではないのだから、批判を繰り返すことによって、一般企業へも理解を広めていくしかないだろう。

同様に、「ユーザに知らせることなしにユーザのコンピュータの動きを送信する」というこの種の挙動は、これまでにも何度かの騒動を経て、やってはいけないことだという常識が、少なくともセキュリティコミュニティにはできあがっていた。

企業が他社製品をスパイ呼ばわりしていいのか？とも思えるところ、これはセキュリティ業界では常識なので、スパイ呼ばわりしてよいというわけである。トレンドマイクロの「スパイウェア」の定義のように、「ユーザに知らせることなしにユーザのコンピュータの動きを送信する」アプリケーションのことをスパイウェア呼ばわりするのは、許されているわけだ。

したがって、ウイルスバスター2006をスパイウェア呼ばわりすることを、トレンドマイクロは止めることができない。

ちなみに、現時点でも、トレンドマイクロホームページの「ニュースとお知らせ」に、この件のアナウンスが出ていない。

（つづく）

*1 リンク先の「眞鍋かをり：スパイウェア撲滅隊長に就任」（毎日新聞）には次のように書かれている。

眞鍋は（略）隊長に任命され、「私のパソコンから何十個もスパイウェアが出てきた。これからは周囲の人にあいさつ替わりに『スパイウェア対策してる？』と話して、意識を高めたい」と抱負を語った。

眞鍋かをり：スパイウェア撲滅隊長に就任, 毎日新聞芸能, 2005年11月24日

本日のリンク元 TrackBacks(25)

2005年11月27日

■ ウイルスバスター2006は存在しないサーバ名もトレンドマイクロに送信する

25日の日記に書いたように、ウイルスバスター2006のフィッシング対策機能（Internet Explorerのツールバーとして搭載された機能）は、ユーザがアクセスしようとした任意のサイトについて、アクセスする前の段階で、トレンドマイクロのサーバにそのURLの全部を送信して、「評価」をもらった後、IEのアクセスを続けさせるかを判断するようになっているそうだ。

しかし、DNSで名前解決できないホスト名を指定したURLにアクセスしようとしたときにも、そのURL文字列がトレンドマイクロに送信されてしまう。つまり、例外なくどんなURLでも送信されるようだ。

たとえば「http:/a/」という文字列をIEのアドレスバーに入力してエンターキーを押すと、ウイルスバスターが自動的にTCPポート80番でトレンドマイクロのサーバに接続し、以下のリクエストを送信して、次のレスポンスを返してくる（一部略）。

GET /P/48/B16B1603A25DA22E70AF6AD32A72DBC690B90CC3FF4C273E HTTP/1.1
User-Agent: TMI_SCM
Host: tis14-JP.url.trendmicro.com:80

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 260

256/94DB4EB7541411D522CFCE6EAE761750（略）

他のURLを試してみると、同じURLについて何度か繰り返しても同一となったのだが、次のようになった（見やすいように16文字ごとに空白を空けておいた）。

http:/a/
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 90B90CC3FF4C273E
http://a/a
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 4AD754147734006B
http://a/aa
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 8C86279EEB6964B9
http://a/aaa
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A
http://a/aaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A AAB1A39A842F683C
http://a/aaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A BDD6EC88255B73C9
http://a/aaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 6630550CE60C84AE
http://a/aaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A CB62188C3FF1DBEB
http://a/aaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A FE30CE3DE34C9530
http://a/aaaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 1AAFA52B91C1750F
http://a/aaaaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 5A671E1CDCDEF86D
http://a/aaaaaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3
http://a/aaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 AAB1A39A842F683C
http://a/aaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 BDD6EC88255B73C9
http://a/aaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 6630550CE60C84AE
http://a/aaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 CB62188C3FF1DBEB
http://a/aaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 FE30CE3DE34C9530
http://a/aaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 1AAFA52B91C1750F
http://a/aaaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 5A671E1CDCDEF86D
http://a/aaaaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 2A079EAEB1330AE3
http://a/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
/P/160/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 2A079EAEB1330AE3 
2A079EAEB1330AE3 2A079EAEB1330AE3 2A079EAEB1330AE3 2A079EAEB1330AE3 2A079EAEB1330AE3

http://b/aaaaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E FF7483DA766AA203 D1AB49418B00911A 2A079EAEB1330AE3 2A079EAEB1330AE3

これがまともな暗号処理なのかどうか心配なところだが、トレンドマイクロの個人情報保護担当者に暗号アルゴリズムは何かと尋ねても、

質問: 暗号アルゴリズムは何か？鍵長は何ビットか？（略）

回答: これ以上の情報は弊社として社外秘扱いの情報としておりますため回答できません。あしからずご了承ください。

25日の日記

とのことだったので、なんとも言えない。

自衛のためにユーザは、自分のコンピュータのこのような挙動を調べて、信用できるかどうかを自分で判断するしかない。なぜ自衛する必要があるかというと、ユーザは https:// のサイトにアクセスする場合があるからだ。

■ ウイルスバスター2006はHTTPSサイトのURLもトレンドマイクロに送信する

https:// のページにアクセスした場合にはどうなるかというと、なんと、同様に以下のリクエストが送信される。しかも、SSLなしの HTTP で。

GET /P/96/B16B1603A25DA22E4DF7B231A59FA7D1D686FB64DB15EAE3607FA285A32FCD1DFD70A1D378A470F328AD165D7F7E4C9E HTTP/1.1
User-Agent: TMI_SCM
Host: tis14-JP.url.trendmicro.com:80

HTTP/1.1 200 OK
Content-Length: 292

256/94DB4EB7541411D522CFCE6EAE761750（略）

これはいかがなものか。

ログイン機能を持つサイトでURLに

http://exmaple.com/foo.cgi?sessionid=dc9f86389fa5ecc137c256

というように「セッションID」（秘密の臨時受付番号）を埋め込むようになっているところがけっこうある（cookieをオフにしていると現れることが多い）*1が、このIDを盗まれたら、セッションハイジャックされてしまう。

しかし、送信されるURLデータは独自に暗号化されているので、これは脆弱性にはあたらないのだろう。これを脆弱性だとしてIPAに届け出ても、「URL自体を暗号化しているので、パケット盗聴されてもセッションIDを盗まれることはありません」ということになることは目に見えている。

しかも、25日の日記に書いたように、トレンドマイクロの個人情報保護担当者は、次のように主張する。

回答: トレンドマイクロのサーバ（以下弊社サーバ）にはパラメータも含めた全ての情報を送信します。ユーザが意図的にメールアドレスなどをＵＲＬに入れた場合やセキュリティ上問題のあるWebベースのアプリケーション（URLにパスワードや重要な情報がそのままの形で出てしまうようなサイト）にアクセスした場合、FORMの隠しフィールドやリンクにこれらの情報が埋め込まれたページが表示され、ユーザーが明示的に入力しなくても、ＵＲＬリンクのクリックやＦＯＲＭの入力を行ったときに、それらの付随する（明示的に入力されていない）データも結果として送信されることはあります。ただし、弊社サーバに保存されるのはＵＲＬだけで、パラメータは保存されません。

25日の日記

つまり、まずい情報が送出されるのは「セキュリティ上問題のあるWebアプリケーション」の場合だという。これでは、届出をしてもそのように言われてしまうだろう。

ウイルスバスター2006を使っていて、cookieを切ってWebアプリケーションにログインするユーザは、トレンドマイクロの暗号方式が安全だと信用できないならば、この機能を無効にして自衛するしかない。

ユーザの大切な情報を送信することも起き得るのだから、正しい暗号を正しく使って、どんな暗号なのかをユーザに開示するべきだろう。

■ Googleツールバーは「?」以降を送信しないしHTTPSのときも送信しない

Googleツールバーで「PageRank」機能を有効に設定しようとすると、

という注意をうながすアラートボックスが現れることを知っている人は多いだろう。

PageRank機能は、ユーザが表示したページの「ランク」をツールバーに表示するために、どのページを開いたのかの情報を toolbarqueries.google.co.jp へHTTPで送信している。そのため、プライバシーの注意が勧告されるわけだ。

この機能を有効にしている場合、どのようなデータがGoogleへ送信されているかというと、以下のように、URL中の「?」以降の文字列を削除した情報が送信されるようになっている。

たとえば、

http://slashdot.jp/pollBooth.pl?qid=251&aid=-1

にアクセスした場合、以下のように、

GET /search?client=navclient-auto&iqrn=sB2B&ie=UTF-8&oe=UTF-8&features=Rank:&q=info:http%3A%2F%2Fslashdot%2Ejp%2FpollBooth%2Epl%3F&ch=773439207827 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; GoogleToolbar 3.0.125.1-big; Windows XP 5.1)
Host: toolbarqueries.google.co.jp

となる。「http://slashdot.jp/pollBooth.pl」までしか送信されていない。（「ch=」の部分の意味は不明。）

また、https:// のページにアクセスした場合はどうなるかというと、その場合は何も送信されず、ページランクは無しとなる。

*1 URLに秘密情報を含めるのは安全性が低いので、そのようなWebアプリケーションの作り方は避けるべきであるが、現実問題としてそのようなサイトはまだまだ少なくない。そのようなサイトでも、外部サイトへのリンクや http:// ページへのリンクが存在しなければ、Refererで漏れることはないため、どうにか安全を保っているといえるところもある。しかし、ウイルスバスター2006のこの機能は、URLをHTTPで送信してしまう。（内容は暗号化されているらしいが。）

本日のリンク元 TrackBacks(6)

2005年11月30日

■ SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも

24日のIT Proの記者の眼に「なぜSSL利用をケチるのか」という記事が出ていた。筆者の阿蘇氏には勤務先でWebアプリケーションセキュリティについて取材を受けたことがある。この記事の主張はこうだ。

Webサイトはログイン画面からSSLを使い，利用者はログイン時に鍵マークを確認するのが常識。

阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日

正しい。より正確には「ログイン時」というのは、パスワードを入力する前にということだろう。ただ、その根拠としてこの記事は、フィッシング対策としてサイトが本物かを確かめるためという点だけを挙げているが、その根拠はやや弱い。

SSLをパスワード送信先の画面からではなく、入力画面から使わなくてはならない理由のもうひとつの重大な理由は、パケット改竄可能な状況での盗聴が可能になってしまうからだ。このことについては、だいぶ前から講演で述べてきた。たとえば、2003年9月の「安全なWebサイト設計の注意点」のスライド4から始まるそのビデオで説明している。

なかなかわかってもらいにくい話なので、そのような画面構成になっていたある公共料金の明細閲覧サイトに対して、今年8月にメールで問い合わせをしてみた。以下はそのやりとりである。

質問一回目: ○○○○○のログイン画面が　https:// になっていません。暗号化に不備があるのではないでしょうか？

回答: ○○○○○ログイン後のホームページは、セキュリティを強化したページになっております。そのため、○○○○○○のIDとパスワードも、保護されて送信されております。ご安心下さいませ。

質問二回目: ログイン後のページが https:// になっていることは、パスワード送信前の段階で、どのようにして確認できるのでしょうか？

回答: ○○○○○○のホームページ http://○○○.○○.com/○○○○○○/ の一番下にございます、『プライバシーを保護します』という項目にて、『ホームページに掲載する情報は暗号化して送受信されます。(SSL技術使用)』というご説明を掲載させていただいております。わかりづらくて申し訳ございませんでした。

質問三回目: いくらそのように文章で書かれていても、今私が見ているログイン画面が本当に、送信先が　https://　になっているかどうかは、どうやって確認できるのでしょうか？たとえば、通信路上でパケット改竄されていれば、今見ている画面のリンク先（パスワードの通信先）は、https:// ではなく　http://　に改竄されているかもしれないわけですが。

回答: Internet Explorerをご利用の場合は、ページ上部のメニューの『ツール』⇒『インターネットオプション』をお選びいただき、『セキュリティ』の項目で『保護付き/保護なしのサイト間を移動する場合に警告する』にチェックを入れていただければ、保護されているサイトに接続される際にメッセージが表示されます。

また、改竄につきましてご心配を頂いておりますが、弊社では、リンク先等を改竄されないようホームページを構成いたしております。ご安心してご利用いただければと存じます。

質問四回目: それは、パスワードの送信を開始させた後に表示されるメッセージですね。しかもそれは、正常な場合（https:// でのパスワード送信となっていた場合）に出るメッセージであって、異常な場合（引き続き http:// のままでアクセスする（パスワードを送信する）場合）には、出ないメッセージではありませんか？つまり、あなたの言うように設定していても、パスワードの送信を開始した後、そのメッセージが出なくて異常に気付いても、後の祭なのではないですか？

私は前回、「通信路上でパケット改竄されていれば」と書きました。通信路上でのパケット改竄を防ぐには SSL を使用して https:// にするしかありません。しかし、○○○○○○のパスワード入力画面は http:// であり、通信路上での改竄防止措置がとられていません。「改竄されないよう構成しています」というのは、明らかな嘘偽りです。

回答: ○○○○○○では、パケット改竄などの不正アクセスの防止等に日々努めております。誠に申し訳ございませんが、何卒ご理解頂きますようお願い申し上げます。

質問五回目: 通信路上でのパケット改竄をどうやって御社が防ぐのですか？御社のコンピュータから私の家のコンピュータまでの通信路上で、パケットが改竄されることを、どうやって御社が防いでいるというのかを教えてください。

回答: 高木様のおっしゃる通り、ログイン画面では、httpsによる暗号化が望ましいと思います。 ○○○○○○では、SSLを利用したログイン画面
https://○○○.○○.com/○○○○○○/login.html
も設けておりますが、現状の○○○○○○トップページ
http://○○○.○○.com/○○○○○○/
からは、暗号化されたログインページにアクセスすることができなくなっております*1。

そのため、今後はトップページより、暗号化されたログインページへのアクセスをご選択いただけるような形に変更するよう対応していきたいと思います。

このような質問をするなどして、ご自身で考えて頂かない限り、運用中のサイトの管理責任者にこの問題を理解していただくことは難しい。

その後このサイトの画面構成は改善され、トップページのパスワード入力欄は撤去され、「ログイン」ボタンを押すと https:// のページにジャンプするようになり、そこにパスワード入力欄が現れるという構成になった。

■ クレジットカード業界は最もWebセキュリティを理解していない業界

阿蘇氏の「なぜSSL利用をケチるのか」には、次の記述がある。

今や重要な情報を扱うWebサイトは，SSLを使うのが常識。しかし，ログイン後はSSLを使うのに，ログイン画面の表示にはSSLを使用していない Webサイトが意外に多い。銀行のサイトではさすがに減っているが，Webメールやクレジットカード会社などにはまだある。そのようなサイトに限って，「ログイン時にSSLを使うのでIDやパスワードは暗号化されます」とわざわざ注意書きがあったりする。

阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日

銀行のインターネットバンキングでは、以前から、パスワード入力画面は、サイトのトップページにはなく、ボタンを押して進んで現れる専用画面に設置されていて、入力画面からして https:// になっているというところがほとんどだった。

それに対しクレジットカード会社は、どういうわけか、そのような構成ではなく、カード会社トップページにパスワード入力欄を設けており、画面は SSLを使わずに http:// のままとなっているところがやたら目につく。

クレジットカード産業協会の会員企業一覧から、いくつかのメジャーなカード会社のサイトについて調べてみた。

このように、21のクレジットカードのうち、ID、パスワード入力画面がSSLになっていないところは 15サイト、つまり7割を超える。

どうしてこんなことになっているのだろうか。銀行とは対照的である。作っている業者が閉じた世界の業界に限定されているのか、それとも、同業他社のサイトを真似て作るために、どこかが始めたものが伝染してしまっているのか。

銀行業界では、昨年秋のフィッシング詐欺報道の機会に、一斉にアドレスバーを隠さない画面構成に改善するということがあった。業界内での情報伝達がある程度できているのだろう。

クレジットカード業界は、フィッシングやスパイウェアの報道に対して、高額なセキュリティ対策製品を購入するという方向に出た。ろくに対策にならない、それどころか誤ってユーザを安心させるような、つまらない「対策ソフト」がこぞって導入されたことは、業界通にはよく知られているところだ。

どうやら、クレジットカード業界は、Webセキュリティに関する正しい情報が伝達されない状況にあるらしい。これはクレジット産業協会の認識不足に原因があるのではなかろうか。

*1 「できなくなっております」とは、https:// ページへのリンクがないという意味で、ユーザが自力でアドレスバーに「s」を挿入して https:// で同じページにアクセスすることはできるようになっていた。

本日のリンク元 TrackBacks(15)