水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2005年のえび日記 > 2005年11月

2005年11月

2005年11月29日(火曜日)

NIS誤検出

どうも Norton Internet Security (www.amazon.co.jp) を導入している環境で「IE が onload="window()" で死ぬ話」を閲覧しようとすると、exploit と見なされて遮断されてしまうようです。文中でコード紹介してるだけなのですけれど……。

同様の誤検出で 2ちゃんねるが見られなかったりもしているようですね。関連: セキュリティホールmemo Internet Explorer の JavaScript の脆弱性に関する注意喚起 2005.11.29 追記 (www.st.ryukoku.ac.jp)

関連する話題: セキュリティ

2005年11月28日(月曜日)

どうぶつの森

りゅうさん (rryu.sakura.ne.jp)に強く推奨されたので「おいでよ どうぶつの森 (www.amazon.co.jp)」を購入、ついでにニンテンドーDS 本体 (www.amazon.co.jp)も購入。これで任天堂部の部員なのに任天堂のハードを持っていないという肩身の狭さから解放されました。

※私の勤め先には「任天堂部」という部活が存在していて、専用のメーリングリストもあったりするのです。:-)

とりあえず釣りにはまって、チョウチンアンコウ 3匹釣ったりしました。ちなみにまだ Wi-Fi 通信できる環境ではないのであしからず……。

関連する話題: ゲーム / どうぶつの森 / ニンテンドーDS

2005年11月22日(火曜日)

IE が onload="window()" で死ぬ話

JPCERT/CC から「Internet Explorer の JavaScript の脆弱性に関する注意喚起 (www.jpcert.or.jp)」という文書が出ています。

<body onload="window()">

と書いてあると、それだけで IE が死ぬという話。うまくすると任意のコードが実行できる模様です。既に PoC が公開されていますが、残念ながら私の環境ではうまく動作しませんでした。あるいは日本語環境だと駄目なのかもしれませんが……日本語環境でも IE が死亡することは確認できたので、しっかり影響は受けるようです。

関連する話題: セキュリティ / Internet Explorer

2005年11月21日(月曜日)

ワコールの漏洩

ワコール、ECサイトの顧客情報4,757名分が流出~カード情報も含まれる (internet.watch.impress.co.jp)」だそうで。ワコールのサイトを見ると「お客様情報の流出に関するお詫びとご説明 (www.wacoal.co.jp)」というコンテンツがあって、経緯などがかなり詳細に公開されています。

原因ですが、「不正アクセスの原因は何か?またいつ頃までに究明するのか? (www.wacoal.co.jp)」「不正アクセスとは、具体的にどんなことが起こったのか? (www.wacoal.co.jp)」によると、SQLインジェクションだったようです。

NECネクサスソリューションズ株式会社の管理・運用するオンラインショップシステムにおいて今年8月にシステム変更を行いました。SQLインジェクションによる不正アクセスへの対策を行っているとの認識をしておりましたが、システムの一部に対策漏れがあることがこのたびの調査で判明しました。結果としてその対策漏れが放置されていました。現在、さらに詳細な原因の徹底究明に向けて対応中です。

しかし、これだけ早いタイミングでこれだけの情報が公開されると気持ちが良いですし、真摯に考えてくれているという印象を受けますね。どこかのサイトとは大違いです。

※惜しむらくは、スクリプト無効だと読めなかったりするものがあることでしょうか。情報漏洩が発覚したら、その関連しそうなサイトを全部「制限付きサイトゾーン」につっこんだりするのが正しい行動のような気がしますし……。

関連する話題: セキュリティ / SQLインジェクション

2005年11月18日(金曜日)

MD5 の現況

MD4/MD5 コリジョンの実証コードが公開 (slashdot.jp)」。

まさに今日「パスワードは MD5 でハッシュして格納いるので問題ない」なーんて発言を見てしまったのでメモ。とある大手企業からは、去年あたりから「社のポリシーとして MD5 は駄目ってことになったんで、既存アプリで MD5 が使われていないかどうか確認させてください」なんて話が聞こえてきていましたが……。ところ変われば人変わる、ということですかね。

関連する話題: セキュリティ

セキュリティのため上記アドレス(URL)は、他の人から類推できないように暗号化されています。

インターネットディスクのセキュリティ (www.internetdisk.jp)」というページに、こんなことが書いてあります。

公開URLの類推

スムーズな利用を実現する公開URLは、類推対策として暗号化して発行。

インターネットディスクでファイルを公開するときの URL は、たとえば http://pub.idisk-just.com/fview/fGO_vizACeROCbrL02QAPieQafMk7dbiDYRTikZ7aoQTDUu-rG7njAUEXRhmTdQe6qJHPNhHr9U.html のようなものになります。この URL にアクセスすると、ノーパスワードで目的のファイルを取得することができます。URL は見ての通りのような感じで、確かに類推は難しいと思われます。

インターネットディスクではダウンロード時のパスワードという概念がありません。そのかわりに URL 自体が「類推されにくい」ものになっています。これによって、「URL を通知した相手にしかアクセスされない」ことを保証しようとしているのだと言えるでしょう。これはつまり、URL そのものがパスワードとしての機能も果たしている、ということです。上記 URL の fGO_viz……の部分というのはファイルの ID であるとともに、パスワードに相当する機能も持つと言えると思います。

さて、ここで改めて上記引用部分を見てみると、「暗号化して発行」と称していますが……。これが類推されにくいのは良いとしても、「暗号化」と呼んでしまうのは問題ないのでしょうか。

以下の二者は似ているようでいて、全く異なります。

前者は漏れてもいちおう (解読や解析がされなければ) 大丈夫ですが、後者は漏れたら即アウトです。インターネットディスクの公開 URL の文字列は明らかに後者の例で、漏れればただちにファイルにアクセスできてしまいます。

そして URL というものは、Referer などから簡単に漏れることがあります。URL が漏れたらアウトな場合には、ちゃんとそのことを意識しないと危ないはずです。ノーパスワードでアクセスできることは、便利でもあるのでしょうし、それ自体は特に問題ないと思います。しかし、それを下手に「暗号化」などと言ってしまうと、「暗号化されているので漏れても大丈夫」という無用な誤解を招いてしまうのではないでしょうか。

※ちなみに本当に URL が漏れてしまった場合は、一度非公開にして再公開することで URL が変わり、以前の URL が無効になります。もちろん、URL を変える前に見られてしまったらどうにもなりませんが。

というわけで、公開 URL 通知メールの「セキュリティのため上記アドレス(URL)は、他の人から類推できないように暗号化されています。 (www.google.com)」という文言もちょっとやめて欲しいですし、むしろ「URL が他人に漏れたらそのままアクセスできちゃうので気をつけましょう」みたいな注意が欲しいなあ、と思ったりする今日この頃でありました。

関連する話題: セキュリティ / ジャストシステム

ステータスバー偽装系 (既出)

IEやOperaにステータス・バーを偽装できる問題 (itpro.nikkeibp.co.jp)」。

アンカーの中にイメージボタンを置くという話。要するに、「リンクとして機能する何か」を a要素の中に入れると、ステータスバーには外側の a要素のリンク先 URL が表示されるが、実際にクリックすると中の「リンクとして機能する何か」が機能してしまうため、ステータスバーの表示と遷移先が食い違うというお話ですね。

って、1年半前にも同じ事を書いたわけですが(「URL偽装問題再び?」参照)。フォームの submit ボタンを使ってこの偽装ができることは、少なくとも私の中ではずいぶん前から既知の問題でした。

関連する話題: セキュリティ / Internet Explorer

2005年11月16日(水曜日)

rootkitをアンインストールするツールが脆弱

2005年11月16日ソニーBMGのコピー防止ソフト用アンインストール・ツールに問題,配布を一時中止 (itpro.nikkeibp.co.jp)」。

アンインストール・ツールの実体はActiveXコントロール。このコントロールには,ファイルの実行などを可能にする危険なメソッドが含まれているものの,「Safe for scripting」マークが付いている。これが,US-CERTが指摘した問題点である。

Safe for scriptingマークが付いているActiveXコントロールは,日本語では「スクリプトを実行しても安全だとマークされているActiveXコントロール」と訳されている。このマークが付いているActiveXコントロールは,Internet Explorer(IE)のセキュリティ設定をユーザーが高めていない限り,Webページ上のスクリプトから呼び出せる。つまり,インターネット上のWebページにアクセスしただけで,そのActiveXコントロールを実行させられる可能性がある。

で、アンインストールが終わっても問題の ActiveX コントロールは残ったままであると……。

関連する話題: セキュリティ

2005年11月15日(火曜日)

ニフティのセキュリティサービスが

やってしまったようで。

これは痛いですね。そもそもこういう事が起きないようにするためのサービスなのに、これではサービスの意義が……。

しかし Sasser (www.microsoft.com) という名前も久しぶりに聞きましたが、MS04-011 (www.microsoft.com)ってもう 1年半も前の話なのですね。事情は分かりませんが、もし「セキュリティサービスがあるから」と安心してパッチを当てなかったのであれば、これはなんとも皮肉な話です。

お金を払ってセキュリティサービスを利用するよりも、ただ黙ってパッチを当てた方が良い……という教訓なのかもしれません。

関連する話題: ニフティ / セキュリティ

2005年11月10日(木曜日)

ファイルにゾーン情報をつけたりする

Windows XP (www.amazon.co.jp) では、ダウンロードした exe ファイルを実行しようとすると警告されたり、ダウンロードした HTML ではローカルマシンロックダウンが無効になったりします。実はダウンロードしたファイルには [ZoneTransfer] というデータが記録されていて、それによって挙動が変わっているのです。逆に言うと、ローカルのファイルにそのデータをセットすれば、ダウンロードしたファイルと同じ挙動になります。

具体的には、Zone.Identifier という代替データストリームにデータを書き込めば OK。たとえば、

echo [ZoneTransfer] > test.html:Zone.Identifier
echo ZoneID=3 >> test.html:Zone.Identifier

のような操作をすれば、この HTML をローカルで開いてもインターネットゾーン扱いとなります。

関連する話題: Internet Explorer / メモ

2005年11月7日(月曜日)

微妙に誤解されている? CSRF

IT Pro でキーワードとして「クロスサイト・リクエスト・フォージェリ (itpro.nikkeibp.co.jp)」が取り上げられていますが……。CSRF の解説というより、「はまちちゃん」の解説になってしまっていますね。

「はまちちゃん」の事例は確かにスクリプトを使っていましたが、CSRF 自体はスクリプトとは関係のない話です。そもそも、「はまちちゃん」のスクリプトも単に自動的に POST させるだけのものです。ボタンを置いておいて押させれば良いだけの話ですし、ボタンをアンカーのように見せることも簡単です。つまり、スクリプト無効でも被害に遭う可能性があるのですが、そこが誤解されていないかちょっと心配ですね。

さらに微妙なのが対策の部分。

クロスサイト・リクエスト・フォージェリは,Webサイト側でセッションをきめ細かく管理することで防げる。処理中のWebページの要所要所でセッションIDを切り換えたり,重要度の高い画面に移るときは改めてパスワードを要求するなどの処理をWebアプリケーションに盛り込めば,手順を飛ばして実行する不正なスクリプトからの処理を排除できる

なんというか、はっきり言って意味がよく分かりませんが……。これで本当に防げるのでしょうか。

関連する話題: セキュリティ / CSRF / ITpro

2005年11月1日(火曜日)

Web バグは画像とは限らないはず

ヨスケ先生に言われて気づいたのですが、Webバグもしくは Web ビーコンについて検索すると、多くの用語集ではこれらを「きわめて小さな画像」であると定義しているようですね。

確かに多くの Web バグは小さい画像として実装されていますが、それは必須ではないはずです。巨大な透明 GIF であっても良いですし、普通に見える画像であってもかまいません。実際、HTML メールに埋め込まれたロゴ画像 (大きいし、明らかに見える) の URL にメールアドレスと関連づけられたクエリを埋め込んでアクセス情報を収集する、というものがありました。最近の Outlook Express では、外部リソースを含む HTML メールに「このコンピュータが送信者に識別されることを予防するため、画像がブロックされています」という警告が出たりしますが、これも当然画像の大小に関係なく出ます。

もっと言えば、そもそも画像でなくても良いはずです。スクリプトでも CSS でも、HTML のレンダリング時に自動的に参照される外部リソースであれば何でもかまいません。ほとんどの場合には画像が使われますが、それは単にその方が楽だからであって、画像でなければ Web バグではないという事にはならないはずです。

結局のところ、Web バグが「バグ」(=盗聴器) と呼ばれるゆえんは、

というものでしょう。

これらの条件をすべて満たすものであれば、たとえそれが「小さな画像」でなかったとしても「Webバグ」と呼んで差し支えないと思います。

関連する話題: セキュリティ

うまくいかなかった事例

脆弱性情報の取扱い - JPCERT/CCとオープンソースソフト開発者が意見交換 (pcweb.mycom.co.jp)」。

「うまくいかなかった」事例その2、って……。取扱番号は伏せられていますが、そもそも JVN で公開されている脆弱性自体少ないですし、「複数開発者にコンタクト」かつ「オープンソース」という時点で相当絞り込まれてしまうような気がしますね。

JVN#465742E4 (jvn.jp)だろうなぁ。Hiki0.6.6は 17日リリースなので。

関連する話題: セキュリティ / IPA

最近の日記

関わった本など