「npm install」が命取り？ 自己増殖ワーム「Shai-Hulud」の脅威：ソフトウェアサプライチェーン攻撃対策をGitHubが指南
開発者が何げなくたたくコマンドが、組織への侵入経路になる――。GitHubが警告する、npm環境を狙った自己増殖型ワーム「Shai-Hulud」。その狡猾な侵入プロセスと、情シスが講じるべき防衛策とは。
「開発効率化のためにOSS（オープンソースソフトウェア）を活用する」――。これは現代のソフトウェア開発において当たり前の光景だ。しかし今、その“当たり前”のプロセスそのものが、企業のセキュリティを脅かす最大の穴となりつつある。
開発者がライブラリを取り込むために日常的に使用するパッケージ管理ツール（npmなど）に、悪意あるコードを混入させる「ソフトウェアサプライチェーン攻撃」が激化している。中でもGitHubが2025年12月23日（米国時間）に警鐘を鳴らした自己増殖型ワーム「Shai-Hulud」（シャイ＝フルード）の事例は、多くの情シス担当者や開発マネジャーにとって、悪夢のようなシナリオといえるだろう。
Shai-Huludは、単なるマルウェアではない。開発者の信頼を利用し、正規のパッケージになりすまして組織内部へ侵入、さらにそこから自己増殖を繰り返す。ファイアウォールで外部からの攻撃を防いでいても、内側の開発者が「招き入れる」形になるため、従来の境界型防御では検知が困難だ。
そのコマンド実行が、情報漏えいの引き金に
併せて読みたいお薦め記事
ソフトウェアサプライチェーン攻撃に備える
Shai-Huludは、スクリプト言語「JavaScript」のサーバサイド実行環境「Node.js」のパッケージ管理ツールであるnpmで管理されるJavaScriptパッケージだ。
攻撃の第一波では、侵害されたパッケージメンテナ（パッケージの管理者権限を持つ担当者）のアカウントが悪用された。攻撃者は悪意あるポストインストールスクリプト（パッケージのインストール時に実行されるスクリプト）を注入して悪意あるコードをパッケージに混入させることで、ユーザー組織の機密情報を流出させ、ワームの自己複製と拡散に成功した。サイバー攻撃の足掛かりは1つ作られると、被害は迅速に依存関係全体に波及する。
「Shai-Hulud 2.0」と呼ばれるShai-Hulud攻撃の第二波では、脅威がさらに高度化した。侵害された認証情報を用いた自己複製と拡散の機能が更新され、感染したエンドポイント間での認証情報の再利用が可能になった。またユーザー組織が管理するセルフホステッドランナー（コードの実行インフラ）を悪用することで、感染したエンドポイントがC2（コマンド＆コントロール）サーバから指示を受けられるようになり、より幅広い機密情報が収集された。
この第二波は、CI（継続的インテグレーション）環境を標的としている。マルウェアがCI環境で実行されていることを検知すると、動作を変更するようになった他、特定のビルドエージェントを狙った権限昇格手法が導入された。ペイロードには複数段階構成のマルチステージ型が採用されており、第一波で使用されたペイロードと比較して検知が困難な点も特徴だ。
最新のソフトウェアサプライチェーン攻撃の特徴とは
Shai-Huludは、メンテナのワークフローやCIの公開パイプラインを標的として、複数の段階を踏んでユーザー組織の認証情報を収集することとパッケージインストール時にマルウェアを実行させることに重点を置いている。Shai-Huludの第一波と第二波に共通する特徴として、以下が挙げられる。
- 認証情報関連の侵害
- 攻撃者は、最初に侵害した認証情報やOAuthトークンを足掛かりにして、npmトークンやCIトークン、クラウドサービスの認証情報など、より多様な機密情報を収集し、侵害範囲を拡大する。
- 難読化されたスクリプトのインストール時実行
- 悪意あるポストインストールスクリプトやライフサイクルスクリプトがパッケージまたは依存関係にあるシステムに注入され、その実行時にのみ作動する。ペイロードは特定の条件下で起動される傾向にあり、実行されるインフラに合わせた方法でデータを窃取する。
- 信頼されている名前空間や内部パッケージ名も標的
- ワームは既存のパッケージ名で感染パッケージを公開する。第二波では、感染パッケージのバージョン番号を修正し、正当なアップデートであるかのように装う手口も確認されている。
- 防御策を回避する迅速な開発サイクル
- ワームの亜種が短い間隔で投入され、既存の対策を回避するための変更が施されている。これは、Shai-Huludが計画された組織的な攻撃手法であることを示している。
セキュリティの強化を進めるnpm
Shai-Hulud攻撃のように巧妙化するサイバー攻撃の被害を抑止するために、npmの開発チームはセキュリティ対策の強化を進めている。GitHubはnpmの開発チームの取り組みによって、npmパッケージの管理者がパッケージを公開する全段階でより安全にパッケージを保護できるようになると説明している。
具体的には、まず認証プロトコルの「OpenID Connect」（OIDC）をまとめて導入できる仕組みが用意される。これにより組織が管理する数百個規模のパッケージを、信頼性の高い公開環境へ効率よく移行できるようになる。OIDCを利用できるCIサービスの対象も広がり、「GitHub Actions」や「GitLab」以外のCIサービスでも安全な公開が可能になる。
さらにパッケージを公開する前に確認やレビューのための待機期間（ステージング）を設ける仕組みも導入される。これにより誤った変更や不審な改変を、ユーザーに配布される前に開発チーム内で発見できるようになる。
GitHubやパッケージ管理ツールのユーザーがサイバー攻撃を防ぐには
GitHubは、GitHubやnpmをはじめとしたパッケージ管理ツールを使用する開発者とこれらを扱うメンテナに対して、以下のアドバイスを提供している。
開発者とメンテナへのアドバイス
- 全てのアカウントでフィッシング攻撃に耐性のあるMFA（多要素認証）を有効にする
- トークンには必ず有効期限を設定し、定期的に更新する。組織は最大有効期間ポリシーを強制するとよい。
- GitHubの機能拡張ツール「GitHub Apps」や認証ツール「OAuth Apps」の使用されていないアクセス権を監査し、無効にする。
- 開発作業にはオンライン開発環境「GitHub Codespaces」や仮想マシン、コンテナなどのサンドボックスを使用する。これによりマルウェアを誤って実行しても、そのアクセス範囲を制限できる。
メンテナへのアドバイス
- ブランチ保護を有効化し、攻撃者が有効なトークンを持っていても、悪意ある更新がメインブランチに直接プッシュされないようにする
- トークンの代わりに、npmの「トラステッドパブリッシング」を使用する。これは、CI/CD（継続的インテグレーション／継続的デリバリー）ツールベンダーから提供される一時的な認証情報を使用することで、長期間有効なトークンを排除する仕組みだ。この仕組みは「PyPI」「RubyGems」「NuGet」など、他のパッケージ管理ツールも備えている。
- CIの依存関係で利用するアクションやツールのバージョンは明示的に固定してコードスキャンを有効化し、コードスキャンアラートを忘れずに解決する。
- パッケージの成果物（アーティファクト）を継続的に監視し、SRI（ファイルのハッシュ値を用いて内容の改ざんを検知する仕組み）や成果物の証明情報を活用して、公開されているtarballファイルやバンドルが元となるソースコードから正しく生成されたものかどうかを検証する。
Copyright © ITmedia, Inc. All Rights Reserved.