Facebook、誤ってユーザーの生年月日を公開
ユーザーが非公開に設定している場合でも、ほかのユーザーが生年月日を閲覧できる状態になっていたという。
あららら。それは大変。
生年月日などの個人情報は、「なりすましなどの犯罪に悪用される恐れがある」とSophosは指摘。
だよね。
だが、
Facebookは今回の問題を修正したが、このようなミスが今後も起こり得る可能性があるとしている。ユーザーに対し、たとえ非公開にしている場合でも念のために本当の生年月日は登録しない方がいいと忠告している。
だったら、こんなフィールド無くしたらどうだろう？
SNSなどで生年月日を公開してくれる機能というのは結構好きだ。近しい友人や知人でも誕生日までは知らなかったりする。そんな場合でもSNSで登録されていると、誕生日を教えてくれる。プレゼントをあげたり、簡単なメッセージを送ってあげたり。世知辛い世の中でコミュニケーションを円滑にする材料にできる。と思っているんだけどなぁ。
なので、嘘の生年月日なんて登録されると困る。
「このようなミスが今後も起こりうる可能性がある」っていうのは正直だとは思うんだが、開き直ってどうする？ と思わなくも無い。
とここまで書いていて思ったんだが、Facebookがこんなこと本当に言うか？
英語のニュースをしばし探索。。。
どうやら、Facebookが言ったのではなく、問題を発見したSophosのコンサルタント、Graham Cluleyが言っているようだ。
つまり、「Facebookは今回の問題を修正したが、このようなミスが今後も起こり得る可能性があるとしている。ユーザーに対し、たとえ非公開にしている場合でも念のために本当の生年月日は登録しない方がいいと忠告している。」は「Facebookは今回の問題を修正したが、Sophosは、このようなミスが今後も起こり得る可能性があるとしている。さらに、Sophosはユーザーに対し、たとえ非公開にしている場合でも念のために本当の生年月日は登録しない方がいいと忠告している。」ということだ。
普通に読めばそうとわかるだろうって？ はい、そのとおり。失礼。
ネットカフェからウィルスお持ち帰り
5/20に某ネットカフェを利用した。そこでは、インターネットからファイルをダウンロードし、USBメモリに保存したのだが、自宅にてUSBメモリを私有PCに挿入したところ、VBS_SASAN.Aが検出される。
一昨年に「ネットカフェ」というタイトルで本ブログに書いた以下のことが現実に起きていることが確認できた。
リムーバブルメディアについては使用は制限されていない。CD-Rにデータを保存することさえ可能だ。USBメディアは持っていくのを忘れたので、試せなかったが、おそらく問題なく使えると思う。ウィルス対策がされていないため、ウィルスに感染したファイルをリムーバブルメディアに保存してしまうこともあるだろう。ここではリムーバブルメディアを使わないことが良さそうだ。
ネットカフェには連絡済み。また、IPAにも報告した。
ついでなので、このあたり*1の規制やガイドラインはどうなっているのか調べてみた。
まず、業界団体として、日本複合カフェ協会というのがあるようだが、この団体の目的は店舗で使われるソフトウェアの著作権遵守を推進することのようだ。
Q: どのような活動を行っている団体ですか？
A: 平成14年６月現在においては、複合カフェにおける家庭用ＴＶゲームソフトの業務利用許諾システムの構築に注力し活動を行っております。今後、家庭用ＴＶゲームに限らずＰＣソフト、映像ソフト等、様々な著作物利用に関するルール構築等において、唯一の業界団体として各方面と交渉を行い、業界の健全な発展に向けた活動を行っていきます。
このように、日本複合カフェ協会は著作権遵守のための活動以外あまりやっていないように見えるが、それでも店舗運営ガイドラインというのは用意されている。ここにはセキュリティ対策について以下のように書かれている。
■インターネットのセキュリティ確保及びネットワーク利用犯罪の防止
１．犯罪行為の防止
他人のＩＤ・パスワードを無断で使用して認証サーバーに不正にアクセスする行為や、インターネットを介したわいせつ画像・児童ポルノ・海賊版ソフトの頒布や偽ブランド品の販売、詐欺行為、その他電子メールや電子掲示板を利用した名誉毀損や脅迫等の行為が不正アクセス禁止法や刑法、その他の法令に抵触し犯罪行為となる旨を店内掲示により警告し、併せてこれら犯罪行為の発生を極力防止するための対策を講ずることとする。
２．セキュリティ対策
不正アクセスやコンピュータ・ウイルス等による被害及びネットワーク利用犯罪を防止するため、利用履歴を削除するソフトやリカバリーソフトをパソコンにインストールするなどの措置をとるよう努めなければならない。また、パソコンやサーバー等のＯＳ・ソフトの脆弱性対策、一定のプログラム（ウイルス、キーロガー等）の実行制限、不正なアクセスを防ぐシステム（ファイアーウォール）の設置、及びルータやモデム等の制御機器の初期パスワード変更、などについても、措置を講ずることが望ましい。
「一定のプログラム（ウイルス、キーロガー等）の実行制限」とはなんとも微妙な言い回しだ。アンチウィルスもしくはウィルス対策ソフトウェアの導入とはっきり書かないのには何か理由があるのだろう。導入やプログラムおよびパターンファイル更新のためのコストがネックになっているのだろうか。
設立趣旨には業界の健全化を推進すると書かれているで、念のため意見しようかと思ったが、お問い合わせフォームでの問い合わせで電話番号の記入が必須になっていたので、面倒くさくなってやめた。どうでも良いけど、インターネットに多少なりとも関係する業界団体でのオンライン問い合わせフォームで、メールアドレス記入は任意で、電話番号の記入が必須というのはどうなんだろう。
警視庁から以下のように注意を促されているが、これは一般ユーザー向け。
インターネットカフェでは高速回線が利用されている店が多く、快適なサービスを利用できる等便利な反面、セキュリティ等の安全対策が施されていない店も多く見受けられます。
ほかにも、site:go.jpで何かガイドラインのようなものは出されていないか検索してみたが、どれも一般ユーザーへの注意勧告だった。
ならばと思い、セキュリティベンダーでネットカフェへの特別パッケージやソリューションなどを用意していたりはしないかと見てみたが、こちらも見つけられなかった。
お国に頼るのはあまり個人的に好きじゃないんで、声高に規制が必要だと叫ぶつもりはない。それよりも、各セキュリティベンダーはネットカフェがここまで普及しているんだから、導入や運用をコスト面と手間の面の両面で助けるようなことを考えれば良いのに。
［参考］
今までのネットカフェに関する記述
*1:ネットカフェのセキュリティ対策
Yahoo! Cafe
久しぶりのネットカフェ探訪シリーズ。
以前の連載（連載だったの？！）は以下のとおり。
- 2006-05-07: ネットカフェ
- 2006-07-09: ネットカフェにまた行ってみた
- 2006-08-15: ネットカフェ＠都内某所
- 2006-09-10: ネットカフェ＠韓国人街
- 2006-09-24: ネットカフェ＠埼玉県某所
- 2007-07-28: ネットカフェでP2Pソフトウェアが禁止されていた
これ以外にもネットカフェは頻繁に利用している。東京23区内に通うように久しぶりだったのだが、良く見てみると、ネットカフェの価格破壊がすごい。外出時の仕事の合間にネットにつなぐ必要があるのなら、一般のカフェよりもめちゃくちゃリーズナブルだ。
ネットカフェに行く際には極力、そこのセキュリティがどうなっているかを確認するようにしているが、どこも最低限のセキュリティ対策はとられているようだ。最低限とはリブートすることでシステムが元の状態に復帰するということだ。果たして、これを最低限と呼んで良いのかどうかわからない。以前の投稿でも指摘していたが、アンチウィルスが導入されていなかったり、最新のセキュリティ修正プログラムが適用されていなかったりというのはまだ見受けられる。一番驚くのが、本人確認をしないまま利用を認めている店舗があることだ。昨年、神戸に行った際に寄ったネットカフェもそうで、東京以外ではこういう店もまだあるのかと思っていたが、その後に利用した新橋のネットカフェでも同じで、こちらは自動販売機でチケットを発売して、それで利用が可能であった。システム側のセキュリティ対策がとられていたとしても、いくらでも穴はあるので、ネット犯罪を防ぐためには本人確認は必要だろう。
さて、ちょっと前置きが長くなったが、今回は、Yahoo! Cafeに行ってみた。今日書いているが、実は少し前の話（3/17）。シドニーに出張があったのだが、久しぶりに成田空港第2ターミナルへ行ってみたら、Yahoo! Cafeがある。時間もあったことなので、ここを利用してみた。
まず、Yahoo! Cafeであるが、利用料金は無料（太っ腹！）。本人確認は必須で、成田空港のYahoo! Cafeではパスポートの提示を求められた。利用申請書に記述することで、ID番号のついたUSBメモリー状のキーが渡される。いわゆるドングル（というかセキュリティトークン）で、スクリーンにでかく「iKey」と書かれていたので、SafeNetのiKeyであることがわかった。ちゃんと調べる時間がなかったが、形状からおそらくiKey 2000シリーズのほうではないかと思う。これをUSB端子に装着することで各マシンへのログインが可能となる。
ログインし終わった後であるが、不必要（とYahoo! Cafeが考える）な操作はできないようにロックアウトされている。たとえば、画面のスクリーンキャプチャを取りたかったのであるが、ペイント（mspaint.exe）が起動できない。スタートメニューから削除されているし、「ファイル名を指定して実行」もない。
タスクマネージャから「新しいタスク」を起動しようとしたが、タスクマネージャは起動できるものの「新しいタスク」からペイントを起動することもできない。WinKeeperにより制限されているためだ。
WinKeeperは主に学校向けに導入されている製品であるが、ユーザーの挙動を制限することができるものだ。時間が無かったので、あまりきちんと調査できなかった（し、そもそも設定変更は禁止と書かれているので、あまり怪しい行動をしたら怒られただろう）が、ざっと触った感じでは簡単には悪いことはできそうにない。
以上のように、必要十分なセキュリティは確保されている模様。さすが。
＜参照: Flickrの写真＞
DEP用新API提供
Microsoft、データ実行防止技術を推進する新APIを提供（Computerworld.jp）にあるように、「第1〜2四半期にリリースされる予定のWindows Vista SP1、Windows XP SP3、Windows Server 2008に搭載される」らしい。DEP（Data Execution Prevention）はNX（No eXecute）とも呼ばれるもので、データ領域におかれたコードの実行を禁止することで、バッファオーバーフロー攻撃を防ぐものであり、Windows XP SP2から導入されている。
この記事の元ネタ*1はMichael Howardのブログの"New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008"。
ざっくり言うと、1) 古いATLではDEPが使えなかったので、使えるようにした ということと、2) ソフトウェアからDEPの制御を可能にしたということだ。ATL（Active Template Library）とはまた懐かしいものがと思った*2が、ATLとDEPの組み合わせの問題はMichael Howardにより次のように説明されている。
Older versions of ATL, and by older I mean pre-Visual C++ 2005, used dynamically generated code in small isolated cases. Obviously, without the appropriate APIs this is going to cause problems on a DEP-enabled computer, because you can't execute data. This code is referred to as a "thunk" and versions of ATL in VC++ 2005 and later work correctly with DEP.
"New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008"より
VC2005以前では、動的に生成されたコードを使っていたが、それらはDEP有効にした環境では動作しないので、APIを準備したということだ。最新のATLを用いれば解決するらしいが、このように古いATLまで気にしなければいけないということは、それだけDEPを有効にした環境が増えてきたという証拠か。
新しく用意されるのは、3つのAPI（ブログから読む限り）。
- SetProcessDEPPolicy
- GetSystemDEPPolicy
- GetProcessDEPPolicy
SetProcessDEPPolicyでプロセスのDEP制御をするもので、残りの2つはシステムとプロセスのDEP状況を把握するものだ*3。
アプリケーションからDEPの有効/無効を制御できるようにしたのは、互換性の問題を解決するため。
If you support DEP but want to allow customers to disable DEP if there are serious compatibility issues, then this is the API to use because the argument can be a configuration option.
"New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008"より
なんで、この時期に？ というのもあるが、それは、
なお、新しいAPIをこの時期に提供する理由については、「同SPが多数のユーザーに導入されるからにほかならない。われわれはDEPによるアプリケーションの保護を推進中であり、新APIの提供はその一環」とHoward氏は説明した。
だそうだ。
RC5/DES Cracking Challenge
昨日の「暗号輸出規制の思い出」を書いた後に思い出したのだが、当時、RSAがDESの56ビット鍵長では脆弱なことを証明するために、クラッキングコンテストを行っていた。DES Challengeと呼ばれていた。
これに世界中のマシンで分散して解析計算をさせることを組織化したのが、Distributed.netだ。個人またはチームでグループとなって分散された計算を行い、その結果を競うもので、一種のゲームのような感覚を楽しみながら*1、暗号の輸出規制緩和もしくは撤廃を求めることができた。
私はこれにJWNTUGという今は無くなってしまったWindows NTのユーザー会の有志の1人として参加していた。この団体、残念ながら、今はホームページも無くなってしまったのだが、Web Archiveから一部を見ることができる（Feeling Your NTBOX Secure Now? - Team JWNTUG RC5 Cracking Challenge）*2。タイトルがRC5となっているが、Distributed.netではいくつかのDES ChallengeとRC5のクラッキングコンテストを行ったため、このようなタイトルとなっている。
ここでTeam JWNTUGの参加理由について以下のように述べられている。
全世界のユーザが平等にその恩恵を受けることの妨げになっているのが輸出規制に他ならず、米国政府にこうした規制を緩和させ、よりbit長の長い暗号キーを輸出できるよう認めさせるために、RSA は暗号キーの解読コンテストを主催しています。暗号を破ることによりアルゴリズムが安全でないことを証明するわけです。この解読コンテストにJWNTUGも一昨年の10月16日より参加しています。
http://web.archive.org/web/20010628022441/www.jwntug.or.jp/rc5/intro-j.html
Team JWNTUGに参加したメンバーの多くは、比較的多くのパワーのあるマシンを大量投入することができたため、国内１位を達成したこともあった*3。こういうときのメンバーの結束は固く、メタルプレートも配布されていた。私もいくつかもらい、自宅のPCに貼り付けたものだ。
というようなことも、またふと思い出した。
