2005年6月
2005年6月28日(火曜日)
Windows Server 2003 の IE でのイントラネットゾーンの扱い
むらまささん (www.fprog.org)に教えていただいたのですが、Windows Server 2003 (www.amazon.co.jp)
Windows XP (www.amazon.co.jp)
ちなみに、初期状態では hcp://system というものが登録されています。これは「ヘルプとサポートセンター」を示す URL のようです。
- 「Windows Server 2003 の IE でのイントラネットゾーンの扱い」へのコメント (4件)
関連する話題: セキュリティ / Internet Explorer
ruby で RPC 関係の脆弱性
「ruby-1.8.2に任意のコマンド実行の脆弱性 (slashdot.jp)」だそうで。
XML-RPC は、普通は特定のメソッドだけを HTTP 経由で呼べるようにするわけですが、ruby-1.8.2 では、何も考えないで使うとあらゆるメソッドが全世界から呼べてしまう……というお話で良いのかしら。
関連する話題: セキュリティ
2005年6月27日(月曜日)
セカンダリ DNS 放置プレイ
「ドメイン名の登録と DNS サーバの設定に関する注意喚起 (www.ipa.go.jp)」という文書が出ています。
いわゆるセカンダリの DNS が放置プレイで、ドメインごと消滅していたりしても気づかないということは結構あると思います。いや、実はあんまり他人事ではなくて、弊社でも半年くらい前には同じ状態になっていたという……。たまたま私が DNS 関係の設定を確認していて気づいたのですが、逆に、そういう機会がないと意外に気づかなかったりするのですよね。他の DNS サーバは生きているので一応引けますし、特に問題らしい問題も出なかったりしますので。
最初から全部内部名にしておけば問題ないといえばないのですが、ISP から「この名前で登録しろ」とか言われたものに勝手に名前を付けることには問題がありますし…… (儀礼的な話ではなくて、ISP 側が IP アドレスを変えたときに困る)。
某所の怖いエラー
うーん、パス名パラメータにドライブ名まで含まれているというケースは初めて見ました。"C:\winnt\……" なんてのを渡すといろいろ見えるのかなぁと思いつつも、怖くて試せないわけですが。
とりあえず明らかに無効な文字列を渡してみると、まあ普通にエラーメッセージが出るわけですが……なんか引数がおかしいとか言われていて、どうも OS コマンドの引数に任意の値がインジェクションできる雰囲気ですね。もちろん試しませんが。
公開されているのかどうか……
なんか某社の社内向けページっぽいものが見えていますが……個人情報丸見えならともかく、こういうものだと意図的に公開している可能性もあり、問題なのかどうかよく分からないのですよね。経緯はこんな感じ。
- スクリプト無効だとトップページから先にはアクセスできないサイト
- 仕方ないのでソースを見る
- すると、アクセス解析用のフリーの CGI を呼んでいる記述を発見
- フリー CGI だけにアクセス解析結果を表示する URL が既知なので、アクセスしてみる
- 普通に見えた。トップページが 50PV/日みたい。この CGI にはアクセス制御機能があるようなので、それを使っていないということは意図的に公開しているのだと思われます。
- Referer のログを見ると、なんかパスに private とか含まれている URL がある (ちなみに、これを発見したのは私ではありません)
- アクセスしてみると、社内向けっぽいページだった。もちろん ID もパスワードも全く訊かれていません。
とりあえず、意図して公開しているものと判断しておきます。
2005年6月23日(木曜日)
脆弱性対策のチェックポイント
IPA から「ウェブサイトのセキュリティ対策の再確認を ～脆弱性対策のチェックポイント～ (www.ipa.go.jp)」という文書が出ています。
技術者向けの内容ではないような気がしますが。
ドラッグオンドラグーン2は
「「ドラッグオンドラグーン2」は作られるべくして作られた続編である (www.itmedia.co.jp)」。
ドラッグオンドラグーン2 (www.amazon.co.jp)
私が感じた前作との差異を簡単に挙げてみると……
- 敵に与えたダメージの数値が表示されるようになりました。これによって、敵に攻撃が当たっているかどうかはっきり分かるようになりました。
- ジャンプ力が大幅に UP しました。リアリティのない高さですが、いろいろなものが回避できたり、巨大な敵の頭部を攻撃できたりと多彩な使い方が出来ます。
- スライド後の硬直が無くなり、すぐ行動できるようになりました。普通にスライドして後ろに回り込めたりします。
- ドラゴンは地上戦でもロックオンできるようになりました。
- ドラゴンのダッシュが、ボタン押しっぱなしで加速に。前作では連打してもちょっとしか進めなかったのですが、今回は非常に爽快。
- ドラゴンがホバリングできるようになりました。前作では敵の頭上を通り過ぎてしまって、振り向いてまた通り過ぎて……なんてことをしていましたが、今回は L2 でホバリングして撃つことが出来ます (それでもゆっくりと進みますが)。
- 武器の成長が殺戮数ではなく経験値に依存するようになりました。全体的に成長が早くなり、また強敵を倒す方が成長が早いです。次のレベルまで 10000 とか言われても割と平気で達成できます。その代わりシャドウはいなくなったようですが。
- 敵のガードがかなり堅いです。盾を持っている敵が多いので、ガードブレイクを考える必要があります。
- 敵が賢くなったような気がします。なんか敵が大勢いる場合、後ろに回り込もうとしてくるように思います。リーチの短い武器を使っている場合、囲まれるとかなりまずいです。
以下メモ。
- ガード超重要。ガードできないとアンデッドナイトで死にます。
- 賞金稼ぎの吹き矢 (?) を武器で跳ね返して本人に当てると何故か大ダメージ。
- ノーム戦では、開始直後に経験値高めのノームが大量出現します。そこで MP回復薬を用意しておき、いきなり MP 回復→魔法ぶっ放し、の繰り返しで殺戮後、わざと死んでコンティニューすると効率よく経験値が稼げそう。私はやってないですけど。
- 信義の「刃こぼれしやすい」というのは、レベルが上がると弱くなるという意味。レベル1 で 80 あった攻撃力がレベル3 で 10 に低下します。しかし気にせずに使い続けてレベル4 にすると真の力を発揮。
関連する話題: ゲーム / ドラッグオンドラグーン
2005年6月20日(月曜日)
ミシュランのタイヤが脆弱
「７チームが一斉棄権 優勝はＭ・シュー Ｆ１米国ＧＰ (www.asahi.com)」。ミシュランのタイヤに問題があって F1 が大変なことになったというお話ですが、尾張さんの日記 (?) が興味深いですね。
- 2005/6/18 空気圧 (www.f1.panasonic.com)
- 2005/6/19 選択肢 (www.f1.panasonic.com)
- 2005/6/20 セーフティ・ファースト (www.f1.panasonic.com)
6月18日の日記には問題のタイヤの写真も出ています。
関連する話題: 出来事
2005年6月18日(土曜日)
2005年6月17日(金曜日)
こっちが本家ですから
シアター志向のしっとりした画質ーー松下「TH-26LX500」 (www.itmedia.co.jp)
情報端末機能としては、ビクター「LT-26LC60」と同様に「Tナビ」をサポートした。
「サポートした」って、従来機種でも Tナビはサポートしていますから! 少なくともうちの LX300 はサポートしています。
というか、ビクターと同様にって……。
関連する話題: 思ったこと
2005年6月16日(木曜日)
安心できない安心相談
「警察庁、「インターネット安全・安心相談」システム運用開始 (internet.watch.impress.co.jp)」なのだそうですが……実際に「警察庁 インターネット安全・安心相談 (www.cybersafety.go.jp)」を見てみると、フレームだし、スクリプト無効だと送信できないし……ということで、このサイト自体がちょっと安心できない感じですね。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性
2005年6月15日(水曜日)
Whois怖い
「米国の話聞き、試してみた」 フィッシング容疑者供述 (www.asahi.com)という記事が。
同容疑者は勤務先の大阪市内のソフトウエア開発・情報処理会社で、コンピューターのシステム管理を担当。偽サイトは勤務先のパソコンから開設していた。偽サイトのドメイン（ネット上の住所）は「ｙａｆｏｏ．ｊｐ」で、４年前に業者から本名で取得していたが、サイトは開設しておらず、フィッシングをする直前に妹の名前に変更していたという。
逮捕された人の情報が Whois で公開されているのはまずいと思いますが、逮捕された人の妹さんの情報が公開されているのはもっとまずいのではないかと思いました。
ニュースサイトのアクセス性
「ブログに問われる書く技術、話す技術 (www.itmedia.co.jp)」というお話が出ていますが、内容はさておき思ったこと。
大手ポータルがブログサービスを行なうようになってから、インターネットの景色は一変した。例えばサーチエンジンで何かのキーワードを引くと、記事元のニュースサイトよりも、それを引用したブログが先に来ることも珍しくない。
以上、ブログに問われる書く技術、話す技術 (1/3) より
確かに珍しくないですし、検索している側としても嬉しくない事態ですが、本来はそんなことは起きないはずなのですよね。普通、Web の記事を引用したら元の記事にリンクしますから、ニュースサイトの方がランクが高くて当然なのです。
にもかかわらず逆転現象が起きたりするのは、引用されるニュースサイト側のアクセシビリティに問題があるからなのだろうと思います。
たとえば、MSN-Mainichi INTERACTIVE (www.mainichi-msn.co.jp) のニュースなんかはかなり良く引用されると思うのですが、個々の記事を見ると、title要素にその記事の題名が入っていない、h1要素もないという状態です。
読売などはちゃんとタイトルが入っていますが、こちらはこちらでいわゆる「ディープリンクお断り」の姿勢を見せています (参考: http://www.yomiuri.co.jp/policy/link/ )。そのため、その意思を尊重する人は、引用はしても記事へのリンクはしないことになります。これまた当然ですがランク低下の原因となります。
ニュースサイト側に明らかに負けている要因があると思うのですよね。
関連する話題: アクセシビリティ
早期警戒パートナーシップの感想とか?
IT Pro にこんなのが出ていますね……「セキュリティ向上への地道な試み「早期警戒パートナーシップ」を知っていますか？ (itpro.nikkeibp.co.jp)」
さすがに最近ではベンダーの意識が高くなり，上記のような対応をするベンダーは少なくなったと感じている。多くのベンダーはセキュリティ情報や修正版（修正プログラム）を公表するようになっている。セキュリティ・ホール情報の受付窓口を用意しているベンダーもある。
これはソフトウェア製品の話であって、ウェブアプリケーションの話ではないですよね。ウェブアプリケーションについては、現在でもユーザへの報告無しのヤミ改修が主流だと思いますので。
この制度では，セキュリティ・ホールの発見者が報告しやすい。開発者や運営者と直接やり取りしないので，無視されたり恫喝されたりする心配がない。犯人呼ばわりされる恐れもない。実際，この制度でセキュリティ・ホールを報告した経験がある方に話を聞くと，「直接連絡をとらなくてよいので楽だ」とのこと。その方は，この制度が始まる前から，ベンダーなどに何度か報告したことがある。具体的には聞けなかったが，直接連絡をとると，何かと苦労があるという。
私個人の感想を付け加えると、複数のベンダに影響する問題について調整してもらえるのが非常にありがたいと思いました。たとえば、JVN#FCAD9BD8 (jvn.jp) の届出には Shuriken と Outlook Express の名前しか出ていませんが、公開時には他の製品もたくさん名を連ねていました。それらは IPA や JPCERT/CC の方が独自に調査して連絡してくださったものに違いありません。個人が大量の MUA を調達して検証するのは難しいですし、こういう対応をしてもらえるのはありがたいです。
※ただ、その過程の情報が届出者のところにぜんぜん来ないのはどうかと思います。「○○の開発者にも連絡しました」というような報告があっても良さそうなものだと思いますが。
もっとも、これまたソフトウェア製品に限った話なのでして、ウェブアプリケーションの方はまた別な感想があったりなかったり。
関連する話題: セキュリティ / 情報セキュリティ早期警戒パートナーシップ
メモ : URL にセッションが入ってしまっている場合の自衛策
「URLに埋め込むIDに頼ったセッション管理方式の脆弱性(2) － REFERER情報流出によるセッションハイジャック攻撃の問題 － (securit.gtrc.aist.go.jp)」という文書が出ていますが、URL にセッションを埋め込んでしまっているシステムをどうしても使わなければならない場合、ユーザの自衛策としては以下のような対応が考えられます。
- 絶対に URL を記載することがないように気をつける。特に、メールでログイン後画面についての説明をする際などに URL を記載してしまうことがあるので注意。
- アクセス中に他のサイトを見ないように気をつける。「■リンクのないサーバへもREFERERは送出され得る (securit.gtrc.aist.go.jp)」の件。IE6 やその他のブラウザでは起きないような気もするのですが、念のため。
- 用が済んだら、確実にログアウト操作を行う。
こんな感じの対応をマニュアル化して周知する感じ?
要は URL がセッション情報を含んでいるということを意識して、それが漏れないように注意する必要があるということで。
関連する話題: セキュリティ
2005年6月14日(火曜日)
Apache モジュールを通さないで見えてしまう系
某サイトで、ちょっと URL を間違えたところ、サーバ側のスクリプトのソースと思われるものが見えてしまいました。想像するに、特定の URL が独自の Apache モジュールによってサーバ側で処理されることになっていて、しかしながらその対象となる URL の正規化がうまくできていないため、微妙に URL を間違えるとモジュールで処理されないまま出力されてしまうのではないかと。
※あるいはディレクトリトラバーサルも可能なのではないかと思いましたが、出来てしまったら怖いので試していません。
そういえば昔 .jsp を .js%70 と書くと見えるとか、.cgi を .cgi/ とすると見えるとかいう話がありましたが、それと同じような話だと思います。個人が開発しているような Apache モジュールって結構あると思いますが、中には結構まずいものもあるのかもしれません。
関連する話題: セキュリティ
2005年6月13日(月曜日)
フィッシング詐欺で逮捕
「偽の「ヤフー」でフィッシングの疑い 会社員を逮捕 (www.asahi.com)」という記事が出ています。
企業のホームページ（ＨＰ）に似せたサイトをインターネット上に設け、本物と思いこんでアクセスした利用者の個人情報を盗み取る「フィッシング」をしたとして、警視庁は１３日午前、大阪市に住む４０代前半の会社員の男を著作権法違反などの疑いで逮捕した。警察庁によると、国内でのフィッシングの摘発は初めて。被害を受けた企業のマークに似たものを使い、サイトのデザインも酷似していることから、同庁は著作権を侵害したと判断したという。
うーむ、著作権法違反になるのですか……。
2005年6月8日(水曜日)
サルーインを叩き殺す
ロマサガ (www.amazon.co.jp)
で、戦闘開始。サルーインソードの代わりにオブシダンソードを使ってきて LP がもりもり削られましたが、第一形態はまあ軽く撃破。で、形態が変わると……ゴッドハンド×3→アニメート→立て直そうとするも再びアニメートされたりして、最後は竜騎士一人。どうにもならず終了。
※竜騎士がいる時点でどうかという話もありますが……。ただ、絶対アニメートされないという点ではサルーイン戦に向いているかも。
まあまだ 2周目だしこだわっても仕方ないので、今度は形態が変わるなりクイックタイムを解禁。シムラクラムと聖杯・ミイラの薬コンボで無限クイックタイム発動。サルーインは何も出来ず、文字通り「叩き殺す」感じで勝利しました。
※シムラクラムを使って呼び出した雪だるまが武器や消費アイテムを使っても、雪だるまが消えると元に戻っています。アイテムを消費したのはあくまで雪だるまであって、本人ではないということのようです。シムラクラム→聖杯とミイラの薬使いまくり→わざと LP 消費技を使って雪だるま消滅→シムラクラム……を繰り返せば永遠にクイックタイムを維持することができます。
三周目は何となくグレイで。
2005年6月7日(火曜日)
竜槍ケレンドロウズ
ロマサガ (www.amazon.co.jp)
せっかくなのでもう一本の方も揃えようかと思い、シルバーさんを倒す倒す倒す。かなり強化してあるので2ターンで倒せるのですが、出るのは自然銀ばかり。倒しまくること一時間三十分にしてようやく「竜槍ケレンドロウズ」をゲットしました。
ちなみに、シルバードラゴンのブレスは術法防御が 133あればノーダメージになるようです。131だと 3ダメージ受けました。
動かすのは簡単だが、安全に動かすのは難しい
「言葉は知られていても危険性までは認識されていない「SQLインジェクション」 (www.itmedia.co.jp)」より。
「最近のWebアプリケーションは、いわゆるCやC++などによるアプリケーションとは異なり、比較的簡単に書ける。経験の少ないプログラマが、『とりあえず動くこと』を前提にセキュリティのことを考えずWebアプリケーションを作ってしまうケースが多いのが原因だと思う」（笠原氏）。
御意。反射的に "PHP" という三文字が脳裏をよぎりましたが……。
関連する話題: セキュリティ / SQLインジェクション
直しても直しても直らない
JVN に新ネタ、「JVN#0DC004F6 desknet's におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」というものがでています。
この問題は、JVN#F88C2C13 (JVN#89DE2014の情報を追加) で対応されたパターン以外のスクリプトが実行可能である問題です。
以前指摘されて修正したはずの問題が別のパターンで可能だったという話のようです。実のところ、ブラウザベースのアプリケーションで HTML メールを安全に表示するというのはメチャクチャ大変なことなので、仕方ないのかなという気もします。
私が経験した事例では、HTML メールではありませんが、こんなケースがありました。
まずは HTML が添付できる掲示板の事例。
- 添付された HTML は本文の一部として表示されるが、<script> などの危険なタグは削除されるというサニタイズ処理
- しかし <<script> などと書くと何故か貫通
- 修正されたが、今度は <scr<script>ipt> などと書くと貫通
- 修正されたが、また別の方法でスクリプトが書ける事が発覚 (これは修正されていないので方法は伏せておきます)
それから、また別の HTML が書ける掲示板の事例。
- HTML が書けるが、使用できる要素はいくつかに限定されている。a要素が使用できる
- <a href="javascript:alert()"> などと書くと、タグ全体がエスケープされる。属性値に "script" という文字列が含まれているとエスケープされるというサニタイズ処理
- しかし <a href="javascript:alert()"> などと数値文字参照で書くと貫通
- 修正されたが、<a href="javascript:alert()"> として文字参照末尾のセミコロンを省略すると貫通
- これは非公式に修正されたらしい (修正はアナウンスされていないし私も正式な報告を受けていないのですが、いつのまにかできなくなっていました)
- しかし、実はまだ別の方法でスクリプトが書ける (これも修正されていないので方法は伏せておきます)
どちらも「修正しました」「修正できていません」と泥沼としか言いようのない経緯をたどり、結局修正できていません。
これらはそもそも「HTML が添付できる」「HTML が書ける」という仕様ですので、危険でない HTML は使用できるようになっていなければなりません。そして特定の危険な組み合わせだけをサニタイズしようとしているわけですが、それがもう茨の道なわけです。後者のケースでは、「HTML では REFC (参照終了区切り子、セミコロン) が省略可能なケースがある」などという知識が要求されているわけですが、そんなマニアックなところまで把握しているプログラマはどのくらいいるのでしょうか。さらには、HTML の仕様書には出ていない MSIE の怪しい挙動に至るまで理解している必要があります。
というわけで、「危険な記述だけをサニタイズする」という発想はもう物凄い茨の道です。直しても直しても次から次へと貫通方法が発見されるというのは、ある意味当然だとさえ思います。
そして思うのですが、上で軽く触れたような「こういうサニタイズではこういう貫通方法があるので駄目」というノウハウがどこかに蓄積されていて、ウェブアプリケーションを作ろうという人たちが自由に参照できる形になっていると、いろいろな人が幸せになれるのかもしれません。「IPA ISEC セキュア・プログラミング講座 (www.ipa.go.jp)」などに出ている事もあるのですが、もっと詳細に知らないと駄目な事ってあると思うのですよね。
……まあ、現状では「そういうのを公開すると一般ユーザが真似する」などと言う人が出てくるのは目に見えているので、難しいのでしょうけれど。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性 / IPA / JPCERT/CC / JVN / 情報セキュリティ早期警戒パートナーシップ
カカクコム批判はボツ?
こんなお話がでています……佐々木俊尚の「ITジャーナル」：波紋を広げるカカクコム問題 (blog.goo.ne.jp)。
言及は避けるが、「セキュリティ」というものに対する無理解は相変わらずひどいとしか言いようがない――そんな感想を抱いた。
なんというか、「相変わらず」という言葉にすべてが集約されている感じですね。
2005年6月6日(月曜日)
価格.com 事件 IPA からの報告
IPA から「コンピュータウイルス・不正アクセスの届出状況[5月分]について (www.ipa.go.jp)」という報告がでています。
期待の価格.com に関する情報ですが、被害事例 (i) がそれっぽいですね。
(i) Webサーバに侵入され、利用者がWebコンテンツを閲覧しただけで不正なプログラムをダウンロードさせられてしまう仕組みを埋め込まれているのを発見。改ざん行為と修復作業のいたちごっこが繰り返された。改ざん箇所の調査を進めるうちに、データベースでの改ざん形跡が発見されるなどし、最終的には一時的なサイト閉鎖に追い込まれた。原因は不明(届出元で引き続き調査中)。
原因は不明、調査中だそうで。
被害事例(i)では、セキュリティパッチ適用や外部からのサーバアタック診断を適切に実施していたにも関わらず、サーバへの侵入を許す結果となってしまっています。このサイトでは、単に情報を公開するだけのコンテンツに加え、利用者からの書き込みを受け入れる仕組み（掲示板やサービス申込みフォームなど）もありました。こうしたサイトでは OS やサーバソフトの脆弱性対策に加え、利用者からの入力を受け付けるWebアプリケーションの処理方法が適切かどうかのチェックなども必要となり、対策範囲が広範に渡ってしまうケースが多いと思われます。セキュリティ対策を施す範囲とその内容について、再確認しましょう。
セキュリティパッチは当てていたようですね。
Web アプリケーションの脆弱性を突かれたことを匂わせる記述になっていますが、明言はされていません。IPA も断定するだけの情報は持っていないということなのでしょうけれども。
2005年6月4日(土曜日)
パスワードは校長の名前
「パスワードは校長名、生徒が校内ＬＡＮに侵入 北海道 (www.asahi.com)」。
生徒は５月２７日、校長のＩＤの場合、校長の名前がパスワードになっていることを偶然見つけ、３０日に生徒と教員が共用するパソコンから学内業務用サーバーに侵入、生徒の成績や名前、住所などのデータを取り出した。３１日朝、教頭に印刷したデータを示して「管理が甘いです」と指摘したという。
いや、思わず笑ってしまいました。昔「ウォー・ゲーム (www.amazon.co.jp)
しかし、これは「不正アクセス」になるのでしょうかね。校長の名前が「その内容をみだりに第三者に知らせてはならないものとされている」のであれば「識別符号」に該当するわけですが。
関連する話題: セキュリティ
2005年6月3日(金曜日)
青色 LED がまぶしすぎる
「氾濫する青色LED――消費者から「目障り」と不満の声 (hotwired.goo.ne.jp)」。
そういえば Be Silent M7000 のパイロットランプも青なのですが、かなり強く輝いて見えるのでちょっと気になっていたのでした。
関連する話題: 思ったこと
2005年6月2日(木曜日)
カカクコム CEO インタビュー
価格.comのサイトにはこんなのが出ていますね。「株式会社カカクコム - 企業情報 投資家の皆様へ (www.kakaku.com)」。
事件に関しましては現在警察の捜査中ということもあり、お話出来ない事もございます。
各種報道などで一部私どもの真意が伝わっていない報じられ方がなされておりますが、当社が今回の事件を通じて数多くの方々にご迷惑・ご心配をおかけしたことは事実であり、そしてそのことを重く受け止めております。
以上、株式会社カカクコム - 企業情報 投資家の皆様へ より
その一方で、こんなのが出ています……「当社が不正アクセスの手口を公開しない理由」，カカクコムの穐田CEO」 (itpro.nikkeibp.co.jp)。これはやっぱり、ちょっと理解しがたい内容です。
具体的な手口が話題になりすぎると，いわゆるプロのクラッカーではない，一般の人まで面白半分で始めてしまうのではないかと恐れた。
これを読むと、「いわゆるプロのクラッカーではない，一般の人」が「面白半分で」実行できるような簡単な方法でクラックできたのだと解釈できてしまいます。これは、実際にそうだったのかもしれませんね。具体的な exploitコードが公開されれば、誰でもすぐに他のサービスに応用できるようなものだったのかもしれません。
しかし、そもそも具体的な exploitコードを公開してほしいと思っている人がいるのでしょうか? 少なくとも私は、
- OS や Web サーバのセキュリティホールによるもので、最新のパッチを適用していても防げないものだったのか?
- ウェブアプリケーションの脆弱性 (たとえば SQL インジェクション) だったのか?
といったあたりに Yes / No で答えていただけるだけでだいぶ安心できる (あるいは、逆に他人事ではないと分かる) ので、これだけでも公開してほしいと思っています。これらに Yes / No で答えたからといって「いわゆるプロのクラッカーではない，一般の人」が「面白半分で」何かをすることが出来るとはとうてい思えないのですけれども、そんな最低限の情報すら公開されていないのですよね。
もちろん，侵入手口を公開し，皆で情報を共有すれば今後の不正アクセス対策に役立てられることは理解している。だが，仮に手口を公開した場合，その対策を取るまでに企業側はどうしても時間がかかる。万全なセキュリティ体制を固めるまでに，最低でも数日，場合によっては数カ月かかるだろう。
だからこそ、多くの人が早期の情報公開を望んでいるのでしょう。情報が早く公開されれば、早く対応を始めることができ、早く対応が終わります。対応に時間がかかるなら、なおのこと早く対応を始めたいと思うでしょう。情報が公開されなければ、いつまで経っても何の対策も出来ないままですし……。
半面，クラッカーの方は手口を知ってしまえば，すぐに攻撃をしかけられる。同じ情報を知った場合，企業とクラッカーでは対応時間が圧倒的にクラッカーに有利。だからこそ，情報公開について慎重にならざるを得なかった。
ここで言う「クラッカー」って、どういう人を想定しているのでしょうか。今回は実際に悪意をもって攻撃を行った人が存在していると考えられるのですが、その人が別のサイトをターゲットにするとか、別の人にこっそり手口を教えるといった可能性は考えなくて良いものなのでしょうか。現状は、クラッカーは既に情報を持っていて、しかしながら防御側はまだ情報を持っていないという状態だと思うのですが……。
ただ，同じセキュリティ会社から，セキュリティ対策のレベルは決して低かったわけではないと指摘された点も付け加えておきたい。だが実際に不正アクセスを許した以上，これまでの対策では甘い部分があった。
うーん、これは微妙ですが、
- サーバはそれなりにちゃんと管理していたし、ちゃんと OS のパッチも当てていた
- しかしウェブアプリケーションの脆弱性が放置されていた
という状況を評価したものだと解釈すると、いちおう矛盾無く理解できますね。そうであってほしいですが。
……まあそれはさておき、引用が前後しますが
「なんだか危ないからサイトを閉鎖しよう」と言うのは簡単。だが，多くのユーザーや当社で店舗を運営している会社を考えると，おいそれとサイトを閉鎖するのは難しかった。さらに，すぐに閉鎖すれば，不正アクセスの犯人を調子づかせてしまうことにもなる。ただ，結果としては裏目に出てしまった点は否めない。
この点が非常に重要ですね。この手のサイトでは閉鎖は金銭的な損失に直結しますから、個人の責任で閉鎖の判断をするのは非常に難しくなります。
昨日の某所でもこれが話題になりましたが、このような自体を想定した緊急対応マニュアルを整備しておく必要がありそうです。こういう事態が発生したときに、すぐにサイトを閉鎖するという判断が出来る (閉鎖の判断をしなくてはならない) ようなルールを整備しておくことで、少なくとも「サイト閉鎖が遅れて被害を拡大させた」というような事態は避けられるのではないか、というお話になりました。
カカクコムの対応はツッコミどころ満載ですし、情報も出てこないので苛立ちますが、それでも出来るところはありますので、そういうところから実践して行きたいですね。
2005年6月1日(水曜日)
ハッカー神話健在?
某所にて、「皆さんはプロなのでサーバにアクセスしたりできるのでしょうけれど……」などと言われたりして、興味深く思いました。
昔、高木さんが日記にハッカーの虚像というお話を書かれていた (d.hatena.ne.jp)わけですが、やっぱり「その道のプロは自在に任意のサーバに侵入できる」と思われている方は未だに多いのかもしれないですね。価格.com の問題でも「サイバー攻撃」という謎の言葉が使われましたが、その裏には「プロの手によるサイバー攻撃なんだから防ぎようがないよね」という誤った認識があるのではないかな、と思っています。
当たり前ですが、たとえその道のプロであっても、アクセスできるようになっているところにしかアクセスできません。不正アクセス云々というのは、単に管理者の意図しない理由によってアクセス可能になってしまっているという話です。もちろん、その「意図しない理由」の内容は様々で、
- 単にパスワードが漏れた
- OS の脆弱性を放置していた (OS の脆弱性を知らない or 放置の危険性を理解していなかった)
- ウェブアプリケーションに脆弱性があった
などいろいろありますが、「手口」を見ても、そんな特殊な技術や知識は必要ない場合が多いです。もっとも、なにをもって「特殊」とするのかが微妙で、
- フォームのページの HTML のソースを表示する
- そのソースをローカルに保存する
- 元の URL に相当する base要素を追加する
- input type="hidden" の value をテキストエディタで書き換える
- その HTML を開く
- フォームを送信する
というような手順は、多少なりとも Web に携わる人間なら誰でもすぐに簡単に実行できるのですが、マスコミや裁判所のフィルターを通ると「プログラムを改竄」「HTML ソースを巧みに改変」などという評価になってしまうわけですね。
関連する話題: セキュリティ
- 前(古い): 2005年5月のえび日記
- 次(新しい): 2005年7月のえび日記
