- npmエコシステム全体で破壊的マルウェア亜種が拡散しており、GitLabのセキュリティチームがこれを検知
- マルウェアはShai-Huludの進化形で、感染した開発者の他のパッケージまで自動感染させるワーム型伝播構造を持つ
- GitHub・AWS・GCP・Azureなどから認証情報を窃取し、攻撃者が管理するGitHubリポジトリへデータを流出
- GitHubおよびnpmへのアクセスが同時に遮断されると、**ユーザーデータを即座に削除する「デッドマンスイッチ」**を内蔵
- GitLabは自社システムが感染していないことを確認しており、Dependency ScanningとGitLab Duo Chatによる検知・対応策を提供
攻撃の概要
- GitLabのVulnerability Researchチームがnpmエコシステムで大規模なサプライチェーン攻撃を検知
- 内部監視システムが複数の感染パッケージを発見
- マルウェアはShai-Huludの亜種であることを確認
- マルウェアはワーム型伝播を通じて、感染した開発者の他のパッケージまで自動感染
- GitLabは自社で悪性パッケージを使用していなかったことを確認し、セキュリティコミュニティと情報を共有
攻撃の内部構造
- 内部監視システムが検知した悪性npmパッケージは次の機能を実行
- GitHub、npm、AWS、GCP、Azureの認証情報収集
- 窃取したデータを攻撃者管理のGitHubリポジトリへ送信
- 被害者の他のパッケージを自動感染
- インフラへのアクセスが遮断されると破壊的ペイロードを実行
- 複数の感染パッケージが確認されており、調査は継続中
技術分析: 攻撃の進行方式
初期感染ベクター
- マルウェアは多段階のローディング過程を通じてシステムに侵入
- 感染パッケージの
package.jsonに**setup_bun.js**スクリプトを追加
- 表向きはBun JavaScriptランタイムのインストール用に偽装
- 実際には**
bun_environment.js**（10MB、難読化されたペイロード）を実行
- 小さなローダーファイルと大型の難読化ペイロードで構成され、検知を回避
認証情報の収集
- 実行直後にさまざまなソースからトークンおよび機密情報を収集
- GitHubトークン(
ghp_, gho_)
- AWS、GCP、Azureの認証情報
- npmトークン（
.npmrcおよび環境変数）
- Trufflehogツールを使ってホームディレクトリ全体をスキャンし、APIキー・パスワード・Git履歴などを探索
データ流出ネットワーク
- 窃取したGitHubトークンで**“Sha1-Hulud: The Second Coming.”**という説明を含む公開リポジトリを作成
- そのリポジトリがデータのドロップボックス役を果たす
- GitHub Actionsランナーを設置して永続性を確保
- 権限が不足する場合、同じマーカーを持つ他のリポジトリを検索し、別システムのトークンを再利用
サプライチェーン伝播
- 窃取したnpmトークンを使って被害者のすべてのパッケージを感染
- 元のパッケージをダウンロード
setup_bun.jsをpreinstallスクリプトとして挿入bun_environment.jsペイロードを追加- バージョン番号を増加
- 感染パッケージをnpmに再配布
デッドマンスイッチ
- マルウェアはGitHub（データ流出）とnpm（伝播）へのアクセスを継続的に監視
- 両チャネルがともに遮断されると即座にデータ破壊を実行
- Windows: ユーザーファイルを削除し、ディスクセクターを上書き
- Unix系:
shredコマンドでファイルを上書きした後に削除
- GitHubリポジトリの一括削除やnpmトークンの大量失効時には、感染システムが同時にデータ削除を実行するリスクが存在
侵害指標 (IoC)
- 主な検知指標
- ファイル:
bun_environment.js（悪性post-installスクリプト）
- ディレクトリ:
.truffler-cache/, .truffler-cache/extract/
- プロセス:
del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
- コマンド:
curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"
GitLabの検知および対応支援
- GitLab Ultimateユーザーは組み込みのセキュリティ機能で即座に露出有無を確認可能
- Dependency Scanningを有効化すると、
package-lock.jsonまたはyarn.lock内の感染パッケージを自動検知
- 感染パッケージを含むマージリクエストでは警告を表示
- GitLab Duo Chatと連携し、迅速な問い合わせベースの検知が可能
- 例: 「Shai-Hulud v2キャンペーンの影響を受けた依存関係はあるか？」
- Security Analyst Agentがプロジェクトの脆弱性データを照会し、即答を提供
- 複数のリポジトリを管理するチームには、CI/CDベースの自動検知とエージェントベースの迅速対応の併用を推奨
今後の見通し
- 今回の攻撃は、攻撃インフラを守るために被害者データの破壊を利用する新たな形のサプライチェーン攻撃と評価される
- GitLabはコミュニティと協力して安全な復旧戦略を開発中であり、自動検知システムで亜種を継続監視
- 早期の情報共有を通じてデッドマンスイッチによる二次被害の防止を目指す
1件のコメント
Hacker Newsのコメント
1か月ほど前、面倒な作業をする必要があって NPM パッケージを探していた
brew install npmを実行したら 依存関係の雪崩 が始まり、いったん立ち止まってリスクと利益を考えた末、結局brew uninstall npmで元に戻した代わりに古い Unixユーティリティのパイプライン と awk で解決したが、今思えば最高の判断だった
NPM はブラウザ互換性の問題を解決するために作られたツールなので、ブラウザのない環境では不要な複雑さを招く
Node や Python のように依存関係の多いエコシステムのコードをメインシステムで直接実行すると、サプライチェーン攻撃にさらされるリスクが大きい
だから私は Python や JS インタープリタをベースシステムにそもそも入れていない
結局やめてしまったが、今となってはあれで正しかった気がする
「GitHub が悪意あるリポジトリを大量削除したら、何千ものシステムが同時にユーザーデータを破壊しうる」という話があったが、
まるで人質事件のようだ — だから 「人質を撃て」 という冗談が出る
私も今回の npm 攻撃の被害者 だ
GitHub CLI が HOME ディレクトリに 平文の OAuth トークン を保存することを知って衝撃を受けた
攻撃者がアクセスできれば、私のアカウントでほぼ何でもできたはずだ
macOS では OS のキーチェーンに安全に保存される — 関連議論
Chrome は OS の保護機能を使うが、Firefox はまだそうではない
結局 sandbox ベースのアクセス制御 が根本的な解決策だ
ただしプラットフォーム間で一貫した解決策がなく、MacOS でも完全な方法は存在しない
~/.dev-envディレクトリが作られ、私のノートPCが GitHub runner に変わっていたBluefin Linux の 読み取り専用ファイルシステム のおかげで被害が軽減されたのかもしれない
みんな npm ばかり責めるが、GitHub の責任 も大きい
悪意あるリポジトリを素早く検知できず、すでに マルウェアリポジトリ問題 は深刻だ
もしひそかに外部サーバーへ送信されていたら、もっとひどいことになっていたはずだ
コミュニティレベルのツールと慣行 が必要だ
商業的な規制やビルドワークフローの制限が生まれれば、大きな問題につながりうる
なぜ NPM だけが攻撃対象 になるのか気になっていた
Python や Java も人気は高いのに、最近は静かだ
バージョン範囲依存 の文化のおかげで感染が急速に拡散する
Java は特定バージョン固定が一般的なので、こうしたことはまれだ
そのため1つのパッケージが数十個の下位依存関係を引き込む
経験の浅い開発者も多いためセキュリティが弱い
他の言語エコシステムは検証してから更新するが、JS はすぐアップグレードする
インストール時にスクリプトを自由に実行でき、JVM や Python はそうではない
.npmrcにを追加すれば攻撃ベクトルを減らせる
関連文
無効化した場合に 依存関係が壊れる リスクはないのかも疑問だ
今回の攻撃で最も懸念されるのは 認証情報の窃取 だ
感染したパッケージをインストールしたなら、環境変数や
.npmrcトークンが流出した可能性がある直ちに トークンと API キーをローテーション すべきだ
定期的なローテーションは侵害後の対応ではなく、事前の予防策 である
認証情報は環境変数やファイルに保存せず、セキュリティキーや暗号化ファイル を使うべきだ
まるで 分散台帳に悪意あるトランザクション を埋め込むようなものだ
いまだに多くのサービスが平文保存をデフォルトにしているのが問題だ
こうした攻撃が繰り返されているのに、なぜ AI ベースの検知システム が機能しないのか疑問だ
Microsoft はあれほど AI を強調しているのに、肝心の GitHub セキュリティでは使われていないように見える
ファイアウォールが防いだあらゆる試行を攻撃と分類していた時代のように、意味が薄れている
内部的には SonaType IQ Server がそれを支えている
実際、curl プロジェクトが AI 生成のセキュリティレポートスパム に悩まされた事例もある
postinstall スクリプト を今も許可し続ける理由があるのだろうか
ユーザーに実行可否を尋ねるほうがよいのではと思う
CI サーバーでは 非対話式インストール が必要なので、現実的には難しいと思う
記事は非常に洞察に富んでいたが、最後が GitLab のセキュリティ機能の宣伝 で終わっていたのは残念だった