Shai-hulud：サプライチェーン攻撃の隠れたコスト

出典：Andriy Popov（Alamy Stock Photo経由）

オープンソースのソフトウェアコンポーネントを狙った多数のマルウェア攻撃により、何千ものソフトウェアパッケージやリポジトリが侵害されてきた。しかし、これらの攻撃が組織にもたらした実務上の被害は定量化しにくい。長期的かつ間接的なコストこそが、組織にとって最も重大になる可能性がある。

オープンソースのコンポーネントやソフトウェアは、長年にわたり脅威活動の確立された供給源である。広範な利用に加え、プロジェクトごとの支援体制のばらつきが大きいこと――その一因として、多くがコミュニティによる保守に依存していること――により、深刻な脆弱性（および脅威キャンペーン）が見落とされることがある。2021年の壊滅的なLog4Shell脆弱性が思い起こされるし、昨年末のより最近のReact2Shellも同様だ。 

しかしここ数カ月、オープンソースコミュニティに対して、やや新しいタイプのサプライチェーン脅威が現れている。攻撃者はコンポーネントライブラリに自己増殖型マルウェアを放ち、下流の被害者をインフォスティーラーで狙っている。 

この最も有名な最近の例がShai-huludだ。これはNPMプロジェクトを標的とするワームで、被害者が汚染されたコンポーネントをダウンロードすると感染が成立する。被害者のマシンに入り込むと、マルウェアはそのアクセス権を利用して被害者が保守しているコンポーネントを感染させ、汚染版を自己公開する。下流の被害者も同じ運命をたどる。Shai-huludワームには、認証情報を盗み、幅広いユーザーに影響を与えた複数の後継が存在した。 

もう一つよく知られたサプライチェーン脅威がGlassWormで、技術的にはワームでも自己増殖型でもない。しかし、昨秋以降、開発者の認証情報を広範に狙ってきた。開発者が汚染されたOpen VSXコンポーネントをダウンロードすると、GlassWormは認証情報と暗号資産ウォレットを窃取する。攻撃者は侵害した開発者アカウントへのアクセスを手動で利用し、悪意あるバージョンを公開して感染をさらに拡大できる。 

これらの攻撃による被害の範囲は、依然としてはっきりしない部分がある。この波の初期のサプライチェーン攻撃の一つである開発者Qixを狙った攻撃では、人気の高いNPMコンポーネント18個が汚染された――それらは合計で毎週20億回以上ダウンロードされていた。防御側が迅速に対応し、攻撃はほぼ尻すぼみに終わったが、Shai-huludの各波では、一定期間にわたり数百のソフトウェアパッケージと数千のリポジトリが汚染された。 

サイバー即応性とインシデント対応企業Sygniaのエンタープライズセキュリティコンサルタント、Omer Kidronは、ダウンロード数がすべてではないと指摘する。

「サプライチェーンのインシデントをめぐる話題は、しばしば生のダウンロード数に焦点が当たりがちだが、現実的な被害の見方は、影響を受けた組織の内部でのインパクトにある。何が実行され、どこで実行され、何が露出したのかだ」とKidronは言う。「悪意あるパッケージが100万回ダウンロードされたからといって、100万社が侵害されたことにはならない――しかし、多くのビルド環境や開発環境に配布され得ることを示すシグナルにはなる」

サプライチェーン脅威における「被害」の定義

「これらの攻撃はどれほどの被害をもたらしたのか？」という問いへの答えは複雑だ。

Checkmarx Zeroのセキュリティリサーチ・アドボケイトであるDarren MeyerはDark Readingに対し、これら大規模キャンペーンの多くの攻撃は阻止されたか、少なくとも迅速に緩和されたと語る。たとえば、開発者Qixの侵害を通じてChalkなどのコンポーネントを狙った攻撃は、メンテナーの迅速な対応とコミュニティへの透明性のあるコミュニケーションにより、速やかに封じ込められた。Shai-huludも影響は大きかったが、NPMやGitHubなどが拡散停止に取り組んだため、比較的早期に封じ込められた。 

しかし、害やコストは常に直接的な侵害として測られるわけではない。Meyerによれば、Checkmarxは害とコストを3つの異なる観点で捉えている。 

第一は一次被害で、直接的かつ重大な侵害が起きるケースだ。これは起こり得るが、大規模に発生するのはまれで、その理由の一部は攻撃者の拙さ（Qix攻撃が例だと彼は言う）にあり、また一部は防御側の迅速な対応にある。第二の二次被害は、被害自体は小さいものの、開発者がクリーンアップのためにリソースと時間を費やさねばならないケースで、より一般的だ。そして第三の間接被害は、脆弱かどうかにかかわらず、従業員が新たに出現する脅威への防御にリソースを割かねばならないケースで、さらに一般的である。 

「悪意あるコンテンツが判明した場合、組織はそれでも一定レベルのインシデント対応に取り組まなければならない。最低限、セキュリティチームは、脅威そのものを理解しようとすることと、自組織への影響の証拠があるかを調査することの両面から、自組織に対するリスクを評価しなければならない」と彼は言う。「この対応作業は高コストだ。対応者が投入する実際の時間と費用だけでなく、組織にもたらす混乱があるからだ」

アプリケーションセキュリティベンダーBlack DuckのシニアR&DマネージャーであるChristopher Jessは、これを「高くつく検証税」と呼ぶ。 

「インシデントが素早く検知されたとしても、エンジニアリングチームとセキュリティチームは、不快な問いに迅速に答えなければならない。『露出していたのか？ どのパイプラインがそれを取り込んだのか？ どの開発者エンドポイントがインストールしたのか？ どの認証情報が危険にさらされた可能性があるのか？』それが緊急トリアージ、ログ全体にわたるハンティング、ビルドの再実行、成果物の検証、認証情報のローテーション、そして時にはリリースプロセスへの信頼の再構築を促す」とJessはメールで書いている。「これらのキャンペーンは開発者ツールチェーンを狙うため、潜在的な影響範囲（blast radius）は過大になりやすく、ソースへのアクセス、署名鍵、クラウド認証情報、そして下流リリースを汚染する能力まで含まれる」

この件で何千社もの企業がインシデント対応会社を雇っているわけではないかもしれないが、被害は現実のものだ。 

サプライチェーン攻撃による長期的被害は依然不透明

もう一つの考慮点は、これらのインシデントによる長期的で持続する被害である。SygniaのKidronは、認証情報の窃取のような侵害の影響は、より長い時間軸で発現すると説明する。問題が十分に封じ込められていなければ、攻撃者はアクセスを販売したり、後続の活動を後日行うために利用したりできる。 

「実際には、被害は時間枠にわたって展開する。直後――露出から数時間〜最初の数日以内では、主要なリスクは認証情報の露出だ。これらのキャンペーンは、トークンやシークレットにアクセスできる開発者経路やCI/CD経路の内部で実行されるよう設計されている」と彼は言う。「それらのシークレットが漏えいすると、下流の被害は抽象的なものではない――攻撃者はそれらを使って（あるいは売って）被害者として認証し、プライベートリポジトリにアクセスしたり、データを取得したり、コードを改ざんしたり、ビルドをトリガーしたり、パッケージを公開したり、クラウドリソースにアクセスしたり、正当なIDの『代理』として行動したりできる」

前述のとおり、封じ込めのプロセスは、その後、一次被害が軽微であっても対処に数週間かかることがある。これは、他の計画済みの成果物やリリースの遅延につながり得るし、実際しばしばそうなる。

多くのサプライチェーン攻撃は、コミュニティによる検知、レジストリからの削除、スキャンの改善により迅速に止められているが、とJessは言う。それでも、侵害後の認証情報のローテーションであれ、進行中のキャンペーンにおける侵害指標（IOC）の確認であれ、迅速な行動が重要であることを、これらのインシデントは改めて思い起こさせる。 

もちろん、準備も重要だ。 

「リーダーへの教訓は、何十年もかけて培われたセキュリティのベストプラクティスを徹底することだ」とJessはメールで書いている。「オープンソースコードを盲目的に信頼しない。インストール／ビルドがアクセスできる範囲を減らす。短命で最小権限の認証情報を優先する。パッケージ／拡張機能の制御（許可リストと社内ミラー）を強化し、継続的な監視を追加して、影響を迅速に立証できるようにする」