図1 ゼロデイ攻撃はしっかり鍵をかけたつもりなのに思いもよらない方法で破られるようなもの(イラスト:なかがわ みさこ)
図1 ゼロデイ攻撃はしっかり鍵をかけたつもりなのに思いもよらない方法で破られるようなもの(イラスト:なかがわ みさこ)
[画像のクリックで拡大表示]
図2 弱点の公表から対処可能になるまでの間が狙われる場合もある(イラスト:なかがわ みさこ)
図2 弱点の公表から対処可能になるまでの間が狙われる場合もある(イラスト:なかがわ みさこ)
[画像のクリックで拡大表示]

 ゼロデイ攻撃(zero-day attack)とは,「OSやアプリケーションのセキュリティ・ホールを修正するパッチが提供されるより前に,実際にそのホールを突いて攻撃が行われたり,悪用する不正プログラムが出現している状態」を表す言葉として使われている。宝石箱にしっかり鍵をかけて守っていたはずなのに,思いもよらない方法で鍵が破られて中の宝石が盗まれてしまった──そんなイメージだといえるだろう(図1)。ゼロデイという言葉は,修正パッチが提供された日を1日(目)とすると,それ以前に攻撃が始まったという意味でそう呼ばれている。

 セキュリティ関連のニュースなどで「ゼロデイ攻撃」あるいは「ゼロデイ・アタック」という用語を見かける機会が増えてきた。例えば2006年5月下旬に,「Wordユーザーがゼロデイ攻撃を受けた」というニュースが報道され,大きな話題になった。続いて6月にはExcel,7月初めには米 Yahoo!のWebメール・サービスでも見つかるなど,同様の事件が次々と起こっている。

 オープン・ソースなど一部のソフトを除けば,一般にOSやアプリケーションのセキュリティ・ホールをユーザー自信で修正することはできない。つまり,開発元のベンダーがそのホールに対処する修正パッチを提供するのを待つしかない。このため,一般のユーザーにとってゼロデイ攻撃を防ぐのはかなり困難だ。

 セキュリティの専門家によれば,ゼロデイ攻撃は二つのパターンに分類できるという。一つは,セキュリティ・ホールの存在をユーザーもベンダーも知らない状態で,クラッカ(悪意のあるユーザー)だけがホールを見つけて攻撃するというパターンである。もう一つは,セキュリティ・ホール情報が公表されたあと,ベンダーによって修正パッチが提供されるまでの間を突いてクラッカがそのホールを攻撃するというパターンである。こちらは,先ほどの例でいえば,鍵に問題があることは販売店が公表して多くの購入者が知っているが,実際に販売店が鍵を交換するまでに少し期間があり,その間に泥棒が宝石を盗んでしまったというようなイメージといえる(図2)。

 大手ウイルス対策ソフト・ベンダーの米マカフィーによれば,過去に起こったゼロデイ攻撃は,後者のパターンが多いという。その理由として同社では,「ゼロデイ攻撃を狙って不正プログラムを作る人と,セキュリティ・ホールを探し出せる技術を持った人は別であるケースが多いから」(AVERTラボ JAPANの本城信輔ウイルス研究員)と分析している。ほかの専門家からも「ゼロデイ攻撃を狙った不正プログラムには,他人が作った攻撃用コードをほぼそのままの形で組み込んであるケースが多い」(セキュアブレインの星澤裕二プリンシパルセキュリティアナリスト)と同様の意見が聞かれ,公表されたセキュリティ・ホール情報を基にゼロデイ攻撃が数多く実行されているという現実がうかがい知れる。

 こうした状況をかんがみて,修正パッチを提供できるようになるまではセキュリティ・ホール情報を公表しないというスタンスのベンダーがいる。その一方で,とくに海外のセキュリティ・ベンダーを中心に,見つけたセキュリティ・ホール情報をすぐに公表してしまうケースもある。

 世の中の傾向としては,前者の立場を支持するベンダーが多数派のようで,後者についてはゼロデイ攻撃を助長しているといった批判が少なからずある。ただ,修正パッチの提供を待たずに早々とセキュリティ・ホールの存在を公表することが,必ずしも悪いとは限らない。誰かがホールを見つけたということは,クラッカも同様にそのホールを見つけているかもしれないからだ。仮に修正パッチがなくても,ホールの存在さえユーザーが知っていれば,運用で被害を避けたりセキュリティ対策ソフトで回避するといった対策をとることが考えられる。場合によっては,そのアプリケーションを使わないという選択もできる。

 

次のうち,ゼロデイ攻撃の説明として間違っているものはどれでしょう?