昨年7月1日の日記「アドレスバー百景 その1」で旧型myloにアドレスバーがない件について書いていた。今年、そのmyloに新型「COM-2」が発売されたというので、アドレスバーがどうなっているか確かめるため、3月に購入した。
3月某日、myloが家に届いた。箱を開けて取り出し電源を投入。Webブラウザを起動して早速アドレスバーを調べてみると、概ねPSPと同様の方式になっていた。あまり良い設計ではなく、がっかりした。
次に、SSL接続時のオレオレ証明書の警告はどのようになっているだろうかと、オレオレ証明書で運用されているサイトにアクセスしてみた。
まず、https:// ページに入ろうとしていることを示す「セキュリティ保護がされているページに移ります」というお知らせ画面が出た(これは正規のSSLサイトでも表示される)。ここで「OK」ボタンを押すと……
なんと、何の警告もなく、ページが表示されてしまった。
念のため証明書の内容を確認してみると……
自己署名の証明書になっていた。
これは明らかにセキュリティ脆弱性だ。この種類の脆弱性(ブラウザが証明書を検証しない)は、伏せておくよりも早く事実を公表して利用者に注意を促した方がよいという考え方もあり、すぐに日記に書こうかとも考えたが、このケースではIPA、JPCERT/CCを通した方が修正が早く行われるのではないかと考え、IPAの脆弱性届出窓口に通報した。
この届け出は3月27日に受理された。そして本日、JVNで公表となった。修正版が提供されているので、利用者はアップデートで対応できる。
脆弱性情報の届け出では、意見として次のように書いておいた。
盗聴やなりすましの危険性がある異常事態であることを明示して警告し、ボタンを押したくらいでは容易に接続できないような、ユーザーインターフェイスにするべき。
特に、公衆無線LANでの使用を前提としているこの製品では、これは現実的な危険をもたらす重大な欠陥。
これが通じたのか、修正バージョンのmylo COM-2では、図4の警告が出るように改善された。
それにしても、信じ難い脆弱性だった。ここまで誰でも即座にわかる脆弱性に出くわしたのは、これまでの8年の経験の中で初めてだった。SSLの実装について何のテストも行われていなかったとしか考えられない。
それはともかくとして、この機会に述べておきたいのは、ここ数年のモバイル環境では、この脆弱性は極めて現実的な危険をもたらすという点である。
ここ数年で、携帯型ゲーム機器に無線LAN機能が搭載されるようになり、公衆無線LANサービスの需要が高まっているようである。特に、昨年発売されたiPod touchが、無線LAN経由で閲覧するWebブラウザを搭載し、この使い勝手がたいへん快適であることから、おそらく、これまでになく広い層の人々が、公衆無線LANサービスを使い始めているのではないかと推測する。
実際私も、通勤の際には駅までの徒歩の区間で、livedoor Wirelessを利用して、iPod touchのSafariで、ネット情報のチェックをしている。東京の山手線の沿線とその内側ではほとんどの地域で(ちょっと移動すれば)livedoor Wirelessのアクセスポイントに接続できる状況になっている。
ここで問題となるのが、偽アクセスポイントの危険性である。livedoor Wirelessをはじめとして、現在多くの公衆無線LANサービスにおいて、アクセスポイントへの接続のアクセス制御が、WEPキーによって行われている*1。そして、そのWEPキーは、当該サービスの利用者全員に共通の同一のキーとなっている。サービス加入時にメールでWEPキーの文字列が送られてくるのだが、その文字列でGoogle検索してみると、公開Webページに書き込んでいる人もいるようだ。これは、livedoorだけでなく、マクドナルドなどで使えるBBモバイルポイントなどでも同じである。
このような公衆無線LANの運用方法自体を批判する声もあるだろうが、現実的にはやむを得ない状況のようだ。全員共通のWEPキーはあってないようなものであり、ANY接続を拒否するためと、せいぜい電波法109条の2に基づく法的防御の意味*2くらいしかない。
例えば、livedoor Wirelessを使う場合、無線LANクライアントに、livedoor WirelessのSSIDである「livedoor-web」と、そのWEPキーである「XXXXXXXXXXXXX」(誰でも知ることができるがここでは書かない)を設定することになるのだが、その設定をした無線LANクライアントは、これと同じ名前のSSIDと同じWEPキーが設定された無線LANアクセスポイントであれば、どこのものであろうと自動的に接続してしまう。
そのため、livedoor以外の誰かが自分の所有する無線LANアクセスポイント機器に、「livedoor-web」というSSIDを設定し*3、livedoor Wirelessに加入して知ったWEPキーを設定して、アクセスポイントを設置したら、周辺を行き交う人がiPod touchなどを使ってネットサーフィンすると、そのアクセスポイント経由でインターネットにつながるという事態が生じ得る。
このとき、そのアクセスポイント設置者は、通信内容を盗聴できてしまうだけでなく、偽DNSサーバを設置することで、いわゆるpharming攻撃ができてしまう。つまり、例えば、iPod touch利用者が銀行へアクセスする際に、ブックマークから銀行を選んでアクセスしたとしても、偽アクセスポイントに接続しているため、偽DNSにより偽のIPアドレスへつながってしまうという事態が生じ得る。アドレスバー上では本物の銀行のドメイン名が表示されているのに、実際には偽サイトだということになる。
しかし、本来ならば、ここで役に立つのがSSLである。利用者がパスワード等を入力する際に「安全なWebサイト利用の鉄則」の手順にしたがって行動し、https:// のページであることと、アドレスバーに表示されたドメイン名が知っている本物サイトであることの両方を確認してから入力するようにしていれば、たとえ偽アクセスポイントに接続していても、偽サイトにつながることはない。偽サイト設置者が偽サイト用のサーバ証明書を用意しても、ブラウザが、証明書が不正であることを検出し、オレオレ証明書の警告を出すからだ。
ところが、mylo COM-2は、この不正な証明書の確認を怠っていた。利用者が注意していても、偽サイトにつながってしまう。
オレオレ警告を無視することの危険性については11月25日の日記「オレオレ警告の無視が危険なこれだけの理由」でも書いたが、「SSLってそんなに重要なんですか・・・?」みたいな声が出てくる。「『インターネットは盗聴可能』というけど、実際どこで盗聴できるというの?」という声がよく出てくるのだが、最近の公衆無線LANの普及はまさにその危険が現実になっているのであり、myloはまさに、そのような場で使うことを想定した機器であったはずだ。
Mozillaにせよ、Internet Explorerにせよ、メジャーなWebブラウザは基本的に、米国を中心にした主に英語圏の人たちによって開発されてきた。Operaの事例もあるが、それらは世界の人々からの批判的評価にさらされることで、いくつものセキュリティ上の問題点が改善されてきている。
その一方、携帯電話やゲーム機等、日本企業が独自にWebブラウザを実装している製品が多数ある。日本がコンシューマーエレクトロニクスで世界をリードしてきたがゆえであろう。しかし、そうした製品は、開発者の顔が見えないものばかりだ。セキュリティ上の改善について能動的に耳を傾ける様子がみられない。携帯電話のWebの世界は、秘密保持契約で技術者が縛られ、オープンな議論が許されない閉鎖的な環境に陥っている。そうした製品にはアドレスバーが存在しないものが多く、それでは駄目だということを以前から繰り返し各方面に対して言ってきたろころだが、今のところ改善が見られない。
そして今回の不具合であるわけだが、これは明らかに脆弱性であるので修正されたけれども、その他にもある、セキュリティ上の不備について、どうしたら改善してもらうことができるのだろうか。
例えば、サーバ証明書の内容を確認する機能はどうか。
サーバ証明書の内容を目視確認することが、どんなときに必要とされ、何を確認すればよいのかは、「安全なWebサイト利用の鉄則」の「(A) 初めて訪れたサイトの場合」に説明されている。知らないドメイン名のサイトを訪れたときに、自分の知っている組織が運営しているサイトかどうかを、証明書の発行先の組織名で確認する。
しかしどうだろう、mylo COM-2のサーバ証明書の表示機能では、図5のように、普通の人には何が何だかわからないものが表示される。
何が表示されているかというと、上から順に見ると、最初に表示されているのは中間認証局の証明書だ。最初に中間認証局証明書の発行元であるルート認証局の名前、そしてその発行先が中間認証局の名前、その下を見ていくとやっと最後に、肝心のサーバ証明書の発行先の組織名が現れる。こんな形式で見せられても、どこをみればいいのかさっぱりわからず、誰も見なくなってしまうだろう。
これは、携帯電話でも似たような状況だ。例えば、図6は、ウィルコムのAH-K3001Vのサーバ証明書表示機能の様子だが、図のように、発行者と発行先が逆に表示されるという杜撰さだった。
auのEZwebブラウザはというと、図7のように、データをただ垂れ流しているだけだ。
たいていの機器で、証明書の表示機能はメニューの奥深いところにひっそりと用意されている。「用意しないといけないようだから付けた」といった単純労働で製作されていて、「ユーザに活用してもらうにはどう設計すれば良いか」といった知的な工夫は見られない。
折しも先日、PayPalがSafariからのアクセスを遮断するのではという話が出ていた。後にPayPalによって否定されたようだが、EV-SSLに対応する様子を見せないApple Computer に対する牽制だったのかもしれない。PayPalはフィッシング被害の草分け的存在であり今も被害が盛んなようだ。それだけ深刻だということだろう。
iPod touchのSafariはサーバ証明書の確認機能がないとか、スクロールするとアドレスバーが消えてしまうという話は、10月20日の日記にも書いていたが、先日のUSENIXのUPSEC'08 (Usability, Psycology, and Security) で「iPhish: Phishing Vulnerabilities on Consumer Electronics」という発表があり、同様の指摘がされたようだ。この論文では、Nintendo DSと Wiiも槍玉に挙がっている。
新型myloのアドレスバーはイマイチでがっかりしたと上で書いたが、どんなふうになっているかというと、図8の画面のように、ブラウザのコンテンツ領域の上部に被さる形で巨大なアドレスバーが現れる。
これはいかにも邪魔なもので、「DISP」ボタンを押すことで消せるようになっている。図9の例は、myloの公式コンテンツなのに、アドレスバーが邪魔で「閉じる」ボタンが押せない様子を示している。
こんな設計では皆、アドレスバーを消して常用してしまうだろう。おそらく、誰かの指示でアドレスバーを付けることにはなったものの、ろくに知的な検討をすることもなく「邪魔だから消せるようにしておけばいいや」的な発想で作られたんだろうと推察する。
とりあえず日本のWebブラウザ実装に携わるベンダらは、定期的に勉強会を開くなりして情報共有をしてはいかがだろうか。私はいくらでもアイデアを提供するつもりでいるのだが。例えば、「日本電子認証協議会」は現状では認証局側の集まりのようだが、ブラウザ実装ベンダも参加して、EV-SSLに限らず、ブラウザに欠かせない実装の手引書でも整えたらいいのにと思う。
*1 アクセスポイントへの接続の後、さらにインターネット接続を許すかのアクセス制御として、別途、Webブラウザによるフォーム認証を通じた、接続機器のMACアドレスによる制御が行われている。料金を払っていない非会員が不正に利用しようとしても、WEPキーだけでできるわけではない。(もっとも、別の理由で、非会員による不正利用は可能ではあるのだが、サービス事業者としては、その程度のリスクは無視してでも利便性を提供した方が有利だと判断しているものと思われる。)
*2 電波法102条の2は、暗号化された無線通信について、「暗号通信を傍受した者又は暗号通信を媒介する者であつて当該暗号通信を受信したものが、当該暗号通信の秘密を漏らし、又は窃用する目的で、その内容を復元したときは、一年以下の懲役又は五十万円以下の罰金に処する。」としており、暗号通信の定義として同3項で、「前二項において「暗号通信」とは、通信の当事者(当該通信を媒介する者であつて、その内容を復元する権限を有するものを含む。)以外の者がその内容を復元できないようにするための措置が行われた無線通信をいう。」としている。不正アクセス禁止法におけるパスワードと比較すると、不正アクセス禁止法では、全員共通のパスワードは、利用権者を区別するために付された符号と解釈されずに、識別符号に該当しないと解釈される可能性があるのに対し、電波法109条の2では、「通信の当事者以外の者がその内容を復元できないようにするための措置が行われた無線通信」とされており、全員共通のキーで暗号化する措置が、「通信の当事者以外の者が復元できないようにする措置」と言えるか……というと、アレだが、まあ、違法だということにしておいた方がよいかもしれない。
*3 これ自体に違法性があるかどうか。商標権の侵害?
木曜の夕方から風邪をひいて療養中。昼間寝すぎて寝付けないので日記でも書く。
フィッシングといえばPayPalが発祥の地。実際にどんな状況なのか知るために使ってみるべきだったが、実はこれまで一度もPayPalを使ったことがなかった。2月からWindowsマシンを捨ててMacに乗り換えて以来、シェアウェア料金を支払う場面に出くわすようになった。十年ぶりにKagi.comのシェアウェア支払いサービスを利用したとき、PayPalによる支払いの選択肢があったので、試しに使ってみることにした。
PatPalにアカウントを作成すると何通かのメールがやってくるのだが、これがHTMLメールになっている。このとき、「こんなことやってるからフィッシングにひっかかりやすくするんだよ」と思った。
アカウント作成時に、カードの有効性確認のためだろうか、200円が引き落とされ、後でカード明細の載っている番号を入力すると返金されるという仕組みになっていた。このとき、「こういうややこしい手続きが正規サイトにあるとフィッシングに騙されやすくなるんだよな」と思った。
そしてその翌日、こんなメールが来た。
典型的なPayPalフィッシングだが、これにひっかかりそうになった。いや、もちろんひっかかりはしないのだが、一瞬とはいえ「げげ、なんかトラブルが起きたのかな」と思ってしまった。
PayPalフィッシングのメールなんぞ飽きるほど見てきたはずだが、ここでそう思ってしまったのは、実際にPayPalにアカウントを作成した翌日だったからだ。しかも、そのタイミングで、spamフィルタをすり抜けてきたことが大きい。
Macに乗り換えて以来、Mac OS X 10.5標準のメールソフト「Mail.app」を使用していて、標準搭載されているspamフィルタ機能を利用していた。フィッシングのメールもspam扱いで自動的にspamフォルダに振り分けられていたため、PalPalフィッシングのメールを目にすることはない状態になっていた。
ところが、PayPalにアカウントを作成した途端、spamフィルタをすり抜けて、PayPalフィッシングのメールを目にしたわけだ。この原因として、本物のPayPalからの連絡メールを受信したことで、spamフィルタのspam判定基準が緩まったためではないかと考えられる。
よく見てみれば、PayPalに連絡先として登録したメールアドレスと、spamが大量にやってくる公開アドレス(この日記の連絡先アドレス)とは別にしているわけで、今回も、フィッシングメールは公開アドレスの方に来ていた。どうやら、Mail.appのspamフィルタの学習は、メールアカウントをまたがって影響してしまうようだ。
私がPayPalにアカウントを作成したことが察知されてspamが送られてくるようになったわけではないのだから、公開アドレスの方には過去にもPayPalフィッシングのメールを受信しているはずだ。spamフォルダの中身を確認してみたところ、やはり、以前から毎日のようにPayPalフィッシングのメールを受信していた。
「なるほど、これは騙されてしまう人が出るのもうなづける」と思った。
試しに偽サイトを訪れてみると、本物と同一の画面が、「paypal.user-updates.com」というサイトで表示された(図3)。あり得ないIDとパスワードを入れてみたところ、認証が成功したふりをして(図4)、カード番号やらを入力させる画面が現れた(図5)。
ちょうどこの日、勤務先の本業で「パスワード相互認証プロトコルの技術評価用ソフトウェアを公開」というプレスリリースを出した。フィッシングを防止しようとするものなのだが、これを提案すると必ず出てくるのが「そんなので全てのフィッシングが防げるわけがない」という声だ。
たしかに、何の心得もない人を救うことはできないが、それはいかなる技術をもってしてもそうだろう。
基本はドメイン名を確認することだが、どんなにネットに慣れている人でも、焦っているときや偶然のタイミングでは確認をミスしてしまうこともあるだろう。実際、Ruby開発者のまつもとゆきひろ氏や、アルファブロガーの池田信夫氏でさえ、フィッシングにひっかかったことを告白している。
PayPalからHTMLメールが届いていて、うっとうしいので今後テキストメールに変更しようと操作したら、まんまとフィッシングに引っかかってしまった。
慌ててパスワードを変更して亊無きを得たが、危なかった。慌ててる私を見て妻が「専門家でも引っかかるのね」。(以下略)
間抜けなことに、フィッシングに引っかかってパスワードを盗まれてしまった。amazon@teamservice.comというアドレスから(略)というメールが来て、ちょっと変だなと思いつつ、そのURLをクリックすると、図のようにAmazon.comそっくりの画面が出てくる。ここでアドレスとパスワードを入れると、クレジットカードの番号を入力する画面が出てくる。(以下略)
最近では、大規模なspamで誘うフィッシングは、ブラウザのフィッシングサイト検出機能で防がれるようになった。図3のサイトも、私がメールに気づいた時点では、Internet Explorer 7でアクセスすると図6のようになったし、Firefoxでアクセスすると図7のようになった。
しかし、これらは誰かが先に「ここはフィッシングサイトだ」と報告してくれたからこのようにブロックできたわけで、報告される前にひっかかる何人かには被害が出ているだろうし、「スピアフィッシング」などと呼ばれる、ごくわずかの人を狙って誘うケースでは、これらの仕組みではブロックされないだろう。
実際、日本国内のフィッシング発生状況を見ると、国家公安委員会らの発表「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況について」によれば、平成19年度の不正アクセス犯罪の検挙数1,438件のうち「フィッシングサイトを開設して識別符号を入手したもの」が1,157件もあるというのだが、そのわりには、日本向けのフィッシングサイトが登場したという話をめったに聞かない。表沙汰にならないのは、ごく少数の相手を狙って偽サイトに誘う行為が横行しているためだろう。
以前にも書いたように、自分が知っているサイトであることを確認する方法は、ドメイン名を目視確認する方法の他にも、「信頼済みサイトゾーン」を活用する方法や、「petname tool」を使う方法などがあるが、それらのように準備として別途ローカルに確認済みサイトを登録する作業を必要とせずに、パスワードの入力によって確認されるというのが、「HTTP Mutualアクセス認証」という新たに提案しているプロトコルだ。
これが普及すれば、Webアプリケーションのログイン機構を自前で設計・実装しなくて済むようになり、それに起因する脆弱性も排除されるという意義もある。(CSRFは従来通り対策が必要だが。)Basic認証やDigest認証に並ぶ第3のHTTP標準の認証方式となるよう、ブラウザベンダに働きかけていきたい。
以前にも書いたように本業のことはあまりここには書かないポリシーなのでこのくらいにして、寝るとしよう。ゲホゲホ。