セキュリティ・ホールが公開されれば,ユーザーは当然対処しなくてはならない。しかし,セキュリティ・ホールが公開される前に,攻撃用のコード(ツールやワームなど)が出回ることがある。そういったコードは,事前に対処する時間(日数)がないことから「0-day Exploit」と呼ばれる。今回のコラムでは0-day Exploitの事例をいくつかを紹介するとともに,その対策を考えてみたい。

0-day Exploitを“ほのめかす”ツール

 以前のコラムで筆者は,Apacheの深刻なセキュリティ・ホールについて解説した。コラムでも書いたように,セキュリティ・ホールが公開されてまもなく,「GOBBLES Security」やhsj氏により検証用ツールが公開された(hsj氏には,後ほどご登場いただく)。そしてその後,このセキュリティ・ホールを悪用するワーム「scalper」が出現した。

 セキュリティ・ホールが公開された後に,検証用ツールが公開され,ワームが出現しているので,ツールもワームも表面的には0-day Exploitではない。しかし,GOBBLES Security が公開したコードには,セキュリティ・ホールが公開される前に,このコードを使っていくつかのサイトに侵入したことをほのめかす記述が含まれている。

 実際,このコードによるものかどうかは不明だが,記述されていたサイトの一つはApache の問題が報告される前の2002年5月の時点で侵入されていて,そこに置かれたツールがバックドア入りのものと取り替えられていたことが報告されている

 もし,この侵入がGOBBLES Securityのコードによって行われていたら,このコードは0-day Exploitといえる。

Code Redの“お手本”は0-day Exploit

 2001年7月に大きな被害をもたらした「CodeRed」ワーム。このワームを解析したeEye Digital Security の Marc Maiffret氏によると,CodeRedはまったくのオリジナルではなく,別のワームのロジックをもとにしているという(参考資料)。“お手本”にしたのは「.htr worm」と呼ばれるワームで,名前の通りにInternet Information Server(IIS)の.htrのセキュリティ・ホールを悪用する(このセキュリティ・ホールのKB番号については,同氏は失念したという)。

 このセキュリティ・ホールはWindows NT 4.0 Service Pack 6aを適用すれば解消できる。しかし,.htr wormが出現したときには,パッチやサービス・パックはおろか,そのセキュリティ・ホール情報も公開されていなかったという。つまり,.htr wormは0-day Exploitであったと,Maiffret氏は述べている。

0-day Exploitでセキュリティ・ホールが明らかに

 米CERT/CCは2001年3月,Solaris OSに対する攻撃が急増していることを警告した。攻撃に悪用されたのは,Solarisにデフォルトでインストールされているデーモン・ソフト「snmpXdmid」のセキュリティ・ホールである。

 米CERT/CCが,あるセキュリティ・ホールが攻撃対象になっていることを警告することは珍しくない。しかしその場合には,まずセキュリティ・ホール自体が警告され,その後「既に公開されている××のセキュリティ・ホールを悪用する攻撃が増えているので,きちんとパッチを適用しよう」といった警告が続く。しかし,snmpXdmidの場合には,いきなり攻撃自体が警告されたのだ。つまり,セキュリティ・ホールは事前に明らかになっておらず,攻撃があって初めてセキュリティ・ホールが明らかになったのだ。このときの攻撃(侵入)に使われたツールが,まさしく0-day Exploitに当たる。

 以上,いくつか0-day Exploitの実例を紹介した。伝聞や推測によるものもあるが,それでも0-day Exploitが机上の空論ではないことが分かってもらえるだろう。

最悪の事態に備える

 次に,Apacheのセキュリティ・ホールに対する検証用ツールを作成したhsj氏に話を聞く機会があったので,0-day Exploitに関する一問一答を紹介したい。同氏は「HighSpeed Junkie!」を主催している。

——Apache のセキュリティ・ホールを悪用するワームは,セキュリティ・ホールとその検証用ツールが公開された直後に出現しました。このことについてどう思われますか。

 [hsj氏] ワームの作者にとって,大きなセキュリティ・ホールは魅力的でしょうから,この問題を利用するワームが出現するのは,ある意味当然でしょう。もちろん,作るだけならともなく,実際に放っちゃうのは倫理的にどうかと思いますが,それを止めるのは難しいでしょうね。「やっちゃダメ」で済むなら,セキュリティなんて必要ないわけですしね(苦笑)。ただ,ワームには,技術的におもしろい部分は滅多にありませんので,個人的にはあまり興味ありません。

——0-day Exploitの脅威についてはどうお考えでしょうか。

 [hsj氏] システムを守る立場としてはキツイなぁ,というのが正直なところですね。0-day Exploitによっては,アプリケーション・レベルのファイアウオールなどで対応できますが,そういったセキュリティ・ツールにもバグがありうるので万全ではありません。

 ただ,積極的にセキュリティ対策を施しているユーザーならば,不要なサービスなどは停止しているでしょう。例えば,IISにおいては,不要なスクリプト・マッピングは削除していると思います。IEでは,インターネットゾーンのアクティブ・スクリプトをオフにしているでしょう。そういった対策を施すことで,影響を受ける可能性を小さくすることはできると思います。

 WebやDNSといった,停止できないサービスを狙う0-day Exploitが出現する場合もあります。しかし,普段からきちんと情報収集していれば,対応する時間が文字通り“0-day”になることはないと思います。もちろん,世界中のだれかが気付く前に,自分が攻撃されてしまった場合には別です。

 対応する時間が少しでもあれば,0-day Exploitといえども,通常の対応で十分です。もしパッチが公開されている場合には,すぐに適用すればよいでしょう。そうでない場合は,あまり現実的ではないかもしれませんが,あらかじめ用意しておいた,別のソフトウエアで構成したマシンと入れ替える方法などが考えられます。0-day Exploitを防げるとうたっているファイアウオール製品もあるようなので,そういった製品の利用も対策となるかもしれません。

 0-day Exploitが出現すること自体は防げないので,結局重要なのは,0-day Exploitが出現した場合,最悪侵入を許してしまった場合を想定した対応手順を事前に決めておくことだと思います。

——最悪の事態を考えて,forensic analysis*の手段や,対応方法を決めておくことが重要ということですね。

 [hsj氏] その通りです。具体的な対応方法はサイトごとに異なるでしょうが,事前に決めておくことが重要です。事態が発生してからあわてて対策を施すとなると,効果的に行うことはむずかしいでしょう。

——ありがとうございました。

* forensic analysisとは,「システムへの侵入の証拠調査」のこと。調査のための手段や手順を指す場合もある。「システムへの侵入」は,DoS攻撃やウイルス感染といった「インシデント」の一つである。そのため,forensic analysisは,インシデントへの対応手順の一つと考えられる。詳しくは次の文書を参照いただきたい。

事前の対策が重要

 0-day Exploit対策としては,hsj氏の言葉にもあるように,事前に対策方法などを決めておくことが重要である。具体的には,代替機の準備や,侵入された場合の証拠分析の手順をまとめた文書やツールを用意しておくことなどが挙げられる。

 侵入を検知するための,ホスト・ベースの侵入検知システム(HIDS)の導入や,特定のぜい弱性に対する保護策(例えば,Buffer Overflow/Format String Protection)を講じておくことも,事前の対策に含まれるだろう。

 このように,事前にいくつもの対策を施すこと——「in-depth protection (周到なる保護)」と呼ばれる——が重要である。「セキュリティ・パッチを必ず適用する」といった対策と同様に,セキュリティを維持するための“鉄則”として考えるべきだろう。


新井悠 (ARAI Yuu)
株式会社ラック コンピュータセキュリティ研究所
y.arai@lac.co.jp


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。