<前の日記(2008年03月15日) 次の日記(2008年04月26日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1178   昨日: 2328

2008年04月23日

新型myloのオレオレ証明書を検出しない脆弱性がどれだけ危険か

mylo COM-2の欠陥

昨年7月1日の日記「アドレスバー百景 その1」で旧型myloにアドレスバーがない件について書いていた。今年、そのmyloに新型「COM-2」が発売されたというので、アドレスバーがどうなっているか確かめるため、3月に購入した。

3月某日、myloが家に届いた。箱を開けて取り出し電源を投入。Webブラウザを起動して早速アドレスバーを調べてみると、概ねPSPと同様の方式になっていた。あまり良い設計ではなく、がっかりした。

次に、SSL接続時のオレオレ証明書の警告はどのようになっているだろうかと、オレオレ証明書で運用されているサイトにアクセスしてみた。

図1: オレオレ証明書で運用されている https:// ページにアクセスしようとした様子

まず、https:// ページに入ろうとしていることを示す「セキュリティ保護がされているページに移ります」というお知らせ画面が出た(これは正規のSSLサイトでも表示される)。ここで「OK」ボタンを押すと……

図2: 何の警告もなくオレオレSSLページが表示された様子

なんと、何の警告もなく、ページが表示されてしまった。

念のため証明書の内容を確認してみると……

図3: 自己署名の証明書であることを確認した様子

自己署名の証明書になっていた。

これは明らかにセキュリティ脆弱性だ。この種類の脆弱性(ブラウザが証明書を検証しない)は、伏せておくよりも早く事実を公表して利用者に注意を促した方がよいという考え方もあり、すぐに日記に書こうかとも考えたが、このケースではIPA、JPCERT/CCを通した方が修正が早く行われるのではないかと考え、IPAの脆弱性届出窓口に通報した。

この届け出は3月27日に受理された。そして本日、JVNで公表となった。修正版が提供されているので、利用者はアップデートで対応できる。

脆弱性情報の届け出では、意見として次のように書いておいた。

盗聴やなりすましの危険性がある異常事態であることを明示して警告し、ボタンを押したくらいでは容易に接続できないような、ユーザーインターフェイスにするべき。

特に、公衆無線LANでの使用を前提としているこの製品では、これは現実的な危険をもたらす重大な欠陥。

これが通じたのか、修正バージョンのmylo COM-2では、図4の警告が出るように改善された。

図4: 修正版mylo COM-2でのオレオレ証明書の警告

それにしても、信じ難い脆弱性だった。ここまで誰でも即座にわかる脆弱性に出くわしたのは、これまでの8年の経験の中で初めてだった。SSLの実装について何のテストも行われていなかったとしか考えられない。

それはともかくとして、この機会に述べておきたいのは、ここ数年のモバイル環境では、この脆弱性は極めて現実的な危険をもたらすという点である。

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はまさに、そのような場で使うことを想定した機器であったはずだ。

日本のWebブラウザ実装者の怠慢

Mozillaにせよ、Internet Explorerにせよ、メジャーなWebブラウザは基本的に、米国を中心にした主に英語圏の人たちによって開発されてきた。Operaの事例もあるが、それらは世界の人々からの批判的評価にさらされることで、いくつものセキュリティ上の問題点が改善されてきている。

その一方、携帯電話やゲーム機等、日本企業が独自にWebブラウザを実装している製品が多数ある。日本がコンシューマーエレクトロニクスで世界をリードしてきたがゆえであろう。しかし、そうした製品は、開発者の顔が見えないものばかりだ。セキュリティ上の改善について能動的に耳を傾ける様子がみられない。携帯電話のWebの世界は、秘密保持契約で技術者が縛られ、オープンな議論が許されない閉鎖的な環境に陥っている。そうした製品にはアドレスバーが存在しないものが多く、それでは駄目だということを以前から繰り返し各方面に対して言ってきたろころだが、今のところ改善が見られない。

そして今回の不具合であるわけだが、これは明らかに脆弱性であるので修正されたけれども、その他にもある、セキュリティ上の不備について、どうしたら改善してもらうことができるのだろうか。

例えば、サーバ証明書の内容を確認する機能はどうか。

サーバ証明書の内容を目視確認することが、どんなときに必要とされ、何を確認すればよいのかは、「安全なWebサイト利用の鉄則」の「(A) 初めて訪れたサイトの場合」に説明されている。知らないドメイン名のサイトを訪れたときに、自分の知っている組織が運営しているサイトかどうかを、証明書の発行先の組織名で確認する。

しかしどうだろう、mylo COM-2のサーバ証明書の表示機能では、図5のように、普通の人には何が何だかわからないものが表示される。

図5: mylo COM-2のサーバ証明書表示機能の様子

何が表示されているかというと、上から順に見ると、最初に表示されているのは中間認証局の証明書だ。最初に中間認証局証明書の発行元であるルート認証局の名前、そしてその発行先が中間認証局の名前、その下を見ていくとやっと最後に、肝心のサーバ証明書の発行先の組織名が現れる。こんな形式で見せられても、どこをみればいいのかさっぱりわからず、誰も見なくなってしまうだろう。

これは、携帯電話でも似たような状況だ。例えば、図6は、ウィルコムのAH-K3001Vのサーバ証明書表示機能の様子だが、図のように、発行者と発行先が逆に表示されるという杜撰さだった。

図6: AH-K3001Vのサーバ証明書表示機能の様子

auのEZwebブラウザはというと、図7のように、データをただ垂れ流しているだけだ。

図7: EZwebブラウザのサーバ証明書表示機能の様子

たいていの機器で、証明書の表示機能はメニューの奥深いところにひっそりと用意されている。「用意しないといけないようだから付けた」といった単純労働で製作されていて、「ユーザに活用してもらうにはどう設計すれば良いか」といった知的な工夫は見られない。

折しも先日、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の画面のように、ブラウザのコンテンツ領域の上部に被さる形で巨大なアドレスバーが現れる。

図8: mylo COM-2のアドレスバー

これはいかにも邪魔なもので、「DISP」ボタンを押すことで消せるようになっている。図9の例は、myloの公式コンテンツなのに、アドレスバーが邪魔で「閉じる」ボタンが押せない様子を示している。

図9: アドレスバーが邪魔になっている様子

こんな設計では皆、アドレスバーを消して常用してしまうだろう。おそらく、誰かの指示でアドレスバーを付けることにはなったものの、ろくに知的な検討をすることもなく「邪魔だから消せるようにしておけばいいや」的な発想で作られたんだろうと推察する。

とりあえず日本のWebブラウザ実装に携わるベンダらは、定期的に勉強会を開くなりして情報共有をしてはいかがだろうか。私はいくらでもアイデアを提供するつもりでいるのだが。例えば、「日本電子認証協議会」は現状では認証局側の集まりのようだが、ブラウザ実装ベンダも参加して、EV-SSLに限らず、ブラウザに欠かせない実装の手引書でも整えたらいいのにと思う。

*1 アクセスポイントへの接続の後、さらにインターネット接続を許すかのアクセス制御として、別途、Webブラウザによるフォーム認証を通じた、接続機器のMACアドレスによる制御が行われている。料金を払っていない非会員が不正に利用しようとしても、WEPキーだけでできるわけではない。(もっとも、別の理由で、非会員による不正利用は可能ではあるのだが、サービス事業者としては、その程度のリスクは無視してでも利便性を提供した方が有利だと判断しているものと思われる。)

*2 電波法102条の2は、暗号化された無線通信について、「暗号通信を傍受した者又は暗号通信を媒介する者であつて当該暗号通信を受信したものが、当該暗号通信の秘密を漏らし、又は窃用する目的で、その内容を復元したときは、一年以下の懲役又は五十万円以下の罰金に処する。」としており、暗号通信の定義として同3項で、「前二項において「暗号通信」とは、通信の当事者(当該通信を媒介する者であつて、その内容を復元する権限を有するものを含む。)以外の者がその内容を復元できないようにするための措置が行われた無線通信をいう。」としている。不正アクセス禁止法におけるパスワードと比較すると、不正アクセス禁止法では、全員共通のパスワードは、利用権者を区別するために付された符号と解釈されずに、識別符号に該当しないと解釈される可能性があるのに対し、電波法109条の2では、「通信の当事者以外の者がその内容を復元できないようにするための措置が行われた無線通信」とされており、全員共通のキーで暗号化する措置が、「通信の当事者以外の者が復元できないようにする措置」と言えるか……というと、アレだが、まあ、違法だということにしておいた方がよいかもしれない。

*3 これ自体に違法性があるかどうか。商標権の侵害?

検索

<前の日記(2008年03月15日) 次の日記(2008年04月26日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2008年03月15日) 次の日記(2008年04月26日)> 最新 編集