2005年10月
2005年10月30日(日曜日)
CSRF 直った
ニフティ系のもろもろがいろいろ直ったという報告がありました。私は退会済みなので確認できませんが、まあ修正報告があったからには大丈夫でしょう。
「脆弱性届出状況2005年Q1」あたりで CSRF による強制パスワード変更の可能性について軽く臭わせることを書いていましたが、実際に「@homepage 管理画面において、CSRF 攻撃によって FTP のパスワードが強制変更される」というものを届け出ていたのでした。届出に記載していた PoC コードはこんな感じ。
<form action="https://homepage.nifty.com/cgi-bin/HP_ChangePW.cgi" method="POST">
<p>例の話ですが、ニフティ会員の方は以下で見られます (要パスワード)。</p>
<input type="hidden" name="DISP_PAGE" value="ftp200.htm">
<input type="hidden" name="FTPPASSWD" maxlength="8" size="15" value="XXXXXXXX">
<input type="hidden" name="NEWFTPPASSWD" maxlength="8" size="15" value="XXXXXXXX">
<input type="submit" style="background:transparent;border:none;text-decoration:underline;color:#00f;cursor:hand" value="例の話詳細">
</form>
押すと、Basic 認証のダイアログが出ます (既にログイン済みでなければ、ですが)。そこで素直にパスワードを入れると、パスワード変更完了画面が表示されて後の祭りです。
※まあ、パスワード変更完了画面を見られてしまうとばれてしまうので、本気で攻撃 (!?) する場合には完了画面をうまく隠す必要があるでしょう。フレームを使うなど、カモフラージュの方法はいくらでもあります。
昔ニフティには「インターウェイ」という Web インターフェイスがあって、フォーラムの発言などを Web 上で閲覧することができるようになっていました。そのアクセス制御には Basic 認証が使われていました。そんなわけなので、「ニフティの会員制のコンテンツですよー」と断ってリンクを書いておくと、Basic 認証のダイアログが出てきても不自然さが微塵もないという。
これの他にもいろいろと直ったらしいですね。お疲れ様でした。
- 「CSRF 直った」にコメントを書く
関連する話題: セキュリティ / ニフティ / CSRF / 情報セキュリティ早期警戒パートナーシップ
2005年10月29日(土曜日)
間違いだらけの個人情報保護ブログ
「間違いだらけの個人情報保護ブログ (internet.impress.co.jp)」なんてのがあるのですね。興味深いです。牧野二郎弁護士が書かれている模様。
2005年10月28日(金曜日)
見出し
「記事見出し配信訴訟、読売新聞側の訴えを一部認めた控訴審判決が確定 (internet.watch.impress.co.jp)」だそうで。
ちなみに「一部」ってどのくらいなのかというと……。
３ 訴訟費用は，第一，二審を通じ，訴えの提起及び控訴の提起の申立て手数料のうち１万分の５を被控訴人の負担とし，その余の訴訟費用はすべて控訴人の負担とする。
以上、http://courtdomino2.courts.go.jp/chizai.nsf/0/0c642a4a124dc13d492570970018104b?OpenDocument より
いちまんぶんのご、0.05% ですね。
関連する話題: 法律
2005年10月25日(火曜日)
フィッシングメールの Recieved: フィールド
「5分で絶対に分かるフィッシング詐欺 (www.atmarkit.co.jp)」。
メールのヘッダ情報を確認するのも見分け方の1つです。「From:」欄は、メールソフトの設定をすることで誰でも詐称することができますが、「Received:」欄にはどのメールサーバから送信されたかが記録されています。メールはいくつかのサーバを経由して届くため、「Received:」が複数ついていますが、一番下に送信元のドメイン名かIPアドレスが残されています。これが正しいドメイン名と違っている場合は疑うべきでしょう。
いや、それはちょっと……。From: だけではなく、Recieved: も簡単に捏造できます。信頼できるサーバ (自社のサーバ、自 ISP のサーバ) が付加したものでないフィールドは一切信じないのがセオリーでしょう。
※捏造した Recieved: ヘッダフィールドを含むメールを SMTP に渡すと、その Recieved: は消えたりせずに、その上に Recieved: が追加されて行きます。単純に一番下の Recieved: を見ると、それは捏造されたものである可能性があります。
というわけで、信頼できるものの中で一番下の Recieved: を見る必要があるのですが……何が信頼できるのかは、普段からメールヘッダを見ていないと判断できないかもしれません。まあ、他の無難なメールのヘッダと比較すればすぐに分かりますけれども。
関連する話題: セキュリティ
破綻
「ハジョウする」という耳慣れない言葉を聞いたのですが……これ、ひょっとして「破綻」のつもりなのでしょうか。
……ATOK で「はじょう」と入れて変換しようとすると、「破綻《「はたん」の誤読》」という候補が出ますね。
※MSIME だと「波状」しか候補が出ない模様。
2005年10月24日(月曜日)
セキュリティ人材のパラドックス
「ネットワークセキュリティの諸問題 - 技術者の雇用/Bot/ビジネスの継続性 (pcweb.mycom.co.jp)」。
「セキュリティ業界には『優秀な人がいるとその会社には何も事件が起こらなくて、結果としてその人が不要になる』というパラドックスがあり
なるほど。
何も起きないと経験も積めませんしね……。
関連する話題: 思ったこと
喫煙タクシー
「タクシー喫煙、粉じん基準の１２倍 回復まで１時間以上 (www.asahi.com)」だそうで。まあそうでしょうね。
私はタクシーに乗ると高確率で体調が悪くなるので、緊急時以外は決して乗らないようにしていますが……禁煙がデフォルトになれば、普通に乗れるようになるかもしれません。
関連する話題: 思ったこと
2005年10月14日(金曜日)
他人の会員情報が見える系
「小田急電鉄、特急券予約サイトで他人の会員情報が閲覧できてしまうトラブル (internet.watch.impress.co.jp)」というお話。見出しだけ見るとセッションの競合とかテンポラリファイルがかぶったとかいう話を想像しますが、良く読むと……。
発生した事故は、複数の会員が同時にログインしている場合に、ある会員がいったんサービスからログアウトして、Webブラウザを閉じずに再度ログインした場合に、その会員の予約情報などが別の会員のWebブラウザに表示されてしまう場合があったというもの。
一度ログアウトして、Cookie をクリアせずにもう一度ログインフォームからログインしたときに他人の情報が見えるということのようで……なんかこれ、私が以前に経験したことのあるパターンに似ていますね。問題の「ロマンスカー＠クラブ (www.web-odakyu.com)」のページにアクセスして、ログインフォームの form要素開始タグを見るとこんな感じでした。
<FORM METHOD="post" ACTION="https://www.web-odakyu.com/servlets/odq02/getcontent/20893755364992306/send/request">
リロードしてソースを見たら、今度はこうなっていました。
<FORM METHOD="post" ACTION="https://www.web-odakyu.com/servlets/odq01/getcontent/7513952029298192/send/request">
何が起きたのか、何となく想像できるような気がしました。
関連する話題: セキュリティ
主文後回し
「主文言い渡しを後回し 連続リンチ殺人事件控訴審判決 (www.asahi.com)」。この見出し……主文が後回しになることの意味を知らない人も多いような気がしますが、かといって迂闊なことは書けないですし、微妙なところですね。
関連する話題: 法律
2005年10月12日(水曜日)
届出状況2005年Q3
「ソフトウエア等の脆弱性関連情報に関する届出状況[2005年第3四半期（7月～9月）] (www.ipa.go.jp)」が公表されました。
「SQL インジェクション」の届出の多くは、データベースのエラーメッセージが表示されたページを発見したというものです。これまでに取扱いを終了した23 件のうち、12 件は「SQL インジェクション」の問題が実際にあり修正したとの報告を受け、残りの11 件はエラーメッセージが表示されていただけで「SQLインジェクション」の問題はなかったとの報告を受けました。
確認もしないで届け出るとは、などと思われるかもしれませんが、届出者が確認してしまったらそれはそれで問題があるわけでして。XSS はともかく、SQL インジェクションは下手をするとデータベースを破壊してしまう可能性もあったりして洒落になりません。
しかし、確認しないで届け出ても結構「当たり」が出るものなのですね。
関連する話題: セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ
2005年10月6日(木曜日)
2005年10月4日(火曜日)
闇サイト
「闇サイト事件：「殺人請負」サイト管理者を逮捕 調査費名目、１６５万円詐取の疑い (www.mainichi-msn.co.jp)」というお話。「闇サイト」ってなかなか凄い表現ですね。
ちなみに問題のサイトは Web Archive で見られます……「復讐★別れさせ屋★悩める方の駆込み寺★ (web.archive.org)」。確かに闇っぽいというか、まあ単に背景が黒いわけですけれども。「君が代★教育勅語」というリンクがあったりして、なんとも微妙な雰囲気を醸し出していますね。
関連する話題: 出来事
2005年10月3日(月曜日)
Project 2002 と信頼済みサイトゾーンの微妙な関係
Microsoft Project 2002 (www.amazon.co.jp)
その Project 2002 を Project Server と連携させて使おうとすると、少々驚くべき事が起きます。そのサーバのドメインを「信頼済みサイトゾーン」に追加するように求めてくるのです。必要性が理解できませんが、追加しないと使えないようなので、指示に屈して「信頼済みサイトゾーン」にドメインを登録して接続します。すると……パスワードを求めるダイアログが何度も出てきて、何を入れても駄目。結局接続できませんでした。
何が起きたのかは明白です。私は「信頼済みサイトゾーン」のセキュリティレベルを、デフォルトよりも高くしてくして使っています。設定はほぼ「中」のレベルになっていて、これは「インターネットゾーン」の初期値と同じです。そしてイントラネットゾーンは初期状態に近いレベルで使用していて、ほぼ「中低」です。つまり、初期状態では
- 信頼済みサイトゾーン …… 低
- イントラネットゾーン …… 中低
であるので信頼済みサイトゾーンよりもイントラネットゾーンの方がセキュリティレベルが高いのですが、私の場合は
- 信頼済みサイトゾーン …… 中
- イントラネットゾーン …… 中低
ですので、信頼済みサイトゾーンの方がイントラネットゾーンよりもセキュリティレベルが高いという逆転現象が起きています。
そして、私のところの Project Server にアクセスするためには、「ユーザー認証」-「ログオン」の項目が「現在のユーザー名とパスワードでログオンする」になっている必要があるのでした。デフォルトの信頼済みサイトゾーンならそういう設定になっているのでアクセスできるのですが、私のところではそうなっていないのでアクセスできないわけです。
しかし考えてみると、この Project Server はイントラネットゾーン上に存在しているので、「イントラネットゾーンでのみ自動的にログオンする」でも問題ないように思えます。しかし「イントラネットゾーンでのみ自動的にログオンする」では駄目なのです。なぜなら、信頼済みサイトゾーンに登録したことによって、イントラネットゾーンのサイトではなくなっているからです。では、信頼済みサイトゾーンから外してイントラネットゾーンにすればアクセスできるのでしょうか。
理論上は、認証は通るはずです。しかしなんと、Project 2002 はターゲットが信頼済みサイトゾーンに登録されているかどうかをチェックしていて、登録していないと「登録しろ」というダイアログが出てアクセスできないようになっているのでした。
何のためにそんなチェックをしているのか全く理解できないのですが、八方ふさがりです。何か打つ手はないかと探してみると、こんなリソースが見つかりました……「[PRJ2003] Project Professional 2003 でイントラネット ゾーンの Project Server に接続するときに、Project Server を信頼済みサイトに追加するよう求めるメッセージが表示されないようにする方法 (support.microsoft.com)」。どうも困っているのは私だけではないようで、いちおう無効にする方法が用意されているのですね。
……Project 2003 では、ですが。Project 2002 では、そのようなレジストリ設定をしても何も起きないようです。もうね……。
ドメイン乗っ取り話
「正しいアドレスなのに別サイト ドメイン乗っ取り、注意 (www.asahi.com)」。
「DNSサーバの乗っ取り」と「ドメインの期限切れ」は微妙に違うような気がしますけれども……期限が切れたドメインを取得することによって偽セカンダリ DNS サーバを立て、それでドメインを乗っ取るという話もありますのでややこしいですね。ドメイン失効から乗っ取りが起きるパターンは二つあります。
- 本体のドメインが有効期限切れとなり、それを他人に取得されれば別のサイトになるという当たり前の話。pukiwiki.org がこのタイプ。
- セカンダリ DNS サーバのドメインが有効期限切れとなり、他人に取得されて偽の DNS サーバを立てられれば一定確率で偽のサイトに誘導される。fdma.go.jp に起こりかねなかったのがこのタイプ。
警察庁の「ドメイン名の有効期限に注意 (www.cyberpolice.go.jp)」は前者の話、IPA の「ドメイン名の登録と DNS サーバの設定に関する注意喚起 (www.ipa.go.jp)」は後者の話ですね。
乗っ取りの実例は知られていないが、経済産業省系の独立行政法人・情報処理推進機構（ＩＰＡ）には、乗っ取られると影響の大きいドメインの権利切れなどの報告が、これまで７件寄せられた。関係者によると公的機関も含まれていた。
公的機関も……って思わせぶりですが、これは「消防庁など政府系4サイトに“ドメインハイジャック”の危険性 IPA、民間企業にも警告 (internet.watch.impress.co.jp)」の話ではないかと。
- 前(古い): 2005年9月のえび日記
- 次(新しい): 2005年11月のえび日記
