最新 追記

高木浩光@自宅の日記

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

2008年03月02日

Winny媒介型暴露ウイルスによるファイル流出被害発生件数の推移

先週、毎日新聞の大阪夕刊に、ウイルス作者逮捕起訴事件のまとめ記事が連載された。

  • ネット汚染:ウイルス事件の影/上 院生、41種作成, 毎日新聞 大阪夕刊, 2008年2月27日
  • ネット汚染:ウイルス事件の影/中 問題意識持ちネット巡回, 毎日新聞 大阪夕刊, 2008年2月28日
  • ネット汚染:ウイルス事件の影/下 情報流出、月1600件 法規制、議員の関心薄く, 毎日新聞 大阪夕刊, 2008年2月29日

このうち「下」の回では、ネットエージェントの話として「ウィニー上で毎月約1600件の情報が流出」「流出ファイルを特に集めている人は1000人いる」という話が紹介されている。これは私も昨年6月に聞いた話だ。今ではどうなっているのだろう。というわけで、Winnyノード数調査用に走らせていたcrawlerでダンプしたキー情報を基に、私も確かめてみることにした。

まず基礎データから。12月28日の日記にも掲載したWinny稼働ノード数は、その後以下のように推移している。

グラフの図
図1: Winny稼動ノード数の推移

ノード数は引き続き同じ調子で減少中のようだ。このグラフで線が真横に伸びている部分は、crawlerが停止していたため観測できていない期間を指す。特に、2007年5月下旬から6月中旬まで約半月にもおよぶ停止期間がある。

次に、暴露ウイルスがWinnyネットワークに漏洩させている流出ファイルを対象として、キーを集計してみた。

対象としたファイルは次のパターンのファイル名を持つものとした。

^\[仁義なきキンタマ\] .*\([0-9A-F]{8}\)のドキュメント\.zip$"
^\[仁義なきキンタマ\] .*\([0-9A-F]{8}\)のドキュメント vol\.\d+\.zip$"
^\[殺人\] .*\(200\d{5}-\d{6}\)のキンタマ\.zip$"
^\[殺人\] .*\(200\d{5}-\d{6}\)のメール\.zip$"
^\[写真集\]\[IV\] .*\(200\d{5}-\d{6}\)のアルバム\.zip$"

これらのファイル名は、暴露ウイルスによって名付けられているわけだが、5パターンのうち後ろの3つにある丸括弧内の「200XXXXX-XXXXXX」の部分は、ウイルスが実行された年月日と時刻を意味していると思われる。前2つには丸括弧内に16進8桁の番号が記されているが、これはウイルス実行時に付けられたランダムな番号ではないかと思われる。

これら5パターンの流出ファイルには、Winnyの「トリップ」文字列が設定されている。トリップ文字列とは、ファイルの放流者が自分を識別できるように設定できるWinnyの機能であり、暴露ウイルスは、ウイルスが実行される毎にランダムなトリップ文字列を付与していると思われる。

5つのパターンのうちいくつかは、複数がセットとなって流出するようになっているようだ。たとえば、「[殺人] ……のキンタマ」と「[殺人] ……のメール」は1回のウイルス実行で同時に作成されて放流されるようであるし、「……のドキュメント」と「……のドキュメント vol.2」「……のドキュメント vol.3」等も同時に放流されるものだと思われる。

したがって、流出ファイル数と被害数は同じとは言えない。流出件数をどう定義するかであるが、これらをセットで1件として数えるのがよいだろう。そこで、ファイル数の集計とは別に、トリップ数を集計してみた。おそらくトリップ数が、ウイルスを実行してしまった被害回数に当たるのではないかと思われる。

下の図2は、1日当たりの流出ファイル流通量(赤い点)(目盛りは左の縦軸)と、1日に新たに発見された流出ファイルの数(緑の線)(目盛りは右の縦軸)と、1日に新たに発見された同トリップ数(青の線)(目盛りは右の縦軸)を示す。

緑の線と青の線がときどき急激に高い値を示している部分があるが、これは、観測停止期間の直後に起きているもので、観測停止期間中に発生した流出のファイルは、観測再開後に集中的に新規発見として観測されるため、このように件数が急激に高い値を示す。特に半月にわたって停止していた6月前半の直後の高い値が目立つが、これらの部分は無視して読めばよい。同様に、赤い点がときどき極端に小さな値を示している部分があるが、これも1日のうち部分的に観測が停止していた時間があるために観測数が少なくなっていることを意味している。

グラフの図
図2: 1日当たりの、流出ファイル流通量、新規流出ファイル数、新規流出件数の推移

赤い点に着目すると、流出ファイルの流通量は、2007年6月まで増加傾向にあり、2006年9月から倍増していたことがわかる。その後やや減少に転じていることがわかる。

この「流通量」というのは具体的に何を意味するかというと、Winnyノードは「私はこのファイルを送信可能です」ということを意味するファイルのキー(Winnyの「キー」)を常に放出しているわけだが、これはそのキーの観測数(流出ファイルに関するもの)である。この調査で使用したcrawlerは観測密度が十分ではないので、この絶対値にはあまり意味がない。相対値は、ファイルの流通量、つまり、そのファイルを「共有」していた人数や、それらがどれだけ継続されていたかの度合いを概ね示していると考える。

2007年5月まで流通量が単調に増加していたのは、流出ファイルの累計数が単調に増加していることを反映したものではないかと考えられる。

緑と青の線に着目すると、最初に大きな値になっていて、急激に減少し、最初の3か月間は漸近的に減少する値となっているが、これは、新規に発見された数を示している値なので、観測開始初期には必然的に大きな値となる。つまり、例えば、2006年11月のある日に初めて観測されたファイルは、観測開始日(2006年8月下旬)より前に放流されたものである場合がけっこうあるということである。観測開始から3か月半ほどで概ね収束しているように見えることから、流出ファイルは、数か月に1回程度の頻度でしかキーを放出しないようなケースがあるものの、3か月半以上期間を置いて同じファイルのキーが放出されることは少ないようである。したがって、緑と青の線に着目するときは、2006年12月より前を無視して読むのがよい。

そうすると、このグラフで注目すべき特徴は、新規流出件数が2007年4月中旬に急増している点であろう。

2006年12月から2007年4月中旬までは概ね一定の値となっており、流出件数(青の線)は、1日当たり50件ほどを示している。1日50件というのは1か月で1500件であるから、ネットエージェントの話と概ね一致している。

新規流出件数は、2007年4月中旬から5月下旬にかけて倍増している。このとき何があったのだろうか。この状況は6月中旬か下旬ごろに元の水準に戻っている。(6月上旬は観測停止期間であり、肝心なときにデータを採れなかったのは悔やまれるところである。)

2007年4月中旬というと、若いカップルが秘め事を撮影したプライベートビデオと写真が流出させられた件が思い起こされる。このとき、マスメディアがこぞってこの件を報道した。その日付を確認すると以下のようである。

これらの新聞や週刊誌が発売された4月10日〜20日あたりの様子を図2のグラフから読み取ると、ちょうど17日あたりから流出件数が増加しはじめていることがわかる。当該部分を拡大したものを図3に示す。

グラフの図
図3: 図2の2007年4月中旬に起きた変化部分の拡大

おそらく、この新聞や週刊誌の記事を見て興味を持ち、この流出ファイルを入手しようとし、その際に暴露ウイルスを実行してしまって自分のファイルも流出させてしまうという事態が多数発生したのだろう。

次に、ウイルスファイルの流通量の変化を調べてみた。ここでは、2月2日の日記のときと同様に、ファイル名に「        .」を含む、拡張子偽装ファイルを対象とした。

なお、ウイルスは拡張子偽装ファイルだけではない。.zip ファイルや .lzh 等のアーカイブファイルの中にウイルスが格納されていることも多い。特に、暴露ウイルスにより放流された流出 .zip ファイルには、その暴露ウイルス自身が埋め込まれているわけだが、他にも、音楽CDを1枚まとめたアーカイブファイルのように見せかけて、中にウイルスも入れられている(そしてその中のファイルのファイル名で拡張子が偽装されている)ことがあるようだ。また、不正に放流されているコンピュータソフトのインストーラ(○○Setup.exe等)が実はウイルスであるというケースもあるだろう。これらはファイル名からはウイルスかどうか判別できないので、ここでは集計の対象としていない。

図4は、1日当たりの拡張子偽装ファイルのキー観測数(赤い点)(目盛りは左の縦軸)と、1日に新規に発見された拡張子偽装ファイルの観測数(緑の線)(目盛りは右の縦軸)を示している。

緑の線は図2と同様、新規発見数であるため観測開始初期には大きな値となっている。図2と違って、1か月ほどで収束しているようである。(流出ファイルより収束しやすい原因についてはまだ調査していない。)

グラフの図
図4: 1日当たりの、拡張子偽装ファイル流通量、拡張子偽装ファイル新規発生数の推移

緑の線に着目すると、まず、2007年5月ごろまで、1日に3000〜4000個もの拡張子偽装ファイルが新たに作られて放流されていたらしいことがわかる。複数の者がこのような行為をしていると考えられるが、それにしても数千人もやっているとは考えにくいので、ある程度自動化されているのではなかろうか。

2007年5月までは概ね一定の量の拡張子偽装ファイルが生産されていたのが、2007年6月下旬以降、減少し始め、2007年8月の時点で半減、さらに減少して、現在まで減少し続けたことがわかる。なぜ、2007年6月下旬以降、減少し始めたのかその原因はわからない。

図1の通り、Winny稼働ノード数自体が減少していることから、その影響でウイルスファイルも減っている可能性もあるが、Winny稼働ノード数の減少率に比べ、ウイルスファイルは大きく減少しているように見える。

また、赤の点に着目しても、2007年5月まで拡張子偽装ファイルの流通量は単調に増加していたのが、2007年7月以降減少していることがわかる。特に、2007年12月上旬以降、減少傾向は強まっているようだ。

これらが減少し始めた原因はわからないが、冒頭の毎日新聞大阪夕刊の記事には次の通り書かれている。

京都府警(略)ハイテク犯罪対策室は現在もほぼ同じ陣容で、警視庁に次ぐ充実ぶりだ。(略)ウイルス感染によるウィニー上の情報漏えいは続発。アニメを無断使用した悪質なウイルスをターゲットに絞って昨年7月、捜査を始めた。ウィニーネットワークを監視し、「源流」となるIPアドレス(ネット上の住所)を特定。(略)

ネット汚染:ウイルス事件の影/中 問題意識持ちネット巡回, 毎日新聞 大阪夕刊, 2008年2月28日

関係があるのかどうかはわからない。

次に、1月24日のウイルス作者逮捕で、拡張子偽装型ウイルスが減少したかを見てみると、特に変化はないように見える。それより前から元々減少していたのが継続しているだけのように見える。逮捕後もなお、毎日500〜900個ほどの新たな拡張子偽装ファイルが生産され放流され続けているようだ。流している輩は「自分が作成しているウイルスは著作者人格権侵害や名誉毀損に当たらないタイプなので合法」とでも考えているのだろうか。

図2を図4と比べると、拡張子偽装ファイルの減少(図4)に比べて、流出ファイルの流通量や新規流出件数の減少(図2)は鈍いように読める。

新規流出件数は減少傾向にあるが、2007年12月以降、下げ止まっているように読める(図2)。流出ファイルの流通量も同様に下げ止まっている(図2)。Winny稼働ノード数が減少していることも加味すれば、暴露ウイルスの被害がなくなりつつあるわけではないと言えるだろう。

拡張子偽装ファイルの流通量が大きく減少している(図4)ことが、ウイルスを故意に収集して拡散させる(公衆送信可能化する)輩が減っているためであるとするなら、それは良い傾向である。早く、ウイルス罪の刑法改正を成立させて、これをゼロにまで縮めてほしいところである。

一方、流出ファイルの流通量はこの3か月間減少していない。2007年5月のピーク時よりは減ったものの、観測を開始した2006年9月の水準まで戻ってはいない。流出ファイルを集めてそれを公衆送信可能化して被害を拡大させようとする行為が、あいかわらず横行しているのであろう。こういう輩はどうにかできないものだろうか。前出の週刊誌のような行為(流出した写真を多数掲載)がまかり通っているくらいだから、どうともならないのだろうか。

なお、今回は流出ファイルとして上に挙げた5つのパターンのファイル名のファイルを対象としたが、その他にも以下のパターンのファイルがあるようだ。これについてはまだ調べていない。

^\[キンタマ\] 俺のデスクトップ .* \(.*\) \[[0-9]{2}-[0-9]{2}-[0-9]{2}\]\.jpg$
^\[キンタマ\] 俺のデスクトップ .* \(.*\) \[[0-9]{2}-[0-9]{2}-[0-9]{2}\]\(ファイル詰め合わせ\)\.zip$
^\[キンタマ\] 俺のデスクトップ .* \(.*\) \[[0-9]{2}-[0-9]{2}-[0-9]{2}\]\(ファイル詰め合わせ\)\.lzh$
^欄検眼段_[A-Z]__.*\.GJB$
^\[似非キンタマ\] Desktop Live! 0\.2\.0 [0-9a-f]{6} \([0-9]{8}-[0-9]{6}\)\.jpg$
本日のリンク元 TrackBacks(52)

2008年03月07日

朝日新聞の記事を真っ当な内容に書き直してみた

朝日新聞の

という記事のことが、スラッシュドットジャパンで「意味不明だ」と話題になっていた。

まあ、朝日新聞のIT記事にしては良い出来ではないか。肝心の要点である以下の部分はきちんとおさえられていたから、私には何の話か理解できた。

ユーザーが振り込みをしようとすると、気付かないうちに振込先がウイルス作成者の口座に書き換えられ、振込金をかすめ取られるなどの被害を受けることになる。

しかし、この点がなぜ重要なのか、それが伝わらない記事だったのだろう。

このマルウェアが危険視される理由は、銀行側がこれまでにとってきた「二要素認証」の導入という対策が全く役に立たないからだ。

「二要素認証」とは、通常のパスワードの他にもうひとつの認証要素として、乱数表やワンタイムパスワード生成器などを併用する方式のことで、日本の銀行でも採用するところが急増している。米国では、フィッシング被害の増大に悩まされる中、FFIEC(連邦金融機関検査協議会)が、2005年10月に発表したガイドライン「Authentication in an Internet Banking Environment」で、2006年末までに二要素認証を導入するよう促し、多くの銀行が導入を進めていた。

しかし、二要素認証がフィッシングやマルウェアによる攻撃を防止し切れないことは、技術系のセキュリティ屋からすればわかりきったことだった。Bruce Schneier氏も2005年の3月の時点で「銀行らは二要素認証で億単位の金をドブに捨てている」という批判をしていた。その懸念は現実のものとなり、フィッシングについては、2006年7月にcitibankで被害が発生して騒ぎとなり、マルウェアについては、2006年2月に話題になっている。このことについては、2007年9月23日の日記「対策にならないフィッシング対策がまたもや無批判に宣伝されている」の後半部分でまとめた通りである。

朝日新聞が今回取り上げた「ウイルス」も、そのような手口のマルウェアのひとつなのだろう。情報元のSymantecのblogでも冒頭で「having the ability to circumvent two-factor authentication」と言っているように、二要素認証が回避されてしまうことがこの話の肝である。朝日新聞はそのことを書いていない。

なぜこの記事がこのタイミングで出たのかわからないが、日本ではちょうど先月、全銀協が、インターネットバンキングでの不正送金被害を原則全額補償するという方針を打ち出したところだ。

  • ネットバンキング、不正被害を原則補償 全銀協, 朝日新聞, 2008年2月19日

    全国銀行協会は19日、インターネットバンキングや、盗難に遭った通帳で預金を不正に引き出された場合、預金者に過失がなければ銀行側が原則全額補償する自主ルールを策定した。ただ、ネットバンキングで、預金者に何らかの過失があると思われる場合は、個別に補償内容を協議する。(略)

    ネットバンキングでは、預金者に不正なプログラムを電子メールで送りつけて暗証番号を盗み取り、預金を引き出す被害が出ている。このため、各行は安全対策の向上にも努める。

偽造キャッシュカードなどによる被害は、2006年の預金者保護法以来、補償されることになっていたが、これをインターネットバンキングにまで広げるというのは、ちょっと無謀な決断ではないかと私は思っていた。なぜなら、マルウェア(トロイの木馬)による被害や、フィッシングによる被害は、銀行側では対策が不可能だからだ。

基本的に、フィッシングは、利用者がURLの確認を怠らないよう注意する以外に防御策はなく、マルウェアは、利用者がトロイの木馬を踏んでしまわないよう注意する以外に防御策はない。利用者がそれらの注意を怠った場合にも、銀行は補償するつもりなのだろうか。

こういう論点こそ、朝日新聞は今回の記事で書くべきだったのに、肝心なことを書いておらず、まことにもったいない。もし私が取材を受けていたなら、記事は次のようになっただろう。


強力ウイルス、ネット銀行に防御策なくお手上げ

インターネット上で銀行と取引をする「インターネットバンキング」のユーザーを狙う、攻撃力の強いコンピューターウイルスが新たに見つかった。まだ大きな被害は出ていないが、銀行側では対策する術がなく、専門家らは警戒を呼びかけている。

ウイルス対策ソフト会社のシマンテックによると、問題のウイルスは「サイレント・バンカー」と名付けられ、昨年末に米国などで見つかった。「トロイの木馬型」に分類されるタイプで、怪しいファイルを開いたり、欠陥のあるソフトでウェブサイトを閲覧したときに感染する。日本の銀行では1月末時点で被害は確認されていないが、今後、ウィニーなどファイル共有ソフトを通じて感染が広がる恐れもある。

ネットバンキングを狙ったウイルスはこれまでも数多く見つかり、銀行側も対策を取っている。パスワードを盗み読む「キーロガー」と呼ばれるトロイの木馬に対抗するため、キーボードを使わずにパスワードを入力する方式や、一回限りしか使えないパスワードを導入している銀行も多い。

だが、今回見つかった「サイレント・バンカー」はこうした対策をくぐり抜けてしまう。ユーザーがパスワードでネットバンキングに入った後に活動を開始し、ユーザーと銀行の通信を乗っ取る。ユーザーが振り込みの操作をしたときに、気付かないうちに振込先がウイルス作成者の口座に書き換えられ、振込金をかすめ取られるなどの被害を受けることになる。

全国銀行協会は先月、預金を不正に引き出された場合に預金者に過失がなければ銀行側が原則全額補償する自主ルールを、インターネットバンキングにも適用する方針を打ち出した。ウイルスに対しては、各行が安全対策の向上にも努めるとしているが、「サイレント・バンカー」には銀行側でできる対抗策がないと専門家は指摘する。感染者が続出すれば銀行はひたすら補償に追われることになるが、それでもユーザーに過失はないとして全額を補償するのか、銀行の動向が注目される。

産業技術総合研究所情報セキュリティ研究センターの高木浩光主任研究員は、「これまで文系のセキュリティ屋がお経のように唱えてきた『パスワードを定期的に変更せよ』とかいう対策は何の防御策にもならない。ユーザーは、ソフトウェアを常に最新のものにして、マルウェアを誤って実行しないよう注意するしかない。安全なファイルの開き方を学校教育で教えるべきだ」と話している。


追記

せっかくなので新聞風にレイアウトしてみた。

(使用ソフト:「朝刊太郎 Ver0.95β31」)

本日のリンク元 TrackBacks(100)

2008年03月08日

CAPTCHAのレベルはblog主が選択できるようblogサービスが提供してはどうか

先月末、江島健太郎氏の、

というブログエントリが話題になっていた。そのはてなブックマークを見ると、以下のように非難轟々だった。

  • temtan [セキュリティ][プログラム] この人プログラム初心者って自覚あるみたいだけど、だったらこれが有効かどうかも判らないはずじゃない。なんで自信満々に言うんだろう。googleのプログラマより頭良いと思ってるのかな。★
  • hatest [ダメな例] Javascriptおぼえたての人は、なんでもJavascriptで出来ると思っちゃう典型的な例。Spamに狙われるような人気サービスでもない限りhttp://www.geekpage.jp/blog/のようなCaptchaもどきでもOKだと思う。★
  • pmakino [CAPTCHA][これはひどい][セキュリティ] おもてなしという点でCAPTCHAが理想的な方法ではないのは確かだが代替案が酷すぎる。CAPTCHAですら破られているというのにそれよりひどく脆弱な方法ばかり書き並べてどうするのか ★★★★★
  • h_narazaki コノバクダンハスゴイナー。それで済んだらCAPTCHAとか最初から生まれてませんから。機械に簡単に分かるものは、機械に簡単に分かる。★★
  • fukken [これはひどい] 「コンピュータ処理が高コストで、人間が処理するのは低コストな問題」がCAPTCHAなんじゃないの?JavaScriptによる実装とかアボガド、BOTがJavaScriptを実行したら容易に読めちゃうじゃん、CAPTCHA破りの1000倍簡単だ ★★★★★★★★★★★★★★★

プププ。「この人プログラム初心者って自覚あるみたいだけど」と言われてしまうあたりも興味深い(笑)が、それはともかくとして、この記事がこのように非難されてしまったのは、書き方が悪いからだろう。

この記事はよく読むと2つの異なる話を扱っている。前半は、GoogleのCAPTCHAが破られたニュースを取り上げながら、GoogleのCAPTCHAが人に優しくないレベルのものになっていることを嘆き、とうとう検索時にまでCAPTHCAが現れるようになったことに苛立ってみせている。その一方、「では、他にどういう方法があるの?」から始まる後半は、マイナーサイトでのspam対策について考察している。これらは全然別の話だ。それを何の断りもなく繋げて書いたことが非難を招いた。

後半に書かれているのは、わりと誰でも考えたことのあるであろう、spam除けテクニックの数々だ。簡易なものから複雑なものへと順に説明されている。私なりに補足すれば、さらに簡易な方法として、単にPOSTのパラメタ名を変更するというものもある。

ここで重要なのは、spamは性質の異なる2つのタイプが存在することだ。1つは、サイト横断的に無差別爆撃するタイプのspam。もう1つは、特定のサイトやページに狙いを定めて集中的にピンポイント爆撃するタイプのspamだ。

サイト横断的な無差別spamでは、spam行為を自動化するために、何らかの共通するインターフェイスを利用するであろう。blogにおいて初期の頃、Movable Typeが狙われたように、Movable Typeのコメント送信フォームのHTML構造に合わせてspamプログラムが作られた。そのため、ワールドワイドにはマイナーな存在であったtDiaryはしばらくの間、コメントspamに悩まされずに済んでいた。しかし、後には、tDiaryもspamのターゲットとなる。このレベルの段階では、コメント用のPOSTパラメタの名前を変えるだけでspamy除けになっただろう。サイト横断的なspamは、何らかの共通のインターフェイスを使うからだ。

しかし、もちろん、「blogっぽいサイトのコメント欄っぽいHTMLフォームをWeb crawlingしながら見つけて、片っ端からspamコメントを突っ込んでボタンを押しまくる(のと同等のHTTPリクエストを送信する)」というspamボットも出てくるだろうから、それで解決しないことは目に見えている。それでも、そういう攻撃を受けるまでは、べつにそれでかまわない。サイト横断的なspamに対しては。

江島氏が書いている後半の途中までの内容はそういう話(パラメタ名を変える代わりに、別のもう1つのパラメタを必要とするようにするという方法の話)で、その後、さらにspamボット側の負荷を増大させる策などを挙げている。(JavaScriptを使う話はむしろオマケ。)

このようなやり方は、「spamするならうちより他へ行ったほうがいいよ」戦略であり、サイト横断的な無差別spamには通用する話であっても、何らかの原因で、ピンポイント爆撃の標的として狙いを定められてしまった場合には、通用しない。

Googleは言うまでもなく、世界の頂点に君臨する超メジャーサイトであり、あらゆる目的でspam行為の標的として狙いを定められている。だから、「うちより他へ」戦略は通用しないわけで、世界で最も高度なCAPTCHAを採用する以外にないわけだ。江島氏が言うような「調子に乗ってどんどん強度を上げ」ているわけではあるまい。

では、江島氏は何を言いたかったのか。おそらくこういうことだろう。「身の丈を知らないマイナーサイトがこぞってCAPTHCAを導入しているのはマヌケだ」と。私もそう思う。江島氏の運営するサイトもきっとマイナーサイトに違いない。

サイト横断的無差別spamの対策を語る文脈で、「マイナーなサイトなら簡単な画像認証を使えばいい」と言う人がいる。だが、たとえ簡単であろうと、正規利用者の手を煩わすわけだから、正規利用者が何も入力せずに済む方法をまず先に試してみようよと、それが江島氏の言いたいことだろう。(私もアイデアを出すなら、「ダミーを含む形でコメントフォームがたくさんあって、本物である1つを除いて(何らかの方法で)不可視にされている」という方法なんかはどうだろうか。)

一方、コメントspamの話ではなく、新規ユーザ登録機能に対する自動登録攻撃の話となると話が違う。Googleほどではないにしても、はてなくらいの人気度があると、自動ユーザ登録を目的にしたピンポイント攻撃の標的にされる。標的にされてしまったら、正規利用者にも何かを入力させるCAPTCHAを採用せざるを得ないだろう。新規登録は、最初に一回するだけなのだから、このくらいは我慢して使うべきだろう。

ところで、昨年10月に「はてなのCAPTCHAは簡単に破れる」という話があった。

もちろん、技術的にそうだという話をするのはいいのだが、これを見て、「これじゃ全然だめ」だの、「はてな、なんとかしろ」だのとぬかすバカが出てきて困る。まだ荒らされてもいないのに、わざわざイタチごっこの手を自ら先に進めることもあるまい。やられたら次の手に進められるよう準備しておけばいいだけの話だ。荒らし対策の話は、脆弱性対策の話とは異なる。荒らしはしょせん程度問題であるし、取り返しのつかない被害が即座に出るわけでもない。

その点、2006年8月10日の日記「飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき」の件は話の前提が違う。これは荒らし対策ではなかった。今だから言えるが、これはある意味、脆弱性対策として導入されたものであろう。

このサイトは、長年、数字4桁の暗証番号でのログインを許してきた(ここ数年、そんなサイトは他に存在しない)。数字4桁の暗証番号は、ATMなどの公共の場にある物理機器では妥当であり得ても、インターネット経由の認証には許されないレベルの弱さである。このことは以前から各所で言われてきたし私も講演等で言ってきた。口座番号の方を変えながら繰り返し試されたら、ロックをかけることもできず、数千回程度の試行で突破できる口座が見つかってしまう。

CAPTCHAを導入すれば自動化された攻撃を防止できる。しかし、その目的の場合、そのCAPTCHAは絶対に破られることのないレベルの高度なものでなくてはならない。無差別spamtとは違い、このサイトが標的にされた状況を想定しているのであるし、取り返しのつかない被害の防止を目的としているからだ。それなのに、見ただけですぐ、どうすれば突破できるかわかるような仕掛けを採用していたのが問題であった。

そのサイトはその後、誕生日の入力を必要とするように対策された。これにより、突破される確率が数千分の一程度に抑えられたと言える。

そもそも、この目的では、CAPTCHAを採用するというアイデア自体が誤りであった。なぜなら、CAPTCHAに完全なものはあり得ないのであって、荒らし対策用のものだからだ。

ちなみに、Googleなどのように、パスワードを間違えたときにCAPTCHAが出るようになっているサイトもあるが、これもまた別の目的であるという点に注意が必要である。Googleなどでは、パスワードはユーザが自由に決められるのであるから、正しく設定すれば、上に書いたような方法で破られることはない。破られるのは、安易なパスワードを設定したユーザの責任である。それでもなおCAPTCHAによる対策を設けるというのは、そのようなユーザに対するサービスだと考えるべきものだろう(あるいは、弱いパスワードのアカウントが荒らし目的で不正使用されることを防止する目的のもの)。それに対して、4桁数字の暗証番号をユーザに強要しているサイトでは、サイト運営者に責任があるのであって、話が違う。

というわけで、CAPTCHAは荒らし対策用である。荒らし対策は、荒らされたら対応すればいい。荒らされてもいないのに、ユーザビリティを犠牲にしたCAPTCHAを導入するのはマヌケである。無差別spam対策なら、「他でやって」戦略をとる余地がまだある。標的にされているメジャーなところが、ユーザビリティを犠牲にするのは、他にどうしようもなく、しかたがない。

はてなの、新規ユーザ登録機能の防御は、現状ではおおむね必要十分なのだろう。ここで、はてなの新規ユーザ登録のCAPTCHAを突破して荒らす遊びを実行にうつすガキが出てきたら、そういうクソガキは村民でよってたかってdisるのがいい。業務妨害容疑で告発するのもよかろう。

一方、コメントspam対策はどうか。これは、blog主ごとに事情が異なるだろう。ホットエントリに上がったblogは、spamの標的に選ばれることがある。頻繁に注目を浴びるblogでは、ユーザビリティを犠牲にしてでもCAPTCHAを導入したいという事態になるかもしれない。一方、単なる無差別spamを防ぎたいだけのblogでは、江島氏が言うように、ユーザビリティを下げない簡易対策で当面十分だろう。

自分のドメインでblogを管理している者は自分のやりたいようにできるが、blogサービスを利用している場合はそうはいかない。そういった所で、spam対策のレベルを好きなように調整できないことが、江島氏のような不満を生んでいるのではないだろうか。

であれば、blogサービスの理想的な形は、「弱いが不便でない ←→ 強いが不便」の様々なレベルの仕掛けを用意して、各blog主が選択できるようにすることではないだろうか。

本日のリンク元 TrackBacks(3)

2008年03月09日

国民生活センターの不適切なアドバイス事例

国民生活センターのサイトに「あわてないで!! クリックしただけで、いきなり料金請求する手口」という、いわゆるワンクリック不当請求に対する注意喚起が掲載されている。2004年12月に公表されたものであるが、現在もセンターのトップページから案内されており、消費者に知らせるだけでなく、消費生活専門相談員や消費生活アドバイザーらのバイブルとして活用されていると思われる。

しかしながら、この資料うち、携帯電話の場合について解説された以下のページには、不適切なアドバイスがあり、これは修正するべきである。

  • 携帯電話を利用した クリックしただけで、いきなり料金請求する手口, 国民生活センター, 2004年12月13日

    ※サイトアクセスしただけで契約者名等の情報が伝わることは絶対にありません。

    3. アドバイス

    (2) 個体識別番号”から個人情報は伝わらないため、必要以上に不安にならないこと

    “個体識別番号”から個人情報が伝わることはないので、このようなサイトにアクセスしてしまっても慌てないことが大切です。画面上に表示されている他のボタンをクリックしないよう注意し、トラブルに巻き込まれたときに備えて画面やサイト名、URLなどを記録、保存しておきましょう。

    国民生活センターの注意喚起ページの画面

この解説の図に、「携帯電話情報を送信しますか? YES / NO」という画面が掲載されているが、これは、携帯電話が出すプライバシー警告のダイアログであろう。NTTドコモの場合では、携帯電話の製造番号(あるいは、FOMA端末製造番号、FOMAカード製造番号)を送信しようとするとき(送信するよう仕掛けられたWebページにアクセスしたとき)に、この「携帯電話情報を送信しますか?」という警告ダイアログが出るようになっている。

国民生活センターのこの解説を読むと、この警告ダイアログで「YES」を選択しても「NO」を選択しても同じだという理解をさせてしまう。そして、「契約者名等の情報が伝わることは絶対にありません」、「個体識別番号から個人情報は伝わらない」と解説されているので、「YES」を選択しても何ら問題がないと理解させてしまう。

だが、そもそも、なぜ、わざわざ「YES」か「NO」か選ばせる仕組みになっているのか。確認なしに常時送信するのではなく、ユーザの同意を求めてから送信する設計をしたのは、NTTドコモ自身が、「NO」を選択しなければならないような状況があることを想定しているからであろう。

つまり、信頼できないサイトでは「YES」を選択せず、「NO」を選択しなければならないこと、そのことを啓蒙するべきである。

NTTドコモは、携帯電話の取扱説明書などでこの確認画面の意味を説明する際に、どういう場合に「NO」を選択する必要があるのか説明する義務があると私は思う。しかし、2004年8月29日の日記「最小限の責任だけで済ます携帯電話会社たち」で書いたように、彼らは、「YES」を押しても大丈夫であるかのようなことを言い、「『NO』を押してください」ということを言わない。

NTTドコモの技術者らは、「NO」を選ばないといけないときがあるのを知っているから、このように設計したのであろう。技術者の良心がうかがえる。それに対し、ユーザへの注意喚起文を書く広報担当者は、「とにかく問題はないことにしたい」という気持ちが働くのか、肝心のなすべきアドバイスを言わずに、危険の存在を隠してしまう。

営利企業とはそういうものだからしかたない。だからこそ、国民生活センターという組織がある。企業が短期的な利益しか考えず、危険を隠すような行動をとるときに、国民生活センターは、その危険を広く国民に伝え、注意を促すのが役割のはずだ。

だから、この注意喚起では、「絶対に『YES』を押さないで」ということを言うべきである。

「信頼できるサイト」と「信頼できないサイト」という概念を消費者に啓蒙し、携帯電話情報を送信してかまわないのはどういうときなのかということを啓蒙するべきである。

ワンクリック不当請求の場合、「請求されても支払わなくてよい」ということを伝えなくてはならないため、「個体識別番号を特定しました」といった脅しは無視するようアドバイスすることになる。その趣旨は理解できる。だが、その思いが高じて、個体識別番号を「YES」で送信してしまってかまわないとまで言ってしまうのは間違いだ。

携帯電話の個体識別番号は、インターネットのIPアドレスとは異なり、個人が特定され得るものである。

このことは、2003年に相模原の国民生活センターを会場として開かれた講座の中でも、以下の図1のように説明している。

講演スライド1 講演スライド2 講演スライド3
図1: 2003年7月の講演で使用したスライドより

住所、氏名も同様のシナリオによって悪質サイトに特定されることが起こり得る。

  1. ユーザXが、マイナーな携帯電話向けネットショップYを訪れて、買い物をする。Xは、商品の送り先として、自分の住所氏名を記入してYに送信する。Yは合法なサイトで、商品もちゃんと送られてくる。
  2. しかし、Yは、顧客が5000人以下で個人情報保護法の個人情報取扱事業者に該当しないとの認識から、顧客リストを売却してしまう。
  3. Yは、ネットショップで住所氏名を記入させる際、不正防止の目的で携帯電話の個体識別番号(携帯電話製造番号等)も合わせて記録していた。売却された名簿には、住所氏名に個体識別番号も併記されていた。
  4. ワンクリック不当請求で詐欺まがいの行為をしているZが、このYが売却した名簿を入手する。
  5. ユーザXは、リンクを辿ってたまたまワンクリック不当請求サイトを訪れる。そこはZが運営するサイトであった。このときXは、NTTドコモの「携帯電話情報を送信しますか?」の警告ダイアログに対し「YES」を押してしまう。
  6. すると、Xの携帯電話に、Xの住所と氏名が画面に表示される。(もしくは表示はされなかったが、)後に、郵便で請求書が送られてくる。

こういうことは現に起きているのではないのか。私は被害の情報を入手する立場にないので知らない。

それなのに、国民生活センターの注意喚起は次のように言っている。

●画面に表示される“個体識別番号”について●

これらの業者がいう“個体識別番号”(“固体識別番号”と表記しているものもある)には、現在判明しているもので下記のパターンがあります(下図参照)。

(1)携帯電話会社名と端末の機種

(2)業者が勝手に付与したID(どの携帯電話からアクセスしても同じIDのものと変化するものがある)

こういった情報には、アクセスした消費者の氏名や住所、携帯電話番号等の個人情報は含まれていないため、業者に個人情報が伝わることはありません。また、IDも業者が勝手に付与したものであり、個人情報とは何ら関係がありません。

その他、消費者のメールアドレスやアクセスエリアが表示されることもありますが、いずれにしても個人情報が特定されるわけではありません。これらの業者は“個体識別番号”などを画面に表示することで、あたかも個人情報を入手したかのように思わせることを狙っているものと考えられます。

携帯電話を利用した クリックしただけで、いきなり料金請求する手口, 国民生活センター, 2004年12月13日

少なくとも、「現在判明しているもので下記のパターンがあります……(1)…… (2)……」という記述は、事実誤認で、明確に誤りである。例えばこの報道の例では、携帯電話製造番号を送信させて、本物の携帯電話製造番号をサイト上に表示している様子(「機種」と書かれたUser-Agent:のモザイク部分)が掲載されている。

「携帯電話会社名と端末の機種」と「業者が勝手に付与したID」の事例しか見つかっていないというのは誤りである。しかも、それからもう何年も経っている。

もし、ワンクリック不正請求サイトで住所氏名が表示されたという経験をお持ちの方がいらしたら、国民生活センターに通報するか、私までメール(blog@takagi-hiromitsu.jp)で教えていただきたい。

該当するのは以下の条件を満たす方。

  • 携帯電話で、ネットショップなどに、住所氏名を送信したことがある。
  • 同じ携帯電話で、ワンクリック不当請求サイトを訪れたときに、その住所氏名が表示されたことがある。

本日のリンク元 TrackBack(0)

2008年03月12日

Amazonはやっぱり怖い そろそろ使うのをやめようと思う

今は朝6時。数時間前、寝ようとしたころに大騒ぎになっていた。

これはひどいことになった。HATENA Co., LTD. では暗号解読の本をお求めのようだった。

幸い私は、ウィッシュリストを空にしていたので、何も見られることはなかったが、自分のAmazon登録メールアドレスを入れると、氏名と「茨城県」などの情報が表示された。(メールアドレスも非公開のものを使っているが、ワイルドカード指定もできたようなので、どうなっていたかわからない。もっとも、私は実名を隠していないが。)

そもそも何年か前、この「ウィッシュリスト」なるサービスが始まったとき、やたらウイッシュリストへの登録が促されたので、てっきり「あとで買う」みたいな機能かと思って、何だったかを登録してしまった記憶がある。何分かかかって、これが他人に公開するための機能だと気づいて、リストからあわてて削除した。そのとき説明が悪すぎると感じたのを思い出した。先週から「ほしい物リスト」という名前に変更したそうだが、さらに誤解する人が続出するのではないか。1クリックで登録してしまうようだし。

Amazonはオープン当初から使っているが、他にも嫌な経験をした。「マーケットプレイス」は使わないようにしていたが、在庫がなくAmazon外の業者から買わざるを得ず、初めて利用したとき、Amazonから「評価してください」というメールが来たので、コメント付きで評価を記入したところ、実名でそのコメントが公開されてしまった。これが私としたことが予想外だった。何をすると何が起きるかの説明が足りていないのではないか。

注文履歴を全部消去したいのだが、可能なのだろうか? 9時になったら電話してみよう。2000年からの注文履歴が今も全部閲覧可能になっているのが嫌だ。

Amazonは注文履歴の消去を拒否、アカウント閉鎖後もデータは残る

今は夜。今日、amazon.co.jpのカスタマーサービスに電話して、注文履歴を消してくれないかと相談してみた。そのときのやり取りは次のようになった。


私: 注文履歴を削除したいのですが、どうやったらいいでしょうか?

アマ: はい、大変申し訳ないのですが、注文履歴自体の削除というのは当サイトの方でも、システム上できかねますのでー。

私: え? できないんですか?

アマ: はい。

私: どうやっても消えないんですか?

アマ: そうですね、あのー、別アカウントを作成していただくか、もしくは、アカウント自体を閉鎖していただく必要というのはございます。

私: アカウントを閉鎖すると、データは消えるんですか?

アマ: あのー、そのご注文のあるアカウントにサインインできなくなりますのでー、

私: データが消えるかと聞いてるんですよ。

アマ: データはですね、取引上の記録となりますので、まずあの、完全な削除というのは承っておりません。

(以下略)


そこで、東京都消費生活総合センターに電話して相談した。やり取りはおおむね次のようになった。


私: ネットショップを利用していまして、Amazonという。これは過去に買ったものの記録が全部残っているわけですね。

東京都: はい。

私: で、8年前から使っていたわけですけども、全部記録されていて、

東京都: Amazonの方にということですか?

私: そうですね。自分で見たりできるんですけども。今朝、Amazonで情報流出事故が発生したので、怖いと思いまして、

東京都: はい。

私: 全部消して欲しいというふうに電話したんですが、消すことはできませんと、いうふうに言われました。それは何か法律上、対抗措置というのはないんでしょうか。消して欲しいという。

東京都: あー、でいないと言われましたかー。

私: はい。

東京都: そうですかー。Amazonさんてけっこうお客さまの数、多ございますよね。個人情報保護法という法律がございまして、その法律に拘束される事業者さんというのは、過去6か月において5000人以上の事業者さんに当たるんじゃないかと思うんですね、Amazonさんは。

私: ええ。

東京都: なのでー、その法律によれば、お客様の方からですね、消してねと言われたときには、きちんとした対応をする責務があることになっています。

私: はあ。

東京都: それで、対応について、法律上問題があるかどうかについては、私どもではなくですね、内閣府の国民生活局個人情報保護推進室というところが対応いたしますので、そちらの電話番号が(略)でございますので、そちらに苦情を入れていただけますか?

私: はい。そのようにいたします。


というわけで、内閣府国民生活局個人情報保護推進室に電話することになった。やり取りはおおむね次のようになった。


私: 東京都の消費生活センターに電話したらこちらに相談するようにと言われまして、

内閣府: 東京都の消費生活センターですか?

私: はい。

内閣府: こちらでは法律の解釈についてしか相談を受けれないんですが、それでよろしいでしょうか?

私: ええ。何があったかといいいますと、ネットショッピングの、Amazon.co.jpというサイトがありますが、ここが今朝、個人情報を流出させる事故が発生してネットで騒ぎになっているんですけども、

内閣府: あ、そうですか。

私: 私も心配になりましたので、こんなサイトに自分の情報が預けてあることがですね、なにぶん開店当初から使っていまして、8年分のいろんな買った物のすべての履歴がそのサイトには残ってまして、実際こう、自分で過去の履歴が見れる状態なんですね。

内閣府: 自分で自分の過去の履歴を見れると。

私: はい。しかし今朝起きた事故のようなことを考えれば、いつそれが流出するかもわからない、という心配になりましたので、過去の自分の買った物の履歴ですね、これを消してほしいと、いうことをAmazonに電話しまして、求めたところ、できませんと、言われました。

内閣府: 自分の履歴を削除してくれと言ったら、できないと言われた。

私: はい。アカウントごと停止にすることはできるというので、停止だっていうんですね、削除ではなくて、ログインできなくすることはできるけども、データは消すわけじゃないと、言うんですよ。

内閣府: はい。

私: それは困ると。流出したら困るから、消してほしいと言っているわけだから、それじゃ困りますと、データを消してほしいと言ったところ、それはできないことになっていますと、言うんですよ。それは、個人情報保護法的におかしいんじゃないかと、

内閣府: えっとまああの……、インターネットのアレですよね、ちょっとお待ちくださいね。

(オルゴール)

内閣府: お話はとてもよくわかったんですけどー、個人情報保護法上ではー、そういう、あのー、Amazonさんの方が、間違ったことを言ってないんですね。

私: ほう。

内閣府: この法律上は、25条、26条、27条といろいろ、開示とか訂正とか利用停止とかあるんですけども、何か例えばですね、全部消去とか削除とかしてしまって、後から問題が起きて裁判になったときに、それの証拠がなくなるってことなんですよね。

私: はあ。

内閣府: それで、ログインできないようにすることならできますよっていう、Amazonさん側の言い分は、間違ってないと思われます。

私: つまり、そういった情報は削除を求めることは、

内閣府: できないですね、法律上は。

私: へー。何の役にも立たない法律ですね。

内閣府: ……。何かそのことで裁判とか起きたときに、

私: でも普通、履歴なんて何年も10年も保管するものですかね?

内閣府: まああの、利用停止っていうことで、利用停止を求められればいいと思いますけども、Amazonさん側に対して。

私: たとえば、10年も保存する必要ってあるんですかね、何か裁判上の都合で。

内閣府: いやーちょっとその年数はわからないんですけども。はい。その事業所事業所のことなので、たとえば電話会社なんて莫大な情報になるのでたぶん長く持ってないと思いますし、

私: はい。

内閣府: まあ、その事業者、事業者の判断でやっていることだと思います。

私: ははあ。なるほど。個人情報保護法では何ら拘束力がないと。

内閣府: そうですね、だから利用停止ってことで、

私: 削除って何かありませんでしたっけ?

内閣府: 間違ったことを訂正して消してもらうってことはできても、

私: はあ、なるほど。

内閣府: こちらでは法律の解釈しか言えなくって、もし個々の苦情処理の窓口が、認定個人情報保護団体というのがあるので、データ通信協会というのがあるので、もし、よかったら電話番号ご紹介しますけども、

私: あー、データ通信協会ねえ。まあ聞いてみましょうか。


というわけで、データ通信協会に電話した。


私: 今、内閣府の個人情報保護推進に電話したところ、個別の案件についてはこちらへということで、紹介いただいたんですけども、個人情報保護に関する相談窓口ということで、こちらでよろしいでしょうか?

デー: はい。

私: 何があったかと言いますと、Amazon.co.jpというネットショップがありますけども、今朝(略)8年間買ったもののすべてがいまも蓄積されていて(略)

デー: ちょっとお待ちくださいね、えーと、こちらはああの、電気通信関係の認定個人情報保護団体ということで、Amazonさんというのは、対象事業者になっていないんで、

私: ああー、そうですか。内閣府国民生活局個人情報保護推進室から言われたんですけどね、

デー: あの、こちら電気通信関係のですね、

私: ようするに、内閣府の紹介は間違いだったということですよね。


というわけで終了。

次に、他に使っているネットショップはどうかなということで、同じく8年間愛用してきた、ソニースタイルに聞いてみた。

ソニースタイルも、購入履歴を見ると8年前まで全部の記録が閲覧できるようになっている。「記録を消してくださいと言えば消してもらえるんでしょうか?」と問い合わせたところ、「専用書類を用意しているので、そちらに記入して提出いただければ一切の情報を削除する」とのことだった。

ちなみに、それをやってしまうと、せっかく貯めたスター(長期利用者の指標値)もリセットになってしまうわけで、本当にさよならするときまで断行できない。

私が思い描く理想的なネットショップ像としては、1年くらいで古い購入履歴が自動的に消えていくようになっていて欲しいものだ。8年も前の履歴が残っていて、意味があるのかわからない。

ここ数年で思い知らされているように、情報はいずれ流出する。どんなに守っても、漏洩しないかどうかは確率的な事象であり、あらゆる情報が流出する可能性はいくらかずつ存在している。そんな世の中なのだから、無用な情報はどんどん消していくのが正解ではないだろうか。

日本で本格的なネットショップが登場して、まだ8年しか経っていない。もうすぐ10年の節目を迎えるわけだけども、今後も20年、30年と永遠に注文履歴を蓄積し続けていくつもりなのだろうか。

これまでは、とりあえず消さないで行くという方針だったのかもしれないが、そろそろ考え方を変えて、情報を消していくことによる安心を提供するという、新しい理念に基づいたネットショップが登場してもよいころではないだろうか。

Amazonで私の情報は私の意志に反してどう表示されていたか

私は、数年前に、ウィッシュリスト機能がamazon.co.jpに追加されたころ、初めて「ウィッシュリストに追加」ボタンを見たとき、何だかわからずにボタンを押した。ボタンを押した後の画面を見てもそれが何なのかよくわからなかったが、少し調べて、「家族や友人に」限定して公開されるわけではなく、全世界に公開されるものだと気づき、リストに追加してしまった商品を削除した。そして、そのままにした。その後、ウィッシュリストは触らないようにしていた。

そして今朝、騒ぎを見て、「ほしい物リスト」に改名されたウィッシュリストで、自分のメールアドレスを入力して検索してみると、以下の画面が現れた。

図1: 2008年3月12日早朝の時点での私のウィッシュリスト

ここで、氏名が2か所で表示されている。1つは「作成者」とある部分の氏名で、もうひとつは「お届け先住所」とある部分の氏名と都道府県である。

私は上のエントリにも書いたように、昨年、やむを得ず「マーケットプレイス」を初めて使った際に、Amazonから来た「評価してください」というメールに従ったところ、評価コメントが実名で書き込まれてしまった。(このとき、プレビュー画面さえなく、いきなり書き込まれた。)修正することも消すこともできず、その件は諦めるしかなかったが、このとき、「こんにちは、高木浩光 さん。」と表示される部分の氏名については、仮名に変更していた。

それなのに、ウィッシュリストで表示される「作成者」の名前は、以前のままだった。つまり、アカウント設定画面で設定する名前とは別に、ウィッシュリストの作成者名も管理しないといけないわけだ。

INTERNET Watchの記事には次のように書かれているが、それは事実誤認である。

  • Amazonの「ほしい物リスト」が初期設定で公開される仕組みが話題に, INTERNET Watch, 2008年3月12日

    このうち、商品と作成者名は、リストを公開していれば誰でも表示されるが、誕生日、自己紹介、届け先住所については、ほしい物リストの設定を変更しなければ表示されない。メールアドレスについては、自己紹介欄に記載していなければ公開されることはない。

自分で設定しなければ公開されないと書かれているが、私は何も設定していないのに、「お届け先住所: 高木浩光 - 茨城県」と表示される状態になっていた。

たしかに、今、新しいアカウントを作成して確かめてみたところ、アドレス帳を設定したうえで、ウィッシュリストに商品を追加しても、ウィッシュリストの「お届け先住所」は「登録情報がありません」となる。

おそらく、ウィッシュリスト機能が追加されたばかりの数年前の時点では、ウィッシュリストに一度でも何か追加した人は、自動的に「お届け先住所」が公開される実装になっていたのではないか。それがその後、誰かから苦情があったのか、これではまずいと運営者が気づいたのか、「お届け先住所」を初期設定で公開とするのはやめたということではないだろうか。

そうであれば、その変更をした時点で、既に登録済みになっている利用者達について、強制的に設定を変更するなり、利用者に事情を告知するなり、運営者は対応をとるべきだったはずだ。そういう連絡をもらった記憶はない。

朝日新聞の報道によると、アマゾンの広報はこう釈明しているそうだ。

  • アマゾン「ほしい物リスト」、他人に丸見え 本名も表示, 朝日新聞, 2008年3月12日

    サイトを運営するアマゾンジャパンの広報担当者は「公開になるという説明は、必ず目につくような場所につけている。設定の変更もできるようになっている」と説明。「そもそも、ほしい物リストは、アメリカの文化で、友人や家族にプレゼントして欲しいものをあらかじめリスト化する習慣に合わせてできた機能。公開して使うことが前提になっている」としている。

「ウィッシュリスト」を見に行かない限り、その説明を見ることはない。

こんな対応をする連中が運営しているサイトなんか危なっかしくて使っていられない。米国の amazon.com では、Wish list の初期設定は「非公開」になっており、「Make this list public」というボタンを押さない限り公開されることはない。米国の amazon.com は10年以上前から使っているが、確認したところ、私の Wish listは非公開になっていた*1

アカウントを停止すると、それこそ何もできなくなる恐れがあるのでこのままにするが、これ以上、注文履歴を増やさないようにしようと思う。(amazon.comは使うけど。)

*1 同姓同名の人がいるようだ。Blade RunnerのDVDをご所望のようだが、それは私ではない。

本日のリンク元 TrackBacks(100)

2008年03月15日

ハマチをちゃんとテリヤキにするのは難しい

焦げた。失敗。

CSRF脆弱性を突く攻撃行為を現行法で処罰できるか

CSRF脆弱性が攻撃されることは、それがもたらす被害の内容によっては、不正アクセス禁止法が守ろうとしているものと同等のものが侵害される場合もある。たとえば、本人でなければ見ることのできないはずの情報が、CSRF脆弱性を突く罠を仕掛けた者に送信されるといった攻撃は、不正アクセス行為の典型的な侵害事例と同様の被害をもたらす。また、同法の目的である「アクセス制御機能により実現される電気通信に関する秩序の維持」(第1条)が損なわれるという点も共通する。

しかしながら、CSRF脆弱性を突く攻撃行為は、結果が同じてあっても手段が異なるために、不正アクセス禁止法による処罰は難しいのではないかと以前から思っていた。これについては、2005年7月3日の日記「クロスサイトリクエストフォージェリ(CSRF)対策がいまいち進まなかったのはなぜか」にも書いた。

問題提起が憚られるもうひとつの理由

(略)CSRFによる被害が出たとき、罠を仕掛けた攻撃者の行為は、日本の法律に照らして違法となるだろうか?

アクセスをするのは被害者自身によるものであるし、そのアクセス自体は制限された利用の制限を免れるものではないので、不正アクセス禁止法には触れないと思われる。(略)

刑法改正で予定されている「不正指令電磁的記録作成等の罪」ならば、こうした行為を罪に問えるかもしれない。これは俗に「ウイルス作成罪」と呼ばれてきたものであるが、改正案の条文は次のようになっており、いわゆるウイルスのみでなく、受動的攻撃全般をも指すようにも解釈できそうである。

人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録

この法改正が必要とされていることからも、現行法で受動的攻撃のようなものをカバーしきれていないことがうかがえるところであり、この刑法改正は、 CSRF攻撃も抑止できるかもしれないという意味で歓迎されるところである*3が、去年もこの改正は見送られており、いまだその抑止効果は有効になっていない。

この状況で下手にCSRFの危険性を主張しはじめると、違法でなければ何をやってもよいという輩が、悪戯を繰り返して被害を出しかねないという懸念もあったのではなかろうか。

XSS脆弱性の場合は、罠によって他人に他所のドメインのページの画面上でスクリプトを実行させるところまでは、CSRF同様に罪に問えないと思われるが、それによって盗んだcookie(セッションID)を使って当該サイトにセッションハイジャックのアクセスをした時点で、不正アクセス禁止法3条2項2号違反となると思われるため、安心して啓発活動をすることができた。

そうした法律による保護が、CSRFに対してはまだできていないため、誰も問題提起せずに来てしまったのではなかろうか。

(略)荒らし行為では済まないような(つまり、情報漏洩など、取り返しのつかない結果をもたらす) CSRF脆弱性についてはいまこそ対策を進めるべきであろう。

たとえば、人が死ぬような罠を人を殺すつもりで仕掛けた者がいて、その罠を自ら踏むことで自分で自分を死に至らしめる人が出たとき、その罠を仕掛けた者は殺人罪に問われるかといえば、問われるのだろう。

刑法第199条

人を殺した者は、死刑又は無期若しくは五年以上の懲役に処する。

それに対し、情報が漏洩するような罠を情報を漏洩させるつもりで仕掛けた者がいて、その罠を自ら踏むことで自分で自分の情報を漏洩させる人が出たとき、その罠を仕掛けた者はどの罪に問われ得るか。

まず、情報を漏洩させること自体は違法とされていない。日本の法律には「情報窃盗罪」という規定はなく、不正アクセス禁止法や不正競争防止法などにより、一部の形態についてのみ処罰されるようになっている。そのため、上のような殺人罪との対比は意味がない。

では、不正アクセスを殺人と対比してみるとどうだろうか。

不正アクセスが生ずるような罠を、不正アクセスを生じさせるつもりで仕掛けた者がいて、その罠を自ら踏むことで自分で不正アクセスを生じさせる人が出たとき、その罠を仕掛けた者は不正アクセス禁止法違反の罪に問われるか。

ここでは、「人が死ぬ」←→「不正アクセスが生じる」と対比させている。殺人罪は、人が死ぬようにすることを罪としているわけだが、それに対し、不正アクセス禁止法は、はたして、「不正アクセスが生じるようにすることを禁止している」とみなせるだろうか?

不正アクセス禁止法は第3条1項で、「何人も、不正アクセス行為をしてはならない。」とし、同2項で「不正アクセス行為」を定義している。その定義によれば、不正アクセス行為とは、「他人の識別符号」や「制限を免れる情報又は指令」を「入力して電子計算機を作動させ」ることを要件としている。

ここで次の例を検討してみる。SQLインジェクション脆弱性のあるWebサイトがあり、以下のURLにアクセスするだけで、ウイルスを埋め込む改竄ができてしまう状態になっているとする。

http://www.example.com/virusencyclo/default.asp?name='〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

もちろん、そういう結果をもたらすことを知りながらこのURLで当該サイトにアクセスした者は、不正アクセス禁止法第3条2項2号(もしくは3号)違反で罪に問われるわけだが、では、自分で手を下さずに、このURLを、誰かがアクセスするであろうことを期待しながら、自分のblogに記載したり、掲示板に貼付けるなどして、同じ結果をもたらした場合はどうなんだろうか。

ここで、そのURLにアクセスした人が、何が起きるのかを知らずにアクセスしたのなら、それは不正アクセス行為の故意が認められないので、その人が罪に問われるものではない。したがって、その状況においては、罠を仕掛けた者について幇助犯や教唆犯という話にはならないのではないか。

不正アクセス禁止法第3条2項は、不正アクセス行為の定義として、「電気通信回線を通じて入力して電子計算機を作動させ」とあまりにも明確な要件を挙げているので、自分の手でアクセスした場合でなければ処罰できないように読めるのだが、どうなんだろうか。定番解説書である「逐条 不正アクセス行為の禁止等に関する法律」(立花書房)にもこのケースについての検討が書かれていない*1。私にはよくわからない。法律の専門家の方々の見解を伺いたい。(もっとも、上の例の場合は、電子計算機損壊等業務妨害罪の方で処罰できるのだろうけども。)

では次に、CSRF攻撃の場合にはどうか。

CSRF脆弱性を突いた攻撃というのは、その仕組み上、当該サイトへのアクセスは利用権者本人によるアクセスとなる。したがって、不正アクセス行為の定義にある、「当該アクセス制御機能により制限されている利用をし得る状態にさせる行為」の「制限されている利用」というのが、誰にとっての「制限されている」なのかという点が鍵となる。

行為の主体をアクセスした人とするなら、CSRFによるアクセスは利用権者本人によるものであるから、「制限されている利用をし得る状態にさせ」てはいないことになる。

行為の主体を罠を仕掛けた者とするなら、罠を仕掛けた者からすれば、「制限されている利用」をしていることになる(場合がある)。たとえば、他人の識別符号でサインインしなければ閲覧できないはずの個人情報を、CSRFの罠をblogや掲示板に書くことによって、そこにアクセスした人の当該情報を自分宛に送信させる行為は、「制限されてる利用」をしている。

しかし、まず第一に、上で検討したように、罠の設置によって他人にさせる行為が、はたして、「電気通信回線を通じて入力して電子計算機を作動させ」という要件を満たすのかが疑問であるから、罠の設置者が不正アクセス行為の行為主体となり得ないようにも思えるが、この点は上に書いたように法律の専門家に伺わなければわからない。

そして第二に、仮に、罠を踏ませる行為が「電気通信回線を通じて入力して電子計算機を作動させ」に該当するとしても、何を「入力して」いるのかが問題となる。上のSQLインジェクションの例では、「利用の制限を免れることができる情報又は指令」を用意したのは、罠の設置者であるから、罠の設置者が「電気通信回線を通じて入力して」いることとなり、不正アクセス行為と見なされ得るのに対し、CSRF攻撃の場合では、たとえば、回避しようとするアクセス制御機能がBasic認証なら、パスワードを送信させることになるのだから、「入力して作動させ」というのは「識別符号を入力して作動させ」のことだが、その識別符号は、行為主体である罠の設置者が用意したものではない。それなのに、罠の設置者が「識別符号を電気通信回線を通じて入力して」いると言えるのだろうか?

同様に、アクセス制御機能がセッションIDによるセッション追跡方式で実現されている場合でも、セッションIDが「利用の制限を免れることができる情報又は指令」に該当するとしても、それを用意したのは罠の設置者ではない。

このように、1999年8月に公布された不正アクセス禁止法は、定義をあまりにも明確にしすぎたために、同じ被害をもたらす悪質な行為であっても、CSRFという手法で自分の手を汚さないようにすることで、処罰を逃れられてしまっているように思う。

そこで、先日のウイルス作者逮捕報道の際にも話題になった、いわゆる「ウイルス罪」の法案(不正指令電磁的記録に関する罪を新設する刑法改正案)に期待するところである。

「ウイルス」と言うと、CSRFとは別物のように思われるかもしれないが、不正指令電磁的記録供用罪というのは、「人が電子計算機を使用するに際してその意図に反する動作をさせるべき不正な指令」を実行させる行為を処罰するものであるから、まさにCSRFの罠を踏ませる行為がこれに該当すると思う。

該当しないかもしれないとすれば、URLが「指令を与える電磁的記録」と言えるかどうかという点くらいではないだろうか。法制審議会の議事録によると、「指令を与える電磁的記録」とはプログラムファイルのことを想定しているようなので、URLがプログラムと言えるかということになる。まあ、技術者視点で言えば、プログラムと言って差し支えないんじゃないかと私は思う。

どんな単純なプログラムであれ、どんな目的であれ、人を騙して実行させる行為は悪いことであり、結果が悪質なものであれば処罰の対象となってしかるべきだと思う。Winny媒介型ウイルスが蔓延して悲惨な被害が続出し続けているのは、この法律に頼るしかないのに法案が国会で真面目に取り扱われていないためである。その間に、日本社会は、「ウイルスマンセー」とでも言わんばかりの風潮が広まり、誰もそれを嗜めない狂った文化が育ってしまった。匿名掲示板でその手のことが書かれるのはまあ致し方ないにしても、blog上で名乗りながら、「警察があんまりがんばってWinnyからウィルスがなくなってしまうと、安心してまたユーザーが増えてしまうのではないでしょうか?」などと不謹慎なことを堂々と言う人まで現れる始末だ。匿名掲示板ならまだしも、表で名乗りながらそうする人が出てくると、その空気に飲み込まれていく人が続出するという点できわめて厄介だ。

やはり、文化というものは法律によっても醸成されていくものであって、早くこの法律が成立、施行されることを願うばかりだ。

とはいえ、どんなに早くても何年か先になってしまう。現行法でどうにか悪質なCSRF攻撃を実行に移す輩を処罰できないものだろうか。

このままでは、いつ購入履歴を暴露されるかわからないという不安にかられ、安心してネットショッピングもままならない。まさに、不正アクセス禁止法の「アクセス制御機能により実現される電気通信に関する秩序の維持を図り、もって高度情報通信社会の健全な発展に寄与する」という目的が阻害されている状況である。定番解説本にも次のように書かれている。

本法の直接の目的の第二は、「アクセス制御機能により実現される電気通信に関する秩序の維持を図」ることである。「アクセス制御機能により実現される電気通信に関する秩序」とは、アクセス制御機能による利用権者の識別が正しく行われているとの信頼感によって実現される電気通信に関する秩序である。不正アクセス行為が横行すれば、アクセス制御機能により実現される電気通信に関する秩序が乱され、利用者の中に安心してネットワークを利用できないとの不信感を生み、ネットワーク相互の接続が抑制されるおそれが生じることとなることから、本条では、この点に着目し、「アクセス制御機能により実現される電気通信に関する秩序の維持」を本法の目的の第二として掲げたものである。

逐条 不正アクセス行為の禁止等に関する法律, 不正アクセス対策法制研究会編著, 立花書房

上で検討したように、CSRF攻撃に不正アクセス禁止法を適用するのは無理があるように私には感じられるが、どうにか適用できると解釈する余地も残っているようにも思える。

他の法令はどうだろうか。刑法第161条の2の「電磁的記録不正作出及び供用」の罪に問うことはできないだろうか。

刑法第161条の2

(電磁的記録不正作出及び供用)

第161条の2 人の事務処理を誤らせる目的で、その事務処理の用に供する権利、義務又は事実証明に関する電磁的記録を不正に作った者は、5年以下の懲役又は50万円以下の罰金に処する。

2 (略)

3 不正に作られた権利、義務又は事実証明に関する電磁的記録を、第1項の目的で、人の事務処理の用に供した者は、その電磁的記録を不正に作った者と同一の刑に処する。

4 前項の罪の未遂は、罰する。

まず、CSRFで実害を出そうとする行為が、「人の事務処理を誤らせる目的」であることは明白だろう。この場合、「人の事務処理」とは、当該CSRF脆弱性のあるWebサイトの運営者が電子計算機を用いて行っている事務処理のことである。

次に、その電磁的記録(URL)が、「その事務処理の用に供する権利、義務又は事実証明に関する」ものであると言えるかどうか。たとえば、住所変更やパスワード変更をさせるようなHTTPリクエストは、そのWebサイトが提供するサービスにおけるその人の権利や事実証明に「関する」ものと言えるのではないだろうか。それを他人が偽造して本人に送信させているのであれば、電磁的記録不正作出罪には当たると言えないだろうか。

しかも、不正アクセス禁止法ではアクセス行為の主体が問題となったのと違い、刑法第161条の2第3項では、「人の事務処理の用に供した者」とあり、どのような手段で「供した」かは限定していないので、自分の手で直接に供していなくても、他人の手を借りて供した場合でも該当するように読める。つまり、第3項の罪にも問えるのではないか。

実際、CSRFとは「cross-site request forgery」のことであり、英語の法律用語で「forgery」とは「文書偽造(罪)」のことを指すようだ。日本法の電磁的記録不正作出罪は、文書偽造罪の電子版と位置づけられている。第161条の2の電磁的記録は、私文書のアナロジーなので、申込書のような役割を果たすデータないしファイルも該当するのだと理解している。住所変更やパスワード変更をさせるCSRF攻撃における偽造されたHTTPリクエストは、技術的に見ても、住所変更やパスワード変更の申込書に当たるものであるから、やはり、CSRF攻撃をする行為は、電磁的記録不正作出及び供用罪に問われるように思えるがどうだろうか。同様に、本人でなければ閲覧できない情報をどこかに送信する機能があるときに、その機能を実行させるHTTPリクエストは、その機能を使うと申し出る申込書に当たるとみなせば、同様の理屈が成り立つように思える。ただ、その場合、「その事務処理の用に供する権利、義務又は事実証明に関する電磁的記録」なのかどうかがちょっとわからない。

また、「不正に作った」「不正に作られた」の「不正に」の意味がどういうことなのもわからなかった。

とりあえず、CSRFの罠を踏んで取り返しのつかない被害に遭った人は、警察に相談してみてはどうだろうか。

*1 法案立案当時(1990年代)は、これほどまでに簡単に他人に指定のアクセスをさせることができる技術が普及するとは、認識できていなかったのではないか。

本日のリンク元 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|
最新 追記