最新 追記

高木浩光@自宅の日記

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

2007年10月07日

APWGに行ってきた

APWGeCrime'07に行ってきた。

FSTCの「Better Mutual Authenticationプログラム」が言う「mutual authentication」の意味(定義)が気になった。

終了後、とあるお方のご厚意で、とある方にCMUとその周辺をご案内いただいた。(ありがとうございました。)

University of PittsburghのCathedral of Learning

展望室から見たCMU。左端の工事現場は建設中のゲイツセンター。手前は10年前*1に立ち寄った思い出のあるCarnegie Museum of Natural History

CyLabのある建物を出たところから見たゲイツセンター建設現場。

なぜかASIMOのようなシルエットが……。http://gatescenter.blog.cs.cmu.edu/というURLが書かれていた。

翌日、次の予定のためSan Franciscoへ移動。

BARTが2003年に空港まで延伸していたというので、電車でダウンタウンへ。

遅い昼飯にとFisherman's Wharfへ行ったら、なんか人がめちゃくちゃいっぱいで。航空ショーをやっていた。これか。毎年やってるのね。

戦闘機よりとにかく飯。クラムチャウダーが美味い。アメリカで食べるクラムチャウダーの味(濃い目な感じ)はどうやって出すんだろう? ググったらいろいろ出た。今度作ってみよう。

「Phisherman's Wharf」という言葉を思いついたが、まだ誰も使っていないようだ。何かに使えないかな。

宿に戻って仕事。

PlaceEngineで位置検索してみると(やはり)特定できず。

「位置を教える」の機能は使えた。それ以降、住所は出ないものの地図は出せる。

*1 調べたら11年前だった。

本日のリンク元 TrackBacks(18)

2007年10月09日

明日帰国

この日付は日本時間。今日で仕事は終わり。明日帰る。

昨日、ホテルの近くに日本人街があるというので、夕飯に行ってきた。中華街にあるような門の日本版らしきものが……。

日本人街入り口の写真 紀伊国屋書店サンフランシスコ店の入り口

紀伊国屋書店サンフランシスコ店があった。改装したのか拡張したのか、店が準備途中のままオープンしていた。半分くらいの棚にはまだ本が置かれておらず、何を置く予定かを示す紙のメモが貼られていた。 そして、奥の壁一列には全部本が納められており、のきなみこんな紙が……。

YAOI やおい

なにか間違っているような……。

今日は、仕事が全部終わった後、夕食にGoogleの桃井さん*1を訪ねた。約束の時間より早く着いたので、待ち時間にPlaceEngineを使ってみると……、


おお!ズバリ5メートルの誤差で位置が特定された。既に誰かが位置を登録していたようだ。

帰り際、桃井さんにMountain View駅まで送って頂いた。このあたりは今ラーメンブームなのだとか。

今ググったら、Mountain View駅の近くに「SHABUWAY」という店があるらしい。評判はよさげ。また訪れるときがあれば行ってみたい。

*1 Netscape/AOLにいらした桃井さんはGoogleに移っていらした。

本日のリンク元 TrackBacks(6)

2007年10月20日

アドレスバー百景 その2 「iPod Touch」的UIの活用を考える

産業音楽の呪縛から逃れて久しかったが、ネットラジオLive365.comのチャンネルのひとつ「arabicmusic.com」の放送を聴いてから、このところすっかり「al-Jeel」というジャンルの音楽の虜になっていた。ネットラジオで表示される曲名で検索して、どこで買えるか探しまくっていた*1。ついにはiPod shuffleを買い、そして先日iPod touchを買った。

図1: iPod touchでal-Jeelを聴く

今更だが、iPod touchの操作性はすばらしい。特に、自由自在のズーム機能を活かしたSafariの操作性はすばらしく*2、もうEM・ONEでブラウズする気がしなくなった。駅まで歩く間のブラウズのためにlivedoor Wirelessも契約した。

しかし、セキュリティはどうなっているのか。Safariの画面をスクロールさせるとアドレスバーまで一緒に上へ消え去ってしまうことは、9月28日の水無月ばけらのえび日記に書かれていた。

フラグメントIDつきのリンクで来た場合、アドレスバーが表示されないことになるかも……。

「iPod touch の Safari のアドレスバー」, 水無月ばけらのえび日記, 2007年9月28日

図2: iPod touchのSafariでアドレスバーまで一緒にスクロールしてしまう様子

たしかにそうなる。ただ、アクセス中はアドレスバーがプログレスバーの役割も果たすため、ロードが終了するまではアドレスバーは上部に居座る。開発側としては「この間にURLのドメインを目視確認しておけ」ということなのかもしれないが、それで十分ということはないだろう。

また、フラグメントID付きのリンク(「#p01」などの指定付きのリンク)のジャンプ先をロードし終えた時点でURLを確認したければ、画面上部のバー(時計が表示されている部分)をタップすれば一番上までササっとスクロールしてくれるので、すぐに確認はできる。しかし元の位置に戻る機能はないようなので、普通の人は、上に戻りたくないと思うようになってしまうだろう。

どうにかならないものか。

ここで気がついたのだが、入力の際にアドレスバーを出現させるようにしてはどうだろうか。

iPod touch版Safariでは、入力欄がタップされると、画面をその部分にズームインして、画面下半分にキーボードを出すようになっている(図3)。

図3: 入力欄のタップでそこにズームインして表示される様子

この挙動がスムーズなズームとスクロールで直感的にわかり易く表現されていてすばらしいのだが、ここで、その特長を活かして、アドレスバーもひょっこり現れるようにしてはどうだろうか。画面に余裕もあるようだし。

アドレスバーの確認がどういうタイミングで必要となるかは、安全なWebサイト利用の鉄則にもあるように、重要な情報を入力する直前であるのだから*3、今まさに入力しようとしている図3右の画面で、(偽装不可能な形で)アドレスバーがひょっこり現れれば、確認もしやすいし*4、確認が促されるという効果もあるかもしれない。

これはすぐにも使える現実解なんじゃ?と思ったが、残念ながら、本体を横向きにしているときに無理があるようだ。ズームした画面に余裕がない(図4)。

図4: 横向きで入力欄にズームしたときの様子

うーん、どうにかならないものか。

じゃあ、キーボードの上部の余白部分にURL(あるいはホスト名やドメイン名)を表示するとか? いまいちではある。

ところで、そうすると、このアイデアは携帯電話の現実解にもなるかもしれない。携帯電話にアドレスバーがないことの危険性はこれまでに何度も書いてきたが、開発側に言わせれば、画面が狭くてそれどころじゃないということだった(直接聞いたわけではないが)。しかし、携帯電話のブラウザでも、入力時に特別な動きをするものがある。EZwebのブラウザでは(私の使っている機種では)図5のように、入力欄でボタンを押すと入力専用の画面(右の写真)に移行するようになっている。この(そっけない)画面に、どのURLのページに入力しようとしているのかを表示してもよいのではないか*5

図5: EZwebのブラウザにおける文字列入力動作

さらに言えば、PSPについても同じように改良できるかもしれない。7月1日の日記「アドレスバー百景 その1」では、PSPは「△」ボタンを押したときにしかアドレスバーが現れないのがいまいちだと書いたが、入力欄にカーソルを合わせたとき(図6)にもアドレスバーが現れる(偽装不可能な形で*6)ようになっていてもいいのではないか。

図6: PSPにおける入力欄の様子

日本の開発者には*7「常時表示しておくのは邪魔だ」という主張がどうしても譲れないのだとしても、このように入力の際にだけ表示するのは受容できるはずのデザインではなかろうか。

iPod touch版Safariにはサーバ証明書の閲覧機能がない?

サーバ証明書の閲覧機能は、安全なWebサイト利用の鉄則にもあるように、初めてサイトを訪れた利用者にとって欠かせない機能であり、各ブラウザが当然に備えている機能で、たいていは錠前アイコンで示される。

iPod touch版Safariでは、https:// のページにアクセスすると図7のように、アドレスバーの中に錠前アイコンが表示される。これは良い。(Mac OS版Safariが、わかりにくい場所にひっそり表示するものになっているのとは対照的に。)

図7: iPod touch版SafariにおけるSSL通信時の錠前アイコン

ところが、この錠前アイコンをタップしても何も起きない。もしかして、サーバ証明書を表示する機能が存在しない?? もしそうなら英語圏で既に問題にされてそうな話だが……。

*1 アラビア語の英字表記が揺れていて探すのに苦労した。CDに印刷されている曲名とWikipediaの記載が違ってたりする。現在星5つの曲:

歌手アルバム入手元感想
Nancy AjramAh W NossAh W NossiTunes Store, CD大ヒット曲と知ってなるほど
Nancy AjramLawn OyounakAh W NossCD今の一番のお気に入り
Nancy AjramMoegabaYa Tabtab...Wa DallaaCD萌え?
Nancy AjramAshtiki MinnoYa Tabtab...Wa DallaaCDなんだか懐かしい
Nawal Al-ZoghbiKhaletny AhebakEineik KaddabeenCD冒頭と終わりのリズムが印象的
Nawal Al-ZoghbiKhaleek LiyaEineik KaddabeenCD間奏がグッと来る
Najwa KaramEdhak Lil DounyaSaharniiTunes Store伝統的?な曲の終わり方に痺れる
Najwa KaramMa'houra Alayk SaharniiTunes Store伝統的?な冒頭、終わり方に超痺れる
Diana HaddadBeshweeshDiana 2006CDリズムが心地よい
Myriam FaresZai ElsukarNadiniCD声がかわいい
Wael KfouryQalbe MeshtaqQarabe LayaiTunes Store冒頭がたまらん
Amr DiabWehkaitak EihKammel KalamakiTunes Storeこれぞal-Jeelという?ポコチャカリズム
Amr DiabMa'ak BegadKammel KalamakiTunes Storeこれぞal-Jeelという?ポコチャカリズム

湾岸戦争のころテレビから流れてきたアルジャジーラのジングルがかっこよくて忘れられず、録画しておかなかったことを悔んでいたのだが、その望みが少し充足された感じ。

*2 複数ウィンドウ機能がバグっているようだが。

*3 偽サイトでないかの確認は、入力以外のときにも必要となる場合はある。表示された情報が偽でないかアドレスバーで確認する必要が生ずることもあるだろう。それについては、画面上部のタップによるトップまでのスクロール機能(とロード時のアドレス表示)でまあ、どうにか許容可能なリスクに収まっていると言えるかもしれない。

*4 ついでに、ホスト名だけ切り出して表示するとか、(Firefox機能拡張の「Locationbar2」のように)ドメイン名部分だけ強調表示するとか、そういった補助機能があるとよいのだが。

*5 ついでに入力欄のタイトルを表示する(アドレス表示とは別扱いで)のも別の意味で便利になるのでは?

*6 このままでは、画面上のどこにも信頼できる部分(ブラウザのchrome領域)がないので、無理だが。

*7 (日本の開発者にカスタマイズされていない)WindowsやOperaではアドレスバーの設置が当然になっている。

本日のリンク元 TrackBacks(13)

2007年10月21日

デイリーポータルZ 記者の家を探しに行く

5月27日の日記「PlaceEngineのプライバシー懸念を考える」では次のように書いた。

つまり、家庭の無線LANアクセスポイントのMACアドレスを誰かに知られることは、住所を知られることに等しい。そのような事態をPlaceEngineサービス(および類似のサービス)が新たに作り出したことになる。

「MACアドレスは個人を特定するものではない」と言えるだろうか?もし、別のネットサービスで、何らかの目的で家庭の無線LANのMACアドレスを登録して使うサービスが始まったとする。そのサービスもまた、「MACアドレスから個人が特定されることはありません」と主張するだろう。このとき、PlaceEngineとこのサービスの両者が存在することによって、わからないはずの住所が特定されてしまう事態が起きてくる。

PlaceEngineなどのサービスが存在する現状、家庭の無線LANのMACアドレスは秘密にしなければならなくなった。

ではどういう状況でMACアドレスを知られ得るのかだが、8月18日の日記ではストーカーから逃れて転居する状況を想定した。他に崎山伸夫氏からはIPv6が普及した状況を想定しての検討をトラックバックで頂いている。IPv6は未来の話だとして、現状でも次のケースがあることにその後気づいた。

iPod touchや携帯ゲーム機器を外で歩きながら使っている人ならお気づきのように、巷の無線LANアクセスポイントのいくつかは、SSIDにMACアドレスっぽい12桁の16進数を割り当てているものがある。これは何のアドレスだろうか。

たとえばBUFFALO製無線LANアクセスポイントのある機種の説明にはこんな記述がある。

WER-AMG54は、本体に設定されているLAN MACアドレス(SSID)が本体底面に記載のSSID初期値と異なります。AOSSを使わずに無線接続する際は、本体底面に記載されているSSID初期値の末尾 ”_G” を除いた12文字のSSIDに接続してください。

製品名・製造番号・MACアドレス・ESSID・設定初期化ボタンを確認する方法, 株式会社バッファロー

また、BUFFALOの「QA番号:BUF3491」には、機種ごとのSSID初期値の一覧表があり、次などの記述がある。

「000740」で始まる12桁のLAN MACアドレスの値
「000D0B」で始まる12桁のLAN MACアドレスの値
11a = 「000D0B」で始まる12桁の値 + 「 _A 」
11g = 「000D0B」で始まる12桁の値 + 「 _G 」
「000740」、「000D0B」で始まる12桁の有線MACアドレスの値
「000740」、「000D0B」で始まる12桁の有線MACアドレス(WiredMAC)の値
「004026」で始まるMACアドレスの下6桁に”GROUP”をつけた値
エアステーションのLAN側の有線MACアドレスの値

「LAN MACアドレス」と「有線MACアドレス」の違いがいまいちわからないが、どうやら、無線側のMACアドレスではなく、有線LAN側のMACアドレスをSSIDの初期設定としたものが多いようだ。PlaceEngineで位置を調べるには、有線LAN側ではなく、無線側のMACアドレスが必要である。

ところが、どうも、有線LAN側MACアドレスと無線側MACアドレスを連番で割り当てている機種が少なくないようなのだ。

図1は、夏休みに東海道新幹線移動中にNetwork Stumblerで検出した数千件のアクセスポイントについて、SSIDで並べ替えて表示した様子である。

図1: 適当に集めたアクセスポイント情報をSSID順に表示した様子 その1
(電波法59条に配慮し一部墨塗り)

Coregaの一部の機種では、無線側MACアドレスと1番違いの値がSSIDとして設定されれていることがわかる。おそらく有線LAN側のMACアドレス(あるいはWAN側のMACアドレス)をSSIDとして使っているのだろう。別のメーカーのものも図2の通りで、全く異なるアドレスを用いているものもあるが、1番違いのアドレスを用いているものがあり、同一アドレスを用いているものも見られる。

図2: 適当に集めたアクセスポイント情報をSSID順に表示した様子 その2
(電波法59条に配慮し一部墨塗り)

また、(これはわりと知られていることかもしれないが)ソニーのLocationFreeベースステーションは、無線側のMACアドレスをそのままSSIDに含めている(図3)。

図3: 適当に集めたアクセスポイント情報をSSID順に表示した様子 その3
(電波法59条に配慮し一部墨塗り)

ここで思い出したのが、2月にデイリーポータルZに掲載されていた以下の記事である。

この「デイリーポータルZ」というサイトは、誰もやらない実験をすることで人気を博しているサイトなのだが、この回に限っては、いまどき誰でもやったことのあるであろう、無線LANアクセスポイントの収集という平凡な実験をネタにしていた。この記事の著者(および編集者)からすれば、他で見たことのない実験なので、ユニークと思ったのかもしれないが、他の誰もこういうことをしないのは、無線LANアクセスポイントの情報をそのまま公表する行為が電波法59条に抵触する可能性があると心配されているからだろう。

(秘密の保護)

第59条 何人も法律に別段の定めがある場合を除くほか、特定の相手方に対して行われる無線通信(電気通信事業法第4条第1項又は第164条第2項の通信であるものを除く。第109条並びに第109条の2第2項及び第3項において同じ。)を傍受してその存在若しくは内容を漏らし、又はこれを窃用してはならない

電波法

傍受できてしまうこと自体はしかたないが、傍受して存在を漏らす行為、傍受して内容を漏らす行為、傍受して窃用する行為それぞれが禁じられている。どこの場所にこんなSSIDのアクセスポイントがあるといった情報を公表するのは、存在を漏らす行為にあたるおそれがあるのではないか。

この記事は、以下の引用部のように、能天気にも自分の家の近くで得たアクセスポイントのSSIDをモザイクもかけずにそのまま掲載している。(赤の墨消しは引用時による。)

  • フェティッシュの火曜日 無線LANを探しに行く, @nifty デイリーポータルZ, 2007年2月6日

    見つかりました。3つです。このうち一つは僕の家の無線LANです。なので、僕の家の周りで無線LANを使ってる人が、僕のほかに二人ということになります。

    さて、家から80mくらい離れてみました。さっき無線LANを検索した場所がまだ視界にあるくらい近いのですが、検索してみるとまた新たに2つの無線LANを見つけました。

5つ示されているSSIDのうち2つは、MACアドレスのようだ。もしこれが、無線側MACアドレスそのものであったり連番であるなら、PlaceEngineを使って著者の家を探し当てることができてしまうだろう。

というわけで、実際にやってみることにした。

まず、無線側のMACアドレスを変更できるアクセスポイントを用意するわけだが、たとえば、次の製品(かなり広く普及していると思われる)では普通にそれが可能になっている。

図4のように、普通に設定でMACアドレスを変更できるようになっている。

図4: MACアドレスを変更する機能の様子

このアクセスポイントデバイスと、これを受信するための別の無線LANクライアントデバイスをPCに接続し、これらをアルミホイルで包んで簡易電波暗室とし(図5)、環境に存在する他のアクセスポイントを受信しないようにした。

図5: アクセスポイントとクライアントを簡易電波暗室に入れる

手始めに、BroadBand Watchの記事に最近掲載されたこのスライドに映し出されているMACアドレス*1をターゲットにして試した。図6のように、変更した指定のMACアドレスのアクセスポイント1個だけが観測される状態を作り出したところで、PlaceEngineを起動して位置を測定してみると、そのスライドに書かれている通り、たしかに淡路町駅交差点の位置が示された。本当にこの方法で位置を検索できてしまうことが確認された。

図6: 指定のMACアドレスの1個のアクセスポイントのみを受信する様子

というわけで、早速、デイリーポータルZの記事で著者が自宅前だとして公表しているSSIDをアドレスとして用い、また、その前後1番違いのアドレスそれぞれを用いて検索してみた。

図7: PlaceEngineに登録されていないMACアドレスだった様子

結果、掲載されている2つのSSIDのどちらについても、位置は特定できなかった(図7)。どうやら、記者の家の地域はまだPlaceEngineのデータベースに登録されていないようだ。(あるいは、これら2つのSSIDが無線側MACアドレスとは無関係の値である可能性もある。)

そこで次に、同じ記事の後半に記載されている、「アルタがある一角をグルっと一周しただけで12個も見つかりました」と説明された写真に掲載されているSSIDで試してみたところ、図8のように、新宿アルタ前の位置が特定された。

図8: SSIDから新宿アルタ前を特定できた様子

というわけで、自宅を特定されたくない状況では、MACアドレスを秘密にすることが求められるだけでなく、SSIDも同時に秘密にすることに注意を払う必要もあるということになる。あるいは、無線LANアクセスポイントは、SSIDをMACアドレスと無関係の文字列に設定変更して使うのがよい。

近頃はブログ等で、自宅の無線LAN設定の様子を写真で載せている人が少なくない。「SSIDがバレたところで、それで不正アクセス可能になるわけじゃないし」という思考から、SSIDにモザイクをかけずに掲載することがあるかもしれないが、PlaceEngineというサービスが存在する今となっては、各自、SSIDがMACアドレスになっていないかに注意して掲載する必要がある。

特に、LocationFreeを自宅に設置している人は注意が必要だ。たとえば、BoradBand Watchの「外出先からPSPやPCで自宅のテレビが見られる画期的な製品ソニーの新型ロケーションフリー「LF-PK1」」という記事は、LocationFreeベースステーション本体の写真を掲載しているが、この写真には(初期設定の)SSIDが記載されたシールが写っており、誰でも読み取ることができてしまう。

この個体が今どこに設置されているのかは定かでない(インプレス社内にあるのかもしれないし、他人の手に渡っている可能性もある)が、この値をMACアドレスとしてPlaceEngine検索してみたところ、マンションらしき場所が示された(図9)。

図9: SSIDからマンションらしき場所が特定された様子

さて、今回は、所期の目標であった「デイリーポータルZ 記者の家を探しに行く」を実現できなかったわけだが、今後、PlaceEngineの利用者が増え、登録位置情報が自動的に充実していくにつれ、いつの日か記者の家の地域が検索可能になる可能性がある。

ところで、実は、この記者の個人ブログによると、9月に転居したとのことなので、2月の記事の場所にはもう住んでいないようだ。

だが、逆に、これによって転居先を特定できる可能性もある。記事中で、

見つかりました。3つです。このうち一つは僕の家の無線LANです。なので、僕の家の周りで無線LANを使ってる人が、僕のほかに二人ということになります。

とされている「僕の家の無線LAN」が、もし、上で試したMACアドレスらしきもののことを指しているのなら、今後、転居先の場所が検索可能になる可能性がある。

もっとも、ブログの書きぶりからして、この方はあまり家の場所を隠すつもりがないようなので、いらぬ心配かもしれない。

ユビキタス社会の歩き方(3) 無線LANのSSIDを不用意に明かさない

上に書いたとおり、「ユビキタス社会の歩き方」として「無線LANのSSIDを不用意に明かさない」よう留意しなければならい状況が生じ始めている。

あるいは、もしかすると、そうではなく、「PlaceEngineのようなサービスは社会にとって危険であり、存在しないべきである」という世論*2にたどり着く可能性もある。どちらが適切なのか、私にはまだわからない。いずれにせよ、まずこの事実が広く知られなければ、正しく判断されることはないだろう。

*1 こういうふうに、他人のアクセスポイントのMACアドレスを公表してしまうことに無頓着なのは、いかがなものかと思う。

*2 1990年代に、個人宅の電話番号帳をネットで検索できるサービスが存在した時期も短期間存在したが、現在ではそのようなサービスは存在しない。

本日のリンク元 TrackBacks(100)

2007年10月27日

自分の無線LANがPlaceEngineに登録されていないか確認する方法

前回の日記に対するリンク元などを見てまわったところ、「PlaceEngineは使いたいが自分のアクセスポイントは登録したくない」といった声があった。さて、「PlaceEngineを使いつつも登録しないでいる」ことは可能なのだろうか。

PlaceEngineには「位置を教える」という機能があるが、このボタン(図1)を押さないようにしていれば登録されずに済むかというと、そうではない。

図1: PlaceEngineの「位置を教える」ボタン

このボタンは、PlaceEngineの取扱説明書よると、次の場合に使うものとして用意されている。

まだ PlaceEngine サービスエリアに含まれない場所で「現在地を取得」ボタンをクリックすると、現在地取得に失敗します。この場合、地図の下の「位置を教える」ボタンをクリックし、(略)

PlaceEngine MAP サイトで現在地を表示しても、推定された現在地が正しく地図上に表示されない場合は、結果を修正して正しい情報を PlaceEngine サーバーに教えて頂くことが可能です。この場合、地図の下の「位置を教える」ボタンをクリックし、(略)

自分の家で(近くで)このボタンを押せば、もちろん、家のアクセスポイントが登録されてしまうわけだが、このボタンを押さなくても、PlaceEngineで位置情報を得るだけ(「現在地を取得」ボタンを押すだけ)でも、家のアクセスポイントはPlaceEngineサーバに登録されてしまう。このことは、PlaceEngineの論文で次のように説明されている。

  • 暦本純一, 塩野崎敦, 末吉隆彦, 味八木崇, PlaceEngine:実世界集合知に基づくWiFi位置情報基盤, インターネットコンファレンス2006, pp.95-104, 2006.

    LaMarca らは、GPS を携行して街中を移動しながら得た大量の無線LAN 電界情報のログから、アクセスポイントの位置制約条件を抽出し、アクセスポイントの位置を推定する方式を提案している[5]。しかしながら、アクセスポイント状況は漸次変化していくので、このようなバッチ式の位置更新だけでは変化に追従しきれない。

    本論文では、バッチ式の位置推定方式に加えて、エンドユーザによる位置アクセスによっても位置情報データベースを更新することを特徴とする無線LAN 位置情報システム, PlaceEngine について報告する。

    (中略)

    • 利用者によるデータベース更新は、利用者が電測情報の測定と同時に明示的に位置を登録する場合に行われるが、利用者が単に位置を検索した場合にも発生する

    • すなわち、大量の利用者が継続的にシステム対してに検索要求を発生する行為自体がデータベースを更新・増大させるための重要な情報源となる。

    2.4 利用者の位置登録/検索によるデータベースの更新

    利用者が位置を検索する場合

    (中略)

    まず、検索要求に未知のアクセスポイントが含まれる場合が考えられる。位置情報は既知のアクセスポイント情報から得ることができるが、電測情報にデータベースに登録されていなアクセスポイントが含まれていた場合、推定した位置情報を、そのアクセスポイントの初期登録位置として記録する。図7に典型的な位置検索の際のパラメタの例を示す。検索要求に未知のアクセスポイント情報が含まれている。このような場合、既知のアクセスポイント情報に基づき位置を推定し、未知アクセスポイントの初期位置も推定位置として設定する。

このことは、今年9月のイベントの講演でも示されたようで、記事中のこのスライドに例が示されている。

したがって、自分の家のアクセスポイントがPlaceEngineに登録されることを嫌う人が、既に登録されてしまっていないか確認しようとするときに、PlaceEngineをそのまま使ってはいけない。確認のために使用する行為が、自ら登録する行為となってしまいかねない。

サーバに影響を与えることなく、その確認をしたければ、次のようにすればよい。

未登録のアクセスポイントが検索時に登録されるのは、そのとき同時に観測される周辺の他のアクセスポイントが既に登録されていて、位置を取得できる場合に限られるのであるから、確認しようとするアクセスポイント1個だけしか観測されない状態で、PlaceEngine検索を行えばよい。

つまり、前回の「デイリーポータルZ 記者の家を探しに行く」で行った実験と同様に、アルミホイルで包むなどして、周辺環境に存在する他のアクセスポイントを観測しないようにしたうえで、確認対象のアクセスポイントのビーコンだけが観測される状態を作り出し、PlaceEngine検索を行う。住所が示されれば既に登録されているということであるし、「位置が特定されません」と表示されれば未登録ということになる。

前回と異なり、MACアドレスの変更が可能なアクセスポイント機器は必要ない。確認対象の(自分の)アクセスポイント機器と、観測する側のPC(PlaceEngineを稼動させるPC)を近くに置いて、それら全体をアルミホイルで包めばよい*1

このとき、前回の図6(下の図2)のように、Network Stumblerなどを用いて、たしかに1個のアクセスポイントしか観測されない状態であることを十分に確認してから、PlaceEngineを使うよう注意した方がよいだろう。

図2: 1個のアクセスポイントのみ観測していることを確認した様子(前回の図6)

たしかに1個のアクセスポイントだけで検索を行ったかは、検索後のPlaceEngineの画面で、上段の灰色の縦棒が1本だけかどうかで確認できる。

図3: 1個のアクセスポイントだけを使ってPlaceEngine検索した様子(前回の図7)

検索したタイミングではたまたま2本だった……なんてことになれば後の祭りなので、事前に十分に確認したい*2

ただし、この方法で登録済みかどうか確認できるのは現時点での話だという点に注意したい。もし、今後、PlaceEngineサーバ側が、プライバシー対策として「複数のアクセスポイントが観測されているときにしか位置情報を応答しない」という対策(5月27日の日記の脚注6の対策)をとった際には、上の方法で確認しようとして「位置が特定されません」と表示されても、それは必ずしも未登録ということを意味しない。その状況では、自分のアクセスポイントが登録済みかどうか確認することは難しくなるだろう*3

もっとも、こうして、自分のアクセスポイントが未登録であることを確認できたとしても、それはあくまで現時点での話である。今後、誰かが(隣人や、通りすがりの人が)家の近くでPlaceEngineを使ってしまえば、そのときに登録されてしまうわけで、それを食い止めるには、司法の力に頼る以外に術がないのではないか。

では、自分の家のアクセスポイントが登録されてしまっているとき、その位置情報を変更することはできるだろうか。たとえば、皇居の中心に変更するとか、沖ノ鳥島に変更してしまえば、誰も本当の位置だと思わなくなると期待できる。

これを故意に行った場合、PlaceEngineサービスに対する業務妨害として責任を問われるおそれがあるかもしれない。ただ、自分のプライベートな情報を無断で勝手に登録されたことに対する対抗措置として、自分の情報についてだけ無効なものに変更するのは、正当な行為であると抗弁できるようにも思える。

もちろん、他人のアクセスポイントに対してまで、位置情報をかく乱させるような変更行為を、故意に継続して大量に行えば、確実に業務妨害行為に当たるだろうし、自分のアクセスポイントの位置情報をかく乱させる行為を組織的に大量の人にさせるよう教唆する行為も、業務妨害行為に当たるおそれがあると思えるので、私はそのような変更行為を推奨しない。

また、技術的観点から言って、そのような変更を行っても無駄である。いずれ、誰か(隣人や通りすがりの人)によって正しい位置に補正されてしまう。このことは、一般向けに書かれた次の記事でも解説されている。

  • 立っている無線LAN APは他人のものでも使え!?, 日経IT Pro 記者の眼 安井晴海, 2007年8月1日

    ユーザー参加型のコンテンツの場合,問題となるのが信頼性である。PlaceEngineも,誤操作などによる誤った位置登録や,悪意を持ったユーザーによるニセの位置情報が登録される危険がある。また,無線LAN AP自体が移動する可能性もある。(中略)しかし末吉社長は,「登録件数が増えれば増えるほど,そうした誤った情報は排除されていく」と語る。ソニー本社の“誤登録”も,しばらくたつと解消されたという。

    また位置情報は,ユーザーによる「登録」だけではなく「検索」でも更新されていく。例えば,A,B,CというAPが新宿にあり,これら3つのAP 情報で検索をかけると「新宿」の位置情報をPlaceEngineサーバーが返していたとする。ところが,CのAPを持つ会社が渋谷に移転してX,Y,Z のAPの近くになると,今度は渋谷からX,Y,Z,Cの4つのAPで位置検索がかかるようになる。Cが混ざってはいても,X,Y,Zがある限りは確率的に渋谷の可能性が高いため,位置情報としては「渋谷」を返す。それと同時に,Cの位置が渋谷に移った可能性が高いことをPlaceEngineサーバーが把握するというわけだ。

この記事は、無難なことに、「会社の移転」を題材にしているが、これは個人の家の無線LANアクセスポイントでも同じであることに注意したい。

無線LANのステルス機能ではPlaceEngineに登録されるのを阻止できない

前回の日記に対するリンク元などを見てまわったところ、「ステルス機能でアクセスポイントを隠さなきゃ」といった感想を書いている人がいた。無線LANのいわゆる「ステルス機能」は、SSIDを隠そうとするもの*4であるが、MACアドレスを隠せるものではない。

このことについて、8月に書かれた日経IT Proの記者の眼にも次の記述があった。

  • 立っている無線LAN APは他人のものでも使え!?, 日経IT Pro 記者の眼 安井晴海, 2007年8月1日

    PlaceEngineでは,ビーコン信号中のMACアドレスと電界強度を使って位置を割り出す。ただし,ステルス機能を設定しているAPの場合は位置情報の取得には使えない。ステルス機能とは,ESS-IDの存在を隠すためにビーコン信号の送出を制限するセキュリティ機能のことである。

これは事実に反する誤った記述である。

第一に、無線LANのステルス機能とは、ビーコンパケットの送出を止めるものではない。送出されるビーコン中のSSID欄にSSIDを記載しないようにする機能であり、当然ながらMACアドレスは送出される。

第二に、もしかすると、PlaceEngineクライアントが、傍受したビーコンについて、ステルス機能でSSIDが空になっているものについては、MACアドレス情報をPlaceEngineサーバに送信しないよう、配慮された設計になっている可能性もあるが、現時点ではそのようにはなっていない。

実際に、上に書いた「自分の無線LANがPlaceEngineに登録されていないか確認する方法」の方法で、私の家のステルス設定のアクセスポイントについて確認を行ってみたところ、住所が表示された。ステルス設定のアクセスポイントのMACアドレスがPlaceEngineサーバに送信されたためと推定される。

もっとも、今後、プライバシー配慮の第一歩として、ステルス設定のアクセスポイントの傍受情報をPlaceEngineで窃用しないようにする改善が行われる可能性はあるかもしれない。

その場合、必要な人がその設定変更の必要性を認識できるよう、PlaceEngineサービスの運営者は、その仕様の明確な開示と、それが何のための配慮であるかを説明しなければならない。また、それは、PlaceEngineユーザに説明すれば済むというものではなく、すべての無線LANアクセスポイント設置者に対して必要な説明である。

ユビキタス社会の歩き方(4) 他人から貰う無線LAN機器に警戒する

モテ頃の女性(など)は、知人男性(など)から無線LANアクセスポイント機器をプレゼント(など)された際には、プレゼント主がMACアドレスをメモするような人物でないか注意した方がよいかもしれない。

貰い物を自宅で使用していると、しばらく経過した後(つまり、誰かが自宅近所でPlaceEngineを使用して、そのMACアドレスがPlaceEngineサーバに登録されるに至った後)には、プレゼント主に自宅の場所を検索されてしまいかねない状態となる。

箱が未開封であること、また、箱にMACアドレスやSSID初期値が書かれていないことを確認した方がよい。

一般にこの種のリスク(譲渡されるIT機器によるストーカー行為のリスク)は、通常、初期化した後に設定を変更して使用することで回避されるものであったが、この問題(PlaceEngineによって新たに生じ始めた問題)においては設定変更で対応できない。なぜなら、たいていの独立型アクセスポイント製品には、無線側MACアドレスの変更機能がないからだ。

同様に、使用済みの無線LANアクセスポイントを他人に渡す場合にも、自宅の場所が知られてかまわない人だけにした方がよいだろう。

類似の話:

*1 全体を包むのが困難でも、観測側のPCだけをアルミホイルで包んでも十分な場合がある。観測側を軽くアルミホイルで包むことにより、家の外にあるアクセスポイントの電波を弱めて観測されないようにしつつ、かつ、近くに置いた確認対象のアクセスポイントだけ観測されるようにできる場合がある。家の中に複数のアクセスポイントがあって複数が観測されてしまうときは、確認対象以外のアクセスポイントの電源を切ればよい。

*2 事前の確認には、図2のNetwork Stumblerを使う方法以外にも、インターネット回線を切断した状態でPlaceEngineの「現在地を取得」ボタンを押す方法もある。この場合、観測したアクセスポイント数を灰色の縦棒を表示した後、PlaceEngineサーバに接続するところで接続エラーとなり、「PlaceEngineサーバに接続できません」と表示される。インターネット接続の設定を誤っていると後の祭りになりかねないので注意が必要。また、複数の無線LANカードを使い分けるときにもミスをしやすいので注意。Network Stumblerでは外付けの無線LANインターフェイスで観測していても、PlaceEngineでは内蔵の無線LANインターフェイスの方で観測していたなどというミスが起きそう。外付けのものを使うときは、内蔵のものが(単にオフになっているだけでなく)「ネットワーク接続」設定で「無効」になっていることを確認した上で、その後にPlaceEngineを起動するのがよいようだ。念のため初回はインターネット回線を切断した状態で「現在地を取得」ボタンを押すとよいだろう。

*3 たとえば、2つ以上ないと応答しないという対策がとられた場合、2台の自分のアクセスポイントを用いてテストすることができそうに思えるが、片方が既登録で、もう片方が未登録であった場合に、応答としては「位置が特定されません」であっても、サーバ側では既登録のアクセスポイントから位置を割り出すことは可能であって、その検索要求の際に、未登録だった方のアクセスポイントをサーバが追加登録してしまう可能性がある。この問題は、PlaceEngineの運営者が、そのような対策をとる際に、このことについての仕様を公開しない限り解決しない。

*4 なお、ビーコン中のSSIDを隠しても(また、ANYプローブ応答などを禁止する設定にしても)、正規利用者の通信中の他の管理フレームパケットからSSIDは特定可能である。昔は、半可通の似非セキュリティ屋が「ステルス設定が常識」などと言いふらしていたことがあったが、それは気休め程度、プライバシー配慮のものであって、攻撃者からの防御にはなっていないことに注意したい。必要なのは(WEPではない)暗号化設定である。

本日のリンク元 TrackBacks(60)

2007年10月30日

一太郎plug-inをIEとFirefoxで無効に 〜 ジャストシステムは本当の脅威を教えてくれない

目次

  • ワープロソフトの「脆弱性」とは?
  • ゼロデイ攻撃に見舞われ続ける一太郎
  • 「危険度:低」って正気で言ってるの?
  • パソコン初心者並みの認識のソフト会社
  • 「攻撃成立に必要なユーザの関与」は「積極的」か「消極的」か
  • 知られざる一太郎ビューアplug-inの存在
  • 受動的攻撃がもはや最大級の脅威
  • ジャストシステムは回答を拒否
  • 製品ベンダーが発表しなければ危険性を周知できない
  • 発見者の指摘があっても無視
  • メディアはJVN情報を伝えるときどうして発見者に取材しないの?
  • plug-inを無効にする方法

ワープロソフトの「脆弱性」とは?

先週、新たな一太郎の脆弱性と修正パッチが公開された。「一太郎の脆弱性」と聞いて、どんなときに危険のある話だと理解されるだろうか。ジャストシステム社の告知文には次のように書かれている。

■現象とその対処方法

一太郎の「セキュリティ更新モジュール」を公開いたします。

悪意のある第三者に不正に改ざんされた一太郎文書を読み込むことで、任意のコードが実行され、パソコンが不正に操作される危険性があります。

モジュールを導入することで、問題のあるファイルを一太郎で開いても、不正な動作は発生しなくなります。

アップデートモジュール導入にかかわらず、身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください。

一太郎の脆弱性を悪用した不正なプログラムの実行危険性について, ジャストシステム, 2007年10月25日

ほとんどの人は、「あやしい一太郎ファイルを開かなければ大丈夫」と思うのではないだろうか。

そもそも、ファイルを開く行為はユーザの責任である。メールに添付されたファイルの拡張子が「.exe」なら、それを開く行為は任意コード実行を許すものとなる(結果としてウイルスやボットやスパイウェアの侵入を許す)わけだが、そのことを指して、何かに脆弱性があるとは普通言わない。それなのに、一太郎のファイルを開くことが、ユーザの自己責任でなくて、なぜ「一太郎の脆弱性」なのか。

それは、データファイル(プログラムコードを含まない)として分類される拡張子のファイルは、本来ならばいつ開いても大丈夫であるはずのところ、その期待が裏切られ、(バッファオーバーフローのバグがあることによって)(攻撃者が仕掛けた)プログラムが起動してしまうためだ。データファイルとして設計された一太郎ファイルの信頼性が損なわれるわけだ。

過去に不適切な脆弱性告知をしていたジャストシステム(事例1事例2)のような会社が、このことを「一太郎の脆弱性」と認めてきたことは、潔いことだと感心していた。今年の7月までは。

ゼロデイ攻撃に見舞われ続ける一太郎

もっとも、相変わらず要領を得ない告知文の書きぶりを見れば、セキュリティ脆弱性のことを理解して「潔い」というよりも、単に、これまで何度かゼロデイ攻撃のターゲットになってきたことから、しかたなくパッチを提供し、わけもわからず「脆弱性」という言葉を使っているだけのようにも見える。

どんなにセキュリティに無理解なソフトウェアベンダーであっても、現に自社製品がゼロデイ攻撃に侵されていたら、嫌々でも対処をせざるを得ないのだろう。顧客からの突き上げもあると思われる。

「危険度:低」って正気で言ってるの?

そんなふうに思っていたところ、今年8月に出たゼロデイ攻撃に対する告知(図1、図2)を見たときは、「やっぱりこの会社は駄目だ」とはっきり認識した。

図1: 8月の告知で「危険度判定:低」と書かれていた様子

図2: 8月の告知文で「危険度 低」が主張されていた様子

わざわざことさらに「危険度判定:低」と書かれていた。

任意コード実行を許す脆弱性なのに危険度が「低」というのは、全くおかしい。

このことについて誤りを指摘しようと、8月6日に、ジャストシステムのサポートセンターに電話したところ、次の展開となった。


私: 3日付の重要なお知らせについてお尋ねしたいのですが。

J1: 一太郎の脆弱性についてですね。ただ今アップデートモジュールを開発中でありまして、レベル自体は低レベルと判断しておりまして、添付ファイルを開かないようにご注意いただいているところです。

私: 添付ファイルを開かなければ大丈夫なんですか?

J1: セキュリティソフトメーカーの判定ではございますが、信頼性の保証されていないWebサイトの、出所の不明なファイルを開かないようにご注意ください。

私: それでいいんですかね?

J1: 私では、重要なお知らせに書かれていること以上のことがご案内できませんので、一太郎の選任のサポート担当者に代わります。

(しばらく待つ)

J2: お待たせしました。一太郎専任のサポートの者です。

私: 一太郎ビューアのユーザなのですが、3日付の重要なお知らせが出ている脆弱性ですが、これはどうすればよいのでしょうか?

J2: 今回、脆弱性の対策プログラムを開発中ではございまして、お客さまには、メールの添付ファイルを開かないように、信頼できないWebサイトの出所不明なファイルを開かないようにお願いしているところです。

私: さきほど電話の最初の方は「レベル自体は低レベルと判断しておりまして」とのことでしたが、レベルが低レベルというのはどういう意味ですかね?

J2: 危険度という意味では、パソコンが完全に壊れてしまうということではないということして……

私: 過去にも脆弱性がありましたが、今までのものと比べるとどうなんでしょうか。

J2: これまでのものも低レベルでした

私: でも、今回だけ低レベルと書いてあるんですよね。「重要なお知らせ」のページに掲載されている過去の告知には、低レベルとは書かれていないですよね。今回だけ「危険度判定:低」とわざわざ書かれているので、今回は以前と違ってたいしたことないという意味かと?

J2: たしかに重要なお知らせには書かれておりませんが、これまでも低レベルでした

私: セキュリティソフトメーカーによる判定とのことですが、具体的にどこのことですか?

J2: シマンテック様やマカフィー様です。

私: それって、感染の状況が少ないっていう意味じゃないんですか?

J2: ……。

私: 電話の最初の方は、開口一番「レベル自体は低レベル」とおっしゃいましたが、「危険度が低というのはおかしいんじゃないかと思うんですよね。

J2: 危険度に関してセキュリティソフト側のものとしては、感染力や影響力などによって判断しているようでして、こちらでは詳しくはわかりかねます。今回の脆弱性に関しては、危険度が高かろうが低かろうが、アップデートモジュールをご提供するつもりで開発を進めておりますので、メールなどで送られてきた場合には安易に開かないようにしていただければと。

私: 「危険度:低」の意味がわからないとおっしゃいますが、サポート窓口ではわからないということはいいですよ、しかたがないとして、しかしながら、ジャストシステム社としての見解はどうなんですか? おたくの告知文の中に「危険度:低」と、意味もわからないままに書いているということはないですよね?

J2: ……。

私: あなたではわからないようなので、「危険度:低」と書いた人に直接伝えたいです。

J2: 担当の者から折り返しお電話いたします。


パソコン初心者並みの認識のソフト会社

以前から感じていたことだが、「セキュリティといえばウイルス対策のこと」と勘違いしている会社がけっこうあるようだ。たとえば、モーニングスターWebサイト改竄事件でも同じことが気になった。(これについては日を改めて書く。)

それは無理もない話で、おそらく、次の順序で事態が展開しているために、そのような勘違いが生じているのだろう。

未知の脆弱性を突いたウイルス入りファイルが、標的型攻撃で特定の組織だけに送り付けられる。
  ↓
ウイルスメールを送りつけられた組織のシステム管理者が、アンチウイルスソフト会社に、それを検体として届け出る。
  ↓
アンチウイルスソフト会社が、そのウイルスについての情報を公開する。
  ↓
脆弱性を突かれたソフトのベンダーがそれを知り、告知文を書く。アンチウイルスソフト会社の発表を基にして。

つまり、8月の件でジャストシステムが「危険度:低」と書いてしまったのは、シマンテックの発表(図3)にあった「危険度 1: ほとんど影響なし」の記述を、そのまま書き写したためと思われる。

図3: シマンテックの告知「危険度 1: ほとんど影響なし」*1

これは全く馬鹿な話だ。脆弱性の危険度と、1つのウイルスの危険度とでは、尺度が別々のものだ。

ウイルスの危険度は、それがどれだけ広く感染するものかが主要な評価尺度となる。ワームであれば危険度は高いが、他への伝染能力を持たない単なるトロイの木馬であれば、危険度は低いものとされる。図3のように、このときのゼロデイ攻撃では「感染報告数 0-2」となっていた。おそらく、1件の届出があっただけなのだろう。

また、ウイルス対策ソフト会社にとっては、感染の原因が脆弱性を突いたものかどうかはどうでもよいことなのだ。なぜなら、メール添付の「.exe」ファイルを自ら開いて感染してしまうようなユーザを相手にしているので、脆弱性がなくてもワームのように拡散するウイルスは「危険度:高」と評価される。

それに対し、脆弱性を修正する立場にあるソフトウェア製品のベンダーはどうか。ゼロデイ攻撃などというのは例外的な事件であって、攻撃が出る前に脆弱性を修正するのが本来の姿だ。そのときは当然「感染報告数」は 0 なのであって、シマンテックに情報が載ってさえいない段階で、攻撃を未然に防ぐために、その脆弱性がもし今後攻撃されたらどれだけの危険性があるかをユーザに伝えて、対処を促すというのが、常識的な製品ベンダーの行動である。

そして、バッファオーバーフロー脆弱性のような、任意コード実行を許す脆弱性の危険度は、誰もが知っているように、致命的なものだ。実際、8月のゼロデイ攻撃のときは、Secuniaの評価では「Extremely critical」とされていた*2

ジャストシステムはそんなことさえ理解していない製品ベンダーだ。

ジャストシステムにはまともな技術者がいないのか? ジャストシステムにだって、社内情報システムがあるだろう。そこには当然にシステム管理者がいて、システム管理者はWindowsやAdobeなど他社製品の脆弱性情報に目を配って、危険度を評価し、重要度に応じて社内システムへの対応を行っているだろう。そのシステム管理者から見て、一太郎のバッファオーバーフローが「危険度:低」というのはおかしいと思わないのか?

部署が違えば他人事なのか? 自社の信頼のために自発的に社内で行動するという愛社精神はないのか?

「攻撃成立に必要なユーザの関与」は「積極的」か「消極的」か

とはいえ、脆弱性の危険度の評価には、「任意コード実行」のように攻撃で何が可能かという尺度だけでなく、どのくらい容易に攻撃が成功してしまうかという尺度も重要だ。

JVNには、「JPCERT/CCによる脆弱性分析結果」という危険度評価がある。この評価指標のひとつに、「攻撃成立に必要なユーザの関与」という項目がある。ここは、「積極的」、「消極的」、「関与させる必要なし」の3段階で評価されている。これがどういうものかというと、おそらく次のようなものであろう。

「攻撃成立に必要なユーザの関与」が「関与させる必要なし」というのは、たとえば、HTTPサーバの脆弱性のように、被害者が眠っている間にも、攻撃者からの能動的な攻撃によっていつでも被害が出てしまうものを指す。これは危険度が高い。

一方、「攻撃成立に必要なユーザの関与」が「積極的」というのは、被害者が自ら望んで行った操作によって攻撃が発動するというもので、たとえば、メールの添付ファイルを開くとか、怪しいWebサイトに置かれたファイルをダウンロードして保存したものをダブルクリックして開くとか、ファイル交換ソフトで入手したファイルを開くといったものが該当する。

この場合、寝ている間には被害が出ないし、賢明な人であれば、操作に注意することで被害を回避することができる。したがって、これは危険度が低いと評価される。

その中間に位置するのが、「攻撃成立に必要なユーザの関与」が「消極的」というものだ。これは、被害者が望んで行ったわけではない操作によって攻撃が発動するというもので、たとえば、Webブラウザで怪しいサイトを閲覧しただけで脆弱性を突かれて攻撃が発動するといったものが該当する。

この場合、寝ている間には被害が出ないものの、賢明な人であっても、いくら注意していても被害を回避することはできない。「怪しいサイト」を事前に見分けることはできないし、IFRAMEタグやOBJECTタグなどによって、ページを開いただけで攻撃用ファイルもロードさせることができてしまうからだ。特に、Web 2.0時代になり、縦横無尽に張られたハイパーリンクを辿りまくるのが普通となった今では、回避できない。

では、一太郎の脆弱性において「攻撃成立に必要なユーザの関与」は、3つのうちのどれと評価されるだろうか。ジャストシステムの告知文に、

アップデートモジュール導入にかかわらず、身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください。

と書かれているということは、「積極的」なユーザの関与がなければ攻撃は成立しないということだと理解される。

私も、8月の時点まではそういうものだと思っていた。

「怪しいファイルを開くような素人ユーザが悪いんだよね」、「俺は怪しいファイルなんか開かないから関係ないね」、「たいして危険じゃないし、パッチなんか適用したら動かなくなるかもしれないし、やめとくわ」……と。

知られざる一太郎ビューアplug-inの存在

しかし、Secuniaの評価が「Extremely critical」だったのが腑に落ちなかった。Secuniaの評価指標の説明によると、

Criticality

Extremely Critical (5 of 5):

Typically used for remotely exploitable vulnerabilities that can lead to system compromise. Successful exploitation does not normally require any interaction and exploits are in the wild.

These vulnerabilities can exist in services like FTP, HTTP, and SMTP or in certain client systems like email programs or browsers.

とある。「もしかして、Internet Explorerとの複合技で何か起きてしまうのかな?」と思い、念のため実験をしてみた。8月5日のことだ。

「test.jtd」というファイルを適当に作って自分のWebサーバに置き、一太郎ビューアをインストールしているPCのInternet Explorerでアクセスしてみた。そしたら、意外な事が起こった(図4)。

図4: Webサーバ上の「.jtd」ファイルにIEでアクセスしたときの様子

なんと、一太郎ビューアがInternet Explorerに組み込まれる形で表示された。

まあ、Acrobat Readerを入れているとPDFファイルにアクセスしたときにそうなるのと同様ではある。だが、そんな機能が一太郎ビューアにあるとは思ってもみなかった。なぜなら、今までどれだけネットサーフィンを続けてきたかわからないが、一度たりとも、一太郎ファイルをWebで開く機会はなかったからだ。

ということは、一太郎にバッファオーバーフロー脆弱性があると、悪意あるサイトを訪れただけで被害に遭うのではないのか? つまり、「攻撃成立に必要なユーザの関与」は「消極的」で、賢明な人が注意していても被害を回避できないタイプの脆弱性ではないのか?

であれば、Secuniaが言うようにこれは最大級の危険性の脆弱性であって、「危険度:低」どころか「危険度:中」ですらない話だ。

受動的攻撃がもはや最大級の脅威

Secuniaの指標のように*3、今日では、受動的攻撃であっても最大級の危険度として評価されることがある。これは、そのような攻撃が現に流行している事実があるためだろう。たとえば次の記事に、その現実が解説されている。

  • 脅威,すべてはWebアクセスから始まる 第1回 普段アクセスしている“おなじみ”サイトに仕掛けられるワナ, 平原伸昭/トレンドマイクロ, 日経IT Pro, 2007年10月15日

    昨今,不正プログラムの脅威はWebアクセスによる侵入へと急激に変化している。2007年6月中旬に数千もの正規Webサイトが改ざんされ,不正プログラムが埋めこまれたイタリアの事例は記憶に新しい(関連記事)。また日本国内においても,ホームページを無料で作成できるサービスを提供しているサイトや投資信託情報を提供するサイトで同様のインシデントが発生し,大きな話題となった。

    (略)

    これらのケースの多くは,不正サイトへアクセスさせるスクリプト・タグが1行埋め込まれ,パソコンに内在するぜい弱性を突いて不正プログラムをダウンロードさせられる*4という仕掛けを施されたものである。

    これらは,普段から多くのユーザーがアクセスしている「正規Webサイト」。にもかかわらず,結果的には,アクセスしてきたユーザーの一部に大きなセキュリティ被害をもたらした。「怪しげなWebサイトに近づかなければ大丈夫」とは,決して言えない。

こういった攻撃が流行っている昨今、Webサイトを閲覧しただけで発動する一太郎の脆弱性の責任は重い。

ジャストシステムは回答を拒否

8月6日に電話した際、「担当の者から折り返しお電話いたします」のその後がどうなったかというと、「『危険度:低』と書いた人」と直接話すことは叶わず、サポートセンターの責任者を通した間接的なコミュニケーションとなった。

まず、次の質問には回答が得られた。

  • 一太郎ビューアではなく、一太郎本体をインストールしたときにも、このplug-inはブラウザにインストールされるのか?

回答は「yes」だった。次に、

  • この脆弱性は、ブラウザplug-inで開いたときにも任意コード実行となるものか?

という点について尋ねたところ、即答できないので上に報告するとのことだった。その際、私の意見として、

もし脆弱性が発動する可能性があるなら、告知文に書かれている回避策「開かないようご注意ください」は間違っていることになるから、訂正が必要で、plug-inを無効にする設定を回避策として告知するべきだ。

ということ伝えた。しかしこの点について告知文が修正されることはなく、4日後にパッチがリリースされた際に、告知文が改定されたものの、「アップデートモジュール導入にかかわらず」という部分が追加されただけだった。

アップデートモジュール導入にかかわらず、身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください。

一太郎の脆弱性を悪用した不正なプログラムの実行危険性について, 2007年8月3日(2007年8月17日改訂版)

そこで、「告知文が訂正されていないが、これは、私が言ったことが伝わっていないのではないか」と尋ねたところ、サポートセンターの責任者は「きちんと伝えている」と言うので、次の3つの可能性のどれかではないか? と尋ねた。

  1. 調査を行ったところ、技術的要因によりこの脆弱性はplug-in経由では発動しないものであることがわかったため、告知を訂正する必要がないと判断している可能性。

  2. 調査を行うにあたり、Symantec等から得た当該トロイの木馬の検体を用いてplug-in経由でどうなるか試したところ、トロイは動かなかったため、告知を訂正する必要がないと判断している可能性。

  3. 話は聞いたが調査はしていない可能性。

そして、もし 2. であるなら、調査方法が間違っているということを伝えた。ローカルファイルを開いたときに発動するように作られたexploitがplug-in経由で動作しないのはたまたまであって、plug-in経由で動作するよう調整されたexploitが登場する可能性があるということを伝えた。 また、もし 1. であるならそのことを知りたいと問い合わせた。

それに対し、翌週、回答があり、「1. 2. 3. のどれなのかということも含めて、回答しないというのが経営の判断です」という回答だった。

無駄骨だったが、「経営の判断です」というくらいだから、然るべき人に趣旨は伝わっているはずだろう。

製品ベンダーが発表しなければ危険性を周知できない

結局、本当にplug-inで発動するかは不明なままだったので、マスメディアもその危険性を伝えることができなかった。以下のように、報道では「ファイルを開かないように注意すればよい」ということになっていた。ジャストシステムの発表をそのまま流しているだけだからだ。

これは、JVNでも同じだ。

JPCERT/CCでさえ次のように言っていた。

  • JPCERT/CC REPORT 2007-08-08

    2007年8月7日現在、この問題を解決するアップデートモジュールは提供されていません。ジャストシステムでは、アップデートモジュールを開発中と発表しています。アップデートモジュールが提供されるまで不審な一太郎ファイルは開かないようにしてください

製品ベンダーが脆弱性情報を隠蔽したり、あるいは分析する能力がなくて発表できないでいる場合でも、もしその脆弱性の発見者が善意の発見者であるなら、発見者から正確な危険性の情報が公表されると期待できる。

それに対し、8月のゼロデイ攻撃の脆弱性のように、悪意の発見者によるものである場合には、検体を持っている人にしか分析ができない。

検体は、ウイルス対策ソフト会社が持っているわけだが、ウイルス対策ソフト会社は、ウイルスの挙動は分析するけども、ウイルスが悪用している脆弱性の(脅威の範囲の)分析はしない。なぜなら、会社の利益に関係がないからだ。彼らの目的は(第一には)公共の安全ではなく、ウイルス対策ソフトを売ることである。

報道でも次のように、現象面ばかりが伝えられていた。

  • 一太郎に新たなゼロデイ攻撃、画面の「閃光」でマルウェアに感染, ITmedia, 2007年8月6日

    セキュリティソフトメーカーのSymantecは、不正な一太郎文書のサンプルを入手したと報告。この文書を開くと画面に閃光が走るが、これはマルウェアが脆弱性の悪用に成功し、もとの文書をクラッシュさせてしまったことを示す。その後新しい文書が開かれるが、中身は空白だという。

    システムには「Trojan.Tarodrop.D」というドロッパー型トロイの木馬が感染する。ここからさらに別のトロイの木馬「Hacktool.Keylogger」を呼び込み、キーボードの入力情報を記録して、盗んだ情報を外部に送信する。さらに、システムに自らをコピーして、ユーザーが自分のファイルをすべて見られないようにしてしまうほか、ファイアウォールもかいくぐってしまう可能性が高いという。

    (以下略)

  • 一太郎の0-day脆弱性を悪用するマルウェアが再び発生 - 米Symantec, マイコミジャーナル, 2007年8月6日

    米Symantecは同社が運営するblog「Symantec Security Response Weblog」において、ジャストシステムの日本語ワープロソフト「一太郎」の0-day脆弱性を悪用するマルウェアが、再び発生したと公表した

    これによると、今回発見された「Trojan.Tarodrop.D」は、一太郎の0-day脆弱性を悪用することでトロイの木馬を生成するという。その後、このトロイの木馬はキーロガーを生成し、盗み出した情報をcvnxus.8800.orgのTCP443番ポートへ送信するとされる。

    また、今回使用が確認されたキーロガーは、自分自身を「%System%\dg.exe」として複製したうえで、explorer.exeのプロセス空間に注入するのだという。こうすることで、感染PCの利用者からこうしたファイルの存在を隠すことができる。同様の動作は「%System%\ svhosts.exe」によって再起動後も発生し、感染を継続させることができるという。

    (以下略)

ある脆弱性に対してたまたま作成された1個のウイルス作成例について動作内容を説明しているだけで、どういうときに脆弱性が発動するかの脅威の範囲についてSymantecは追いかけていない*5

そして、検体の提供を受けたであろう製品開発者のジャストシステムは、ウイルス対策ソフト会社の言うことしか見ておらず、「危険度:低」などと発表してしまう有様だ。

発見者の指摘があっても無視

そして、今回、新たな脆弱性が発見され、IPAに届け出られたものが、JVNで公表された。

今回のケースでは、発見者が脅威の範囲を公表している。

発見者の鵜飼さんにメールで聞いたところ、plug-inで発動することはIPAへの届出にも書いたとのことだった。

それなのに、ジャストシステムが今回公表した告知文は、8月のときと違っていない(図5、図6)。

図5: 10月25日発表の脆弱性の告知

図6: 8月3日発表の脆弱性の告知(8月17日改訂版)

8月のときと異なり、ブラウザplug-inで脆弱性が発動することが実験で確かめられているにも関わらず、ジャストシステムは知らぬ存ぜぬを通した。何が問題なのかは、8月の電話で既に伝えているわけで、「経営の判断です」と答えるほどのレベルまで耳に届いているはずなのにだ。

そして、まずいことに、10月25日にIPAからプレス発表された注意喚起においても、ファイルを開かないようにしていれば発動しないかのような誤解を与える文章が掲載されてしまった。

JVNも、煮え切らないぼんやりとした表現しかしていない。

  • JVN#29211062 一太郎シリーズにバッファオーバーフローの脆弱性

    詳細情報

    ジャストシステムが提供する一太郎シリーズはワープロソフトです。この一太郎シリーズには、バッファオーバーフローの脆弱性が存在します。細工された jtd ファイルを直接開いたり、ウェブサイトなどを経由して閲覧した場合に、その操作を行ったユーザの権限で任意のコードを実行される可能性があります。

「ウェブサイトなどを経由して閲覧」とはどういう意味なのか? なぜもっとはっきり書かないのか?

こうなると、マスメディアはこれを右から左へと流すだけだ。

  • 「一太郎」に危険な脆弱性が3件、ファイルを開くだけで被害の恐れ, 日経IT Pro, 2007年10月25日

    細工が施された文書ファイル(.jtd)を開くだけで、悪質なプログラム(ウイルスなど)を実行される恐れがある。

  • 一太郎シリーズに深刻な脆弱性, ITmedia, 2007年10月26日

    問題を悪用されると攻撃者が細工を施した文書をユーザーに開かせ、任意のコードを実行することが可能になる。(略)

    同社はアップデートモジュール導入にかかわらず、身に覚えのない電子メールの添付ファイルを開いたり、信頼性が保証されていないWebサイトなどにあるファイルを開かないよう、注意を呼びかけている。

「ブラウザで悪意あるWebサイトを訪れただけで」ということを誰も書いてくれない。

メディアはJVN情報を伝えるときどうして発見者に取材しないの?

しかし、今回、@ITの高橋睦美記者*6がすばらしい記事を書いてくださった。

  • ブラウザプラグインにも要注意 一太郎の脆弱性、リンクのクリックだけで悪用される可能性も, 高橋睦美, @IT, 2007年10月26日

    脆弱性を発見した同社のCTO、鵜飼裕司氏によると、これらは、過去にゼロデイ攻撃に悪用された一太郎の脆弱性と同程度か、それ以上の脅威レベルだという。

    (中略)

     「一太郎ファイルは、PDFなどのようにプラグイン経由で、警告なしに自動的に開いてしまう」(鵜飼氏)。つまりユーザーによる動作が介在しなくとも、 Webブラウザで攻撃コードが記述されたファイルへのリンクをクリックするだけで、自動的に攻撃ファイルが開かれ、被害を受ける可能性がある。

    なお、ジャストシステムのアドバイザリには、過去の脆弱性と同様の注意として「身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください」と記述されているが、プラグインを介した攻撃の可能性については触れられていない。

    同社によると「特定の操作に限定しない形で注意を喚起したかった」ことがその理由という。

    (中略)

    さまざまなユーザーが利用していることを考えると、脆弱性の公表においては、何が根本的な問題であり、どうすればそれを避けたり、解消できるのかを正確に伝えることが望まれるだろう。この点についてジャストシステムは「今後検討する」としている。

このように、発見者に取材すれば、発見者しか知らない(もしくは発見者にしか言えない)有益な事実が出てくることもあるわけだ。

そして、この影響があってか、IPAの注意喚起文は訂正されている(図8)。

図8: IPAの注意喚起文が訂正された様子

これは以前から書こうと思っていたことだが、JVNの情報が、ネットメディアで扱われるようになったのは喜ばしいことだけども、内容が、JVNに書かれていることそのまま(語順を変える編集程度)という記事があまりにも多すぎる。

速報性を重視して、できるだけ早く記事を出すという考え方も理解できるが、各社横並びで、どこを見ても同じことが書いてあるのでは、報道としての価値があるのか疑問だ。

どうすればいいかは簡単なことで、発見者が公表されているJVNについては、発見者に取材をしてみたらいい。何か、未公表の有益な情報を得ることができる場合もあるだろう。

私もこれまでに何件か、JVNに届け出た脆弱性があるが、一度も取材はなかった。おそらく、他の方々にも取材はいっていないのだろう。

私は、こうして独自に情報発信する術を持っているから、取材されなくてもかまわないが、他の発見者の方々の中には、取材されたら出すような貴重な情報をお持ちの方もあるだろう。

英語圏の脆弱性の報道を見ていると、メディアは必ず発見者の見解を取って紹介している。どうして日本のメディアにはそれができないのか。

plug-inを無効にする方法

顧客がどういう情報を必要としているかに理解が及ばないジャストシステムの製品など、個人的に使いたくないところだが、そうはいっても、役所方面とのお付き合いのある仕事をしていると、一太郎文書が送られてくることもあるので、一太郎ビューアくらいは入れておかざるを得ない。

かといってこのまま使い続けるのは不安だ。ゼロデイ攻撃が4回、事前の発見が2回の、計6回もの任意コード実行の脆弱性が見つかっている。今後も再び発見されそうに思えるところ、ジャストシステムは、plug-inの脅威のことを教えてくれない。実際、私も7月まで、危険な状態におかれていることを知らなかったわけだ。

もっとも、一太郎文書をWeb上に埋め込んで表示する必要性は全くないので、無効にしてしまえばいいのではないか。

以下の方法ですべての脆弱性を回避できるかは確認していないが、Internet Explorerでの無効化手順と、Firefoxでの無効化手順を挙げておく。

Internet Explorerの場合:

  1. 「インターネットオプション」で「プログラム」タブを選び、「アドオンの管理」ボタンを押す。
  2. 「表示」という見出しのメニューで「Internet Explorerで使用されたアドオン」を選ぶ。
  3. 下の枠に表示される項目の中から、「tJsViewx Control」と書かれたActiveXコントロールを選択する(図8)。

    図9: 「tJsViewx Control」を「無効」に設定した様子
  4. 「設定」欄にある「有効」「無効」の選択肢のところで、「無効」を選び、「OK」ボタンを押す。

Firefox 2.x の場合:

  1. アドレスバーに about:plugins と入力してエンターキーを押し、インストール済みplug-inの一覧を表示させる。
  2. 「JS文書ビューアプラグイン」の項目のところに書かれているファイル名「Npjsview.dll」を確認する(図10)。
    図10: Firefoxのplug-in一覧から「JS文書ビューアプラグイン」を探した様子
  3. この名前のファイルをディレクトリ「C:\Program Files\Mozilla Firefox\plugins」の中から探して削除する。
  4. Firefoxを再起動する。

追記

高橋記者によるこんなコラムが出ていた。

*1 ちなみに、このシマンテックの日本語訳もおかしい。「地域危険度:低」と書かれた項目は意味不明だが、英語版ページを見ると「Geographical Distribution: Low」と書かれている。訳すなら「地理的拡散度:低」といったところか。「対処レベル:易」というのもよくわからない。原文では「Threat Containment: Easy」だ。どうしてこんなに出鱈目な奴らばかりなの?

*2 もっとも、Secuniaが、一太郎がどういうものか本当に理解して言っているのか、疑わしい気もしないでもないが。

*3 Secuniaでは、加えてexploitが既に出回っているときに、extremely criticalと評価しているようだ。

*4 「ダウンロードされられる」こと自体は問題じゃないし、ダウンロード自体は脆弱性を突かなくてもさせられる。問題はダウンロードしてかつ実行させられてしまうことであり、それは脆弱性を突かなければ不可能なこと。アンチウイルスソフトを常用していると、ダウンロードした時点で警告が出てビビるので、ダウンロード自体が危険なものと勘違いしている人も少なくないようだが。

*5 あるいは、このケースでは、一太郎という日本だけで使われているソフトだったため、Symantecは脅威の範囲を分析するまでの興味を抱かなかった(ブラウザplug-inの存在を知る気がなかった)ということなのかもしれない。

*6 前ITmedia、大昔からインターネットのセキュリティ問題を記事にし続けていらした方。

本日のリンク元 TrackBacks(42)

2007年10月31日

ジャストシステムはどこへ向かっているのか

ジャストシステムが、ユーザの安全確保よりも、何らかの別の目標*1に向かっているらしいことは、次の事例で一目瞭然だろう。

図1: ジャストシステムの「すでに改修されている脆弱性について」という告知 (2007年4月6日発表)

こんな言い回しは他で見たことがない。

脆弱性情報を公表することの目的が、まだ修正版の存在を知らされていないユーザに対してアップデートの必要性を周知することにあるということは、(ユーザの立場で考えれば)誰でもわかるはずだ。それなのに、ジャストシステムは、まず先に、「ご安心ください」と言う。(図1の1つめの矢印部分。)

Kaspersky Internet Security 6.0 および Kaspersky Anti-Virus 6.0のVista対応版プログラム以前の製品(バージョン 6.0.0.306)で5つの脆弱性が発見されています。この問題に対する修正は、3月14日より無償でダウンロード提供しているVista対応版プログラム(バージョン 6.0.2.614)ですでに改修されておりますのでご安心ください。

※Windows XP/2000でお使いの方が対象となります。
※現在ダウンロード、および、店頭で販売している製品は、すでにVista対応のプログラムとなっておりますので、プログラムを入れ替えていただく必要はありません。

すでに改修されているKasperskyの脆弱性について, ジャストシステム, 2007年4月6日

当然、3月14日より前にインストールしてそのままのユーザがいるわけで、「ご安心ください」で済む話ではない。

ジャストシステムは、脆弱性のあるバージョンをまだ使用していると思われるユーザに対して、それに続く後半部分でやっと次のように言っている。(図の2つ目の矢印部分。)

まだVista対応版を入れていただいていない方は、ご面倒をおかけして申し訳ございませんが、速やかにVista対応版に入れ替えてくださいますようお願いいたします。 なお、プログラムの入れ替えが必要かどうかについては、お使いのプログラムのバージョン情報をご確認ください。

すでに改修されているKasperskyの脆弱性について, ジャストシステム, 2007年4月6日

先に言うべきことはこっちだ。

長文を読むのが苦手な一般の人たちが、上から順に目を通して、「ご安心ください」だの、「プログラムを入れ替えていただく必要はありません」という文字を見たら、どういう行動をとるか。

ジャストシステムがガス製品を販売したら死人が出るだろう。

こういった悪い社告の例については、経済産業省の「消費生活用製品のリコールハンドブック」にも書かれている。

良い社告の例が図3にあるように、読者は何をすればいいのか、自分は該当するのかが、すぐに確認できるように書かれているべきだ。

コンピュータソフトウェアのセキュリティ脆弱性のケースでは、これに加えて、どのくらいの危険度があって、回避策はあるかを示すことが重要となる。なぜなら、「危険度が小さければパッチを適用しない」という判断をする人たちがいるからだ。

このことは、IPAの「ソフトウェア製品開発者による脆弱性対策情報の公表マニュアル」に書かれている。

ジャストシステムの広報IR室長(NHKニュースで話していた人)はこれらに関心がないのだろう。

ここで気づいたのだが、今回の一太郎の脆弱性のJVNで、「ベンダ情報」の部分が図4のようになっているのが、普通と違う。

図4: JVN#29211062 の「ベンダ情報」

普通ならば図5のようになっているはずだ。

図5: JVN#75899905 の「ベンダ情報」

外国の会社がジャストシステム(図4)のようになっているのはよく見かけるが、国内の大手企業で、しかも国内からIPAに届出られてJPCERT/CC経由で調整されたものなのだから、ここは図5のようになっていても不思議でない。

この違いはどうしたことだろう? よくわからない。

それから、「Kaspersky 脆弱性」で検索してみたら、こんな記事が見つかった。上の「すでに改修されている脆弱性」(4月の件)とは別の脆弱性のようだ。

  • Kasperskyの無償オンラインスキャナに脆弱性、修正版を公開, INTERNET Watch, 2007年9月11日

    Kaspersky Labでは、すべてのKaspersky Online Scannerのユーザーに対して新バージョンのインストールを求めている。なお、同ツールは、Kaspersky Labs Japanのサイトや、ジャストシステムが開設しているKaspersky製品の情報サイトにおいて日本語版サービスが提供されているが、それらは日本時間の11日夕方時点ではまだ最新バージョンに移行していない模様だ。最新バージョンにするには、いったん英語サイトにアクセスしてアップデートする必要がある。

この件についての告知が、「JUST Kaspersky」のサイトに見当たらない。

なぜ告知しないのだろう? 告知しなくてもアップデートしてくれると思っているのだろうか?

*1 たとえば、サポートセンターへの問い合わせ件数を最小化することが、広報部門の業績評価尺度となっている場合などには、このような事態に陥りそうな気がする。

本日のリンク元 TrackBacks(100)

最新 追記

最近のタイトル

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|
最新 追記