ゼロデイ攻撃とは何か 意味や対策をわかりやすく解説 | Codebook|Security News
Codebook|Security News > Articles > 脅威インテリジェンス > ゼロデイ攻撃とは何か 意味や対策をわかりやすく解説

脅威インテリジェンス

Cyber Intelligence

Intelligence

Log4j

ゼロデイ攻撃とは何か 意味や対策をわかりやすく解説

Tamura

Tamura

2023.04.24

 

セキュリティニュースやベンダーのレポートでは、「ゼロデイ攻撃」という言葉がよく使われています。「ゼロデイ脆弱性」「ゼロデイエクスプロイト」という派生形も存在し、最近では「Nデイ攻撃」という言葉まで登場しています。

こうした状況を踏まえ、本記事ではゼロデイ攻撃の意味と、その関連用語の意味について、わかりやすく解説していきます。また、難しいと言われるゼロデイ攻撃対策や、そのポイントについても解説します。

ゼロデイと、その関連用語

ゼロデイ攻撃とは

ゼロデイ攻撃とは、修正プログラム(パッチ)が公開される前の脆弱性を悪用したサイバー攻撃のことです。パッチの存在しない脆弱性が悪用されるため、攻撃を受けないよう対策することは、非常に困難です。

以下は、ゼロデイ攻撃の流れを簡単に図示したものです。

ゼロデイの意味

図のように、ゼロデイ攻撃は、脆弱性が発見されてから、ベンダーがパッチを開発し公表するまでに発生するタイムラグを悪用します。「ゼロデイ」という呼称は、パッチが公表された日を「1日目」として、攻撃が行われた日を「0日目」に例えることから来ています。したがって、パッチ公表済みの脆弱性を悪用して行われる攻撃は、ゼロデイ攻撃とは言いません。

Nデイ攻撃とは

ちなみに、パッチが公表されてから、利用者が実際にパッチを適用するまでの期間に脆弱性を悪用する攻撃は、「Nデイ攻撃」と呼ばれます。多くの場合、パッチ公表後には脆弱性の詳しい情報が提供されるため、攻撃者はエクスプロイト(後述)を作るための材料を容易に得ることができます。よって、熟練度の低い攻撃者にとっては、ゼロデイ攻撃よりもNデイ攻撃の方が実行しやすい、と言うことができます。

エクスプロイト、PoCとは脆弱性の悪用を助けるもの

脆弱性を悪用するための手法やコードは、エクスプロイト(Exploit)エクスプロイトコード、PoC(Proof-of-Concept:概念実証)、実証コードなどと呼ばれます。これらは、どの脆弱性に対しても作成され得るものであり、パッチ未公表の脆弱性だけに存在するものではありません。ただ、ゼロデイ攻撃の情報収集をする中で、頻繁に出くわす重要な用語ではあります。例えば、「ある製品の脆弱性のパッチが公表されたが、すでにゼロデイ攻撃で悪用されていた」などというニュースやレポートを見ると、多くの場合「公表のX日前にエクスプロイトが攻撃者の間で出回っていた」などと書かれることがあります。このエクスプロイトの流通は、上の図の青い箇所に該当します。具体的には、悪意の人物が悪用のための手法やコードをダークウェブなどで共有・売買するケースや、セキュリティリサーチャーがパッチ公表前に脆弱性の存在やその詳細情報、考えられる悪用の手法をネット上で指摘するケースがあります[*1]。

ゼロデイ攻撃で使われたエクスプロイトは、「ゼロデイエクスプロイト(Zero-day Exploit)」と呼ばれます(ただし、これはゼロデイ攻撃そのものを指す言葉として使われることもあります)。

ゼロデイ脆弱性とは

ゼロデイ脆弱性の定義は、実は文献によって様々です。「ゼロデイ攻撃で悪用された脆弱性」「パッチ公表前に攻撃で悪用された脆弱性」という意味で使われることもあれば、「パッチがまだ公表されていない、悪用可能な脆弱性」という意味で使われる場合もあります。本記事では、zero-day.cz[*2]による以下の定義を参考に、前者の「ゼロデイ攻撃で悪用された脆弱性」「パッチ公表前に攻撃で悪用された脆弱性」という意味で、「ゼロデイ脆弱性」を使用します。

ゼロデイ脆弱性(Zero-day vulnerability)とは、ベンダーがセキュリティ修正プログラムを出す前に、実際の攻撃で悪用された脆弱性

ゼロデイ候補(Zero-day candidate)とは、標的型攻撃で使用され得るものの、公式のセキュリティ修正プログラムのリリース前に実際に悪用されたと認めるための証拠が十分に存在しない脆弱性

ゼロデイ攻撃の対策とは

ここまで、「ゼロデイ攻撃」「ゼロデイ」「Nデイ攻撃」「(ゼロデイ)エクスプロイト」「ゼロデイ脆弱性」の意味を整理しました。続いて、ゼロデイ攻撃の対策について考えていきます。

冒頭で述べた通り、ゼロデイ攻撃を受けないよう対策することは非常に困難です。ベンダーからパッチが公開されない状態では、攻撃を受けたことに気付くことはできても適切な対応を取りにくい、という問題があるためです。ただし、「対策が不可能」というわけではありません。情報処理推進機構(IPA)[*3]は、ゼロデイ攻撃の対策として以下のものを挙げています。

被害を予防する対策

・資産の把握、対応体制の整備

・NDR等を用いたネットワークの監視および攻撃通信の遮断

・EDR等を用いたエンドポイントの監視、防御

・セキュリティのサポートが充実しているソフトウェアやバージョンを使う

・利用するソフトウェアの脆弱性情報の収集と周知、対策状況の管理

・セキュリティ診断やペネトレーションテストを行う

関連記事:EDRは必要?アンチウイルスやEPPとの違い、運用コストは?

攻撃の予兆/被害の早期検知

・UTM、IDS/IPS、WAF、仮想パッチ等の導入

修正プログラムリリース前の対応

・回避策や緩和策の適用

・当該ソフトウェアの一時的な使用停止

修正プログラムリリース後の対応

・修正プログラムの適用

被害を受けた後の対応

・組織の方針に従い各所(上司、CSIRT、関係組織、公的機関等)へ報告、相談する

・影響調査および原因の追究、対策の強化

パッチ公表前にできるゼロデイ攻撃対策

これらはいずれも、組織のシステム管理者が行う対策となっています。上記の通り、パッチ公表後の対策は「パッチを適用する」ことに尽きます。これに対し、パッチ公表前にできる9つの対策は、以下の5点に集約されます。

(1)脆弱性や攻撃を発見・検知するため、自社資産を把握・監視する

(2)脆弱性情報を収集・活用する

(3)充実したサポート(パッチや回避策=Workaroundを素早く提供する、等)を提供する製品を使う

(4)パッチがリリースされていなくても、回避策がリリースされているなら適用する

(5)回避策もなければ、使用中止も視野に入れて検討する

対策のポイント

ここまで、ゼロデイ攻撃の一般的な対策を紹介しました。続いて、上記のパッチ公表前にできる対策のうち、(1)と(2)のポイントを詳しく解説します。

(1)資産の把握・監視のポイント

ネットワークやエンドポイントの監視や、脆弱性管理を行うためのツールは、様々なベンダーから提供されています。このうち、アタックサーフェス・マネジメント(ASM)ツールは、自社資産に設定不備や脆弱性がないかを、攻撃者の目線から継続的に監視できるため、効率的かつ素早い対応につながります。

関連記事:アタックサーフェスとは? 具体例や管理のポイント

(2)脆弱性情報を収集・活用する際のポイント

幅広い情報ソースを見る

広く利用されている脆弱性情報のソースとしては、以下のものが挙げられます。

ベンダーや開発元の公式サイト/SNS

例:マイクロソフト社であれば月例パッチ(いわゆるPatch Tuesday)などが有名

セキュリティ専門機関の公式サイト/SNS

例:IPA(「重要なセキュリティ情報」のページ)、JPCERT/CC(「注意喚起」のページ)、米国CISAのアラートやアドバイザリKnown Exploited Vulnerabilities Catalog(KEV)など

無償で利用できる脆弱性情報データベース

例:米国NISTのNational Vulnerability Database(NVD)、MITRE社のCVE、JPCERT/CCとIPAが共同運営するJapan Vulnerability Notes(JVN)JVN iPediaなど

これらはいずれも信頼されている機関や企業が運営しているものであり、一般的な脆弱性情報のソースとしては有益です。しかしゼロデイ攻撃では、まだ公式発表がされていない脆弱性(よって通常は、CVE IDの付与すらされていない脆弱性)が悪用されます。

もちろん、ゼロデイ攻撃対策には上記の情報源も有効です。例えば、すでに他社が受けたゼロデイ攻撃と同様の攻撃を、自社が受けていないか判断するために詳細な情報を集めたい場合です。一方で、ゼロデイ攻撃情報をより早くキャッチできる以下のような情報源も存在します。

セキュリティ専門ニュースサイト

信憑性では公式情報や政府の情報に及ばないものの、ゼロデイ攻撃の発生を素早く、大きく(時に大げさに)報道してくれるメディアが、多数存在します。弊社のサイトでは、こうしたサイト(海外メディア)の記事のうち主要なものを厳選し、一部翻訳・要約したものを、Threat Reportとして公開しています。

関連記事:Threat Report

セキュリティリサーチャーやジャーナリストのSNS

過去には、リサーチャーやジャーナリストがSNSで投稿したことがきっかけで、ゼロデイ攻撃が広く知れ渡った例がありました。最近の例では、GoAnywhere MFTの脆弱性CVE-2023-0669)や、Windowsサポート診断ツールにおけるリモートコード実行の脆弱性CVE-2022-30190、通称「Follina」)の悪用が、これに該当します。

GitHub、ペーストサイト、Telegram、ダークウェブフォーラム

これらの場所で、PoCやエクスプロイトコードが共有、販売されることがあります(ただし、これはゼロデイ攻撃に限った話ではありません)。

以上のソースのうち、自社と関係の深いものをリスト化して定常的に見ておくことで、いざゼロデイ攻撃が発生した時、迅速な対応につながるでしょう。ただ、膨大なソースを1つ1つ閲覧したり、RSSやアラートを設定したりするのは、なかなか大変な作業です。まして、個々の情報がどれくらい信頼でき、どれほど重要で、注目されているのかを評価するのにも労力がかかります。このため、脅威インテリジェンスフィードを導入して情報収集することがおすすめです。脅威インテリジェンスフィードは、膨大なネット空間に散らばる脆弱性情報を自動で収集し、分析や対応に活かしやすい形に処理してくれます。

最後に:脆弱性管理に役立つ脅威インテリジェンスツールを紹介

ゼロデイ攻撃への対策は難しいと言われます。しかし、通常の攻撃と同様、自社の弱点を知り、膨大な脅威情報を上手に活用することで、被害を予防したり最小限に抑えたりすることが可能です。

最後に、このプロセスにかかる労力を大きく軽減する上で有効な脅威インテリジェンスのツールを、いくつかご紹介します。マキナレコードでは、脅威インテリジェンスに活用できるツールや、インテリジェンスの導入支援を行うコンサルティングサービスを提供しております。

脅威インテリジェンスフィード:OSINT

Silobreaker

Silobreakerはサーフェスウェブからデータを集積し、ダッシュボード上に可視化するツールです。ニュース、ブログ記事、ソーシャルメディアなどの18か国語のソースからデータを自動収集し、傾向把握がしやすい形(グラフ、マップなど)に処理した上で表示します。

以下の画像は、Silobreakerの操作画面(ダッシュボード)です。このダッシュボードを使って「重大かつ悪用可能なCVE」に関するトレンドを追跡することが可能です。

 

脅威インテリジェンスフィード:Deep & Dark Web, Vulnerability Intelligence

Flashpoint / VulnDB

Deep & DarkWeb(DDW)に特化した検索・分析ツールです。ダークウェブ等の不法コミュニティで、どのようなエクスプロイトが議論・取引されているかをモニタリングできます。また、Flashpointの一機能として、CVE/NVDにない脆弱性情報各脆弱性のメタデータを豊富に含んだ脆弱性データベース(VulnDB)を利用いただけます。

 

コンサルティングサービス:インテリジェンスの導入支援

インテリジェンスを始めるための支援を、マキナレコードのコンサルタント及びアナリストが実施いたします。

対象となるお客様例

・インテリジェンスが重要なことはわかっているが、何から始めたらいいのかわからない

・情報が散在しており、活用しきれていない

・どういった情報があつめられ、どのように活用すればいいかがわからない

サービス内容例

・要件定義の策定支援

・インテリジェンスを始めるにあたっての基礎トレーニング

・必要なツールの選定

・インテリジェンスを活用するためのレポーティング手法

・他サービスとのインテグレーション

・運用支援

 

注釈

[1] リサーチャーが、発見した脆弱性の情報をベンダーより先に公表することに、違和感を覚える人もいるかと思いますが、実際には、様々な理由でこういったことが発生しています。この理由を理解する上で、 OWASP Foundationが公表している“Vulnerability Disclosure – OWASP Cheat Sheet Series”が参考になるかと思われます。この資料は、脆弱性を発見した後に開示(disclose)する方法を、次の3つのタイプに分類しています。

①Private Disclosure(発見者がベンダーにのみ報告)

②Full Disclosure(発見者が世の中全体に公表)

③Responsible or Coordinated Disclosure(発見者は、最初ベンダーにのみ報告し、パッチが入手可能になったら全ての情報を公表)

「リサーチャーがベンダーより先に公表する」は②に該当しますが、資料によれば、これは「発見者が①を行ったのにベンダーに無視された」「発見者が③を行ったが設定した期限までにベンダーが公表を行わなかった」といった理由で行われるとのことです。なお、資料は②を、他の方法が全て失敗した際や、エクスプロイトコードがすでに公開されている際の最後の手段としてのみ検討すべきだとしています。

[2] Cybersecurity Help, Zero-DAY Vulnerability Research(2023年4月21日閲覧)

[3]独立行政法人 情報処理推進機構, 2023年3月, 情報セキュリティ10大脅威 2023 ~全部担当のせいとせず、組織的にセキュリティ対策の足固めを~ [組織編]

Writer

Tamura株式会社マキナレコード インテリジェンスアナリスト・翻訳者

著者

一橋大学卒業後、新聞記者などを経て、マキナレコード入社。以降、翻訳スタッフとして、情報セキュリティやダークウェブ関連のインテリジェンスレポートや、マニュアル文書等の英日翻訳を担当。現在、アナリストチームの一員として分析・報告業務に携わる。翻訳者評価登録センター (RCCT)登録翻訳者。資格区分:Professional Translator(T00074)。

Special Feature特集記事

Cyber Intelligenceサイバーインテリジェンス

Security情報セキュリティ