npm（Node Package Manager）は、JavaScript / TypeScriptのプログラム部品（パッケージやライブラリ）を管理するためのパッケージマネージャーです。
アプリケーションを作成する際、便利なパッケージをそのプロジェクトにインストールして、使用することができる環境として広く活用されています。
npmはパッケージインストール時の自動実行（preinstall や postinstall などのライフサイクルスクリプト）によるサプライチェーン攻撃を防ぐため、スクリプトのデフォルト自動実行を無効化するセキュリティ対策を導入しました。
しかし、今回の脅威では攻撃者がこのインストール時の制限を迂回する手法をいち早く採用しました。
具体的には、インストール時ではなく、アプリケーションがパッケージをインポートした後に特定のメソッド（関数）を呼び出したタイミングで悪意あるコードを動かす仕組みへとシフトしています。
本脅威（攻撃キャンペーン例：indexed-btree パッケージ）は、インストール時チェックだけに依存しているセキュリティ対策の盲点を突くものであり、開発・運用環境に直接影響を及ぼすリスクがあります。
特徴的な部分をみてみましょう。
- インストールフックから「実行時トリガー（スリーパーセル化）」へのシフト
- 解説
従来はパッケージインストール時（フック）に攻撃コードが動くケースが主流でした。しかし本件では、パッケージを読み込んだ（import）だけでは発動せず、ライブラリ自体のプロトタイプメソッド（例：btree.prototype.set）が呼び出されて初めて攻撃コードが動くよう組み込まれています。 - 影響
アプリケーションが該当メソッドを呼び出すまで攻撃コードは実行されず、「潜伏（スリーパーセル）」状態を維持します。静的解析ツールによる事前検知を難しくさせています。
- 解説
- 「クリーンな package.json」による偽りの安心感（盲点）の悪用
- 解説
npmの対策強化以降、開発者やレビュアーは package.json 内に不審なインストールのフック（フックスクリプト）が存在しないことを安全性の指標（信頼シグナル）としがちでした。 - 影響
今回の悪意あるパッケージは package.json が完全にクリーンであるため、目視や簡易チェックをすり抜けてプロジェクトへ導入されてしまうリスクが高まります。
- 解説
- 精巧な偽装工作（ソーシャルエンジニアリング）
- 解説
攻撃者は正規ライブラリ（sorted-btree など）を模倣するだけでなく、開発者の信頼を得るために偽のGitHubリポジトリやコミット履歴、顔写真付きのプロファイルを作成していました。 - 影響
公開リポジトリ側のソースコードには悪意のあるコードを含めない（レジストリ配信用パッケージのみに仕込む）などの手口により、見た目の検証だけでは正規パッケージと見分けがつかなくなっています。
- 解説
- 本番環境・実行時コンテキストでの悪意ある処理
- 解説
アプリケーション実行時にトリガーされるため、攻撃コードはアプリケーションと同一の権限やネットワークアクセス枠組みで動作します。 - 影響
ホスト情報の収集（フィンガープリント）、SlackやTelegramを経由した認証情報・秘密情報の窃取、さらにはテイクダウン（差押・遮断）が極めて困難なEthereumスマートコントラクトをC2チャネルとして悪用し、TelegramやSlack等も併用した高度なデータ送出（情報窃取）を行います。
- 解説
- 「パッケージ削除」だけでは不十分な被害復旧
- 解説
実行時トリガーによって一度コードが動いてしまうと、アプリケーションがアクセス可能なクレデンシャルや内部システムに悪意あるアクセスが及んでいる可能性があります。 - 影響
該当パッケージを削除するだけでは脅威は排除されず、クレデンシャルの再発行や環境全体の再構築（クリーンビルド）が必要になります。
- 解説
この脅威は、「インストール時のスクリプト実行を防ぐ」だけではエコシステムのセキュリティとして万全ではないことを示す典型例です。
攻撃者はセキュリティ対策に応じて即座に攻撃手法（ベクター）をずらし、アプリ実行時（Import・メソッド実行時）に悪意あるコードを動かす手法へ移行しています。
では、わたしたち防御側は同対策していくのが良いでしょうか。
考えられるのは次のような対策です。
- 「フックがない＝安全」という想定の払拭:
package.json にスクリプトがないことだけで安全と判断しない。 - 動的解析およびバイナリ解析の導入:
静的チェックやインストール時チェックに加え、実際の実行時挙動の監視（動的解析）や、配布パッケージの多層的なバイナリ解析を実施する。 - インシデント対応の再確認:
該当パッケージの混入が判明した場合は単なる削除にとどめず、資格情報の漏洩有無の確認・環境の再構築を含めた対処を行う。
「XXXXをやったからもう大丈夫」という一つで万全の対策となるようなものは期待できません。
新しい情報を常に取り入れながら、継続的に改善していきたいですね。
Dependency installation security measure already defeated on npm
https://www.reversinglabs.com/blog/npm-dependency-installation-security-measure-defeated
| この記事をシェア |
|
|---|
