ゼロデイ脆弱性とは

ゼロデイ脆弱性、エクスプロイト、攻撃

この3つの用語は同じ意味で使われがちですが、それぞれ異なるものを指します。

• ゼロデイ脆弱性：ベンダーに知られていない、または修正のない欠陥そのもの。
• ゼロデイエクスプロイト：その欠陥を悪用するコードや手法。
• ゼロデイ攻撃：実際の標的に対して使われたエクスプロイト。

ベンダーが修正を出荷すると、その欠陥はゼロデイではなくなり、既知の脆弱性（しばしばnデイと呼ばれます）になります。そこから2つ目の競争が始まります。攻撃者はパッチを分析し、まだ適用していないシステムを探してスキャンするため、パッチ未適用のまま放置された既知の脆弱性は、元のゼロデイと同じくらいの被害をもたらしえます。

依存関係に潜むゼロデイ

現代のアプリケーションのコードの大半はオープンソースパッケージに由来し、その大半は推移的依存関係、つまりチームが選んだのではなく、ほかのパッケージによって取り込まれたものです。そのいずれかにゼロデイがあれば、それは自社製品のゼロデイです。

最もよく知られている例がLog4Shell（CVE-2021-44228）です。2021年12月に公開されたこの脆弱性により、ログに記録されるメッセージを制御できる攻撃者は、Apache Log4j 2を通じて任意のコードを実行できました。CVSSは最大の10.0でした。ほとんどのチームにとって難しかったのは修正ではなく、その前の問いでした。自社のどのアプリケーションに、どのバージョンのlog4j-coreが含まれているのか。Log4jは通常「依存関係の依存関係」であり、多くのチームがそれを突き止めるのに何日も費やしました。

サプライチェーンのゼロデイは、必ずしもバグとは限りません。2024年3月、Andres Freundは、SSHログインがCPUを使いすぎていることに気づいたことをきっかけに、xzのバージョン5.6.0と5.6.1にバックドア（CVE-2024-3094）を発見しました。サプライチェーン攻撃の一般的な形態である悪意あるパッケージリリースも同じように機能します。Shai-Hulud npmワームの被害を受けたチームのように、感染したバージョンを最初にインストールしたチームは、まだどのアドバイザリにもスキャナーにも知られていない攻撃に直面します。

依存関係がゼロデイの影響を受けたときの対応

1. どこにあるかを特定する。推移的依存関係として含まれている場合も含め、影響を受けるコンポーネントを含むすべてのアプリケーション、イメージ、リリースを洗い出します。そのためには、ビルドごとの正確なSBOMが必要です。ロックファイルは、インストールスクリプトがダウンロードするコードやコンテナイメージのOSレイヤーなど、パッケージマネージャー以外から取得された依存関係を見逃します。
2. 露出期間を割り出す。どのビルドが脆弱なバージョンを出荷し、それはいつからか。これにより、何を調査し、何を報告すべきかがわかります。
3. 封じ込める。修正や回避策があれば適用し、CVEが割り当てられたら、新しいビルドが脆弱なバージョンを出荷しないようにします。CVEの修正をご覧ください。
4. 悪用の有無を確認する。露出期間中にその欠陥が自社に対して使われた形跡がないかを調べ、到達されえたシークレットをすべてローテーションします。

最初の2つのステップについては、「影響を受けているか？」で詳しく解説しています。

誰も知らないゼロデイから身を守れるか

パッチ適用でもスキャナーでも守れません。どちらも欠陥が既知であることが前提だからです。公開前に有効なのは、攻撃者が見つけた欠陥で何ができるかを制限することです。

• 最小権限。各システムと各CIジョブには、必要なアクセス権とシークレットだけを与えます。
• エグレス制御。システムが必要としないホストへの外向き接続をブロックすれば、エクスプロイトが実行されても攻撃者にデータを送信できません。CIビルドでは、新たな悪意あるパッケージの最初の被害者になった場合でも機能する数少ない対策の1つです。GitHub Actionsのエグレスポリシーをご覧ください。
• 多層防御。1つの欠陥ですべてが開かれないよう、対策を重ねます。
• 後から検索できる記録。ゼロデイが公開されたとき、対応の速さは、自社が何をビルドし出荷したかを把握しているかどうかにかかっています。

CRACIが役立つこと

CRACIはGitHub ActionsのジョブをCRACI独自のランナーで実行し、すべてのビルドを実行と同時に記録します。

• ビルド時SBOMは、ロックファイルベースのツールが見逃す隠れた依存関係も含め、各ジョブが実際に取り込んだパッケージを一覧にするため、実際にビルドされたものから「どこにあるか」に答えられます。ビルド時SBOMをご覧ください。
• ビルド履歴には、過去のすべてのビルドとそのSBOM、そしてどのビルドに脆弱な依存関係（直接・推移的を問わず）が含まれていたかが表示されるため、影響を受けていた期間がわかります。
• ポリシーゲートは特定のCVEを含むビルドをブロックできるため、新しいビルドが脆弱なバージョンを再び出荷することはありません。
• デフォルト拒否に設定したエグレスポリシーは、誰も見たことのない攻撃の最中でも、ビルドが必要としないホストへの接続をブロックします。

ゼロデイ脆弱性：よくあるご質問

ゼロデイ脆弱性とは何ですか？

ベンダーやメンテナーが修正をリリースする前に、攻撃者が把握している、またはすでに悪用しているセキュリティ上の欠陥です。名前は、防御側がパッチを当てるために与えられた日数、つまりゼロ日を表しています。

ゼロデイ脆弱性、エクスプロイト、攻撃の違いは何ですか？

脆弱性は欠陥そのものです。エクスプロイトはそれを悪用するコードや手法です。攻撃は実際の標的に対して使われたエクスプロイトです。

ゼロデイはいつゼロデイでなくなりますか？

修正が利用可能になったときです。それ以降は既知の脆弱性（nデイと呼ばれることもあります）となり、リスクはまだ修正を適用していないシステムに移ります。

スキャナーはゼロデイを検出できますか？

アドバイザリとの照合では検出できません。脆弱性スキャナーはコンポーネントを公開済みのアドバイザリと照合しますが、ゼロデイにはまだアドバイザリがありません。スキャナーやSBOMが提供するのは、アドバイザリが公開された瞬間に検索できるインベントリです。

ゼロデイが自社のソフトウェアに影響するかどうかを知るには？

推移的依存関係を含め、各ビルドと各リリースに何が含まれているかの正確なインベントリから、影響を受けるコンポーネントとバージョンを検索します。次に、どのリリースがそれをいつから出荷していたかを割り出し、露出期間を把握します。