「CanisterWorm」と呼ばれる高度に自動化されたnpmサプライチェーン攻撃キャンペーンでは、脅威アクターがnpmアクセストークンを盗み、信頼されたパブリッシャーアカウントを大規模に武装化しています。
「TeamPCP」として追跡されているグループは、@emilgroupや@teale.ioを含む信頼されたネームスペースを侵害し、新しいSDKバージョンをプッシュしており、これらのバージョンは静かに永続的なバックドアをデプロイしてから、被害者が保守するすべてのパッケージ全体に自己拡散します。
古典的なタイポスクワッティングとは異なり、CanisterWormは本物の既に信頼されているパッケージから開始されます。攻撃者が有効なnpmパブリッシングトークンまたは同等のCI/CDアクセスを取得すると、正当なパッケージコンテンツを、バージョン履歴では無害に見えるが追加のpostinstallフックを含む悪意あるビルドで置き換えます。
このフックはnpm installの間に自動的に実行されるため、開発者は追加の実行ステップなしに依存関係を解決するだけで感染します。
postinstallロジックはPythonバックドアをドロップして起動し、Linux上でpgmonという名前のユーザーレベルのsystemdサービスを介して永続性をセットアップします。これは~/.config/systemd/user/pgmon.serviceにインストールされています。
そのサービスは自動的に再起動するように設定されており、~/.local/share/pgmon/の隠しディレクトリから実行され、元のnode_modulesディレクトリが削除された後でも攻撃者に長期的なアクセスを提供します。
分散型ICP C2とトークン盗難
コマンドアンドコントロール用に、バックドアはInternet Computer Protocol（ICP）キャニスターエンドポイント（特にtdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io）を繰り返しポーリングします。これはデッドドロップチャネルとして機能します。
JFrogの脅威インテリジェンスチームは爆発範囲が複数の組織にわたるSDKとツーリングの広範なセットにまで及んでいると報告しています。
キャニスターはマルウェアを直接配信しませんが、代わりに第2段階バイナリの平文URLを返すため、オペレーターは感染したホストに触れることなくペイロードをローテーションしたり、キャンペーンを一時的に無効化したりできます。
取得されたペイロードは/tmp/pglogに保存されます。実行状態はポーリングと実行フローを管理するために/tmp/.pg_stateで追跡されます。
並行して、JavaScriptローダーは複数の場所からnpm認証情報を積極的に収集します。これはプロジェクト内のローカル.npmrcファイル、ユーザーの~/.npmrc、および/etc/npmrcを解析して_authTokenエントリを探し、NPM_TOKENやNPM_TOKENSなどの環境変数も検査します。
マルウェアはさらにnpm config get //registry.npmjs.org/:_authTokenを実行して、npmの独自設定を通じて設定されたトークンを取得し、公開レベルのシークレットを抽出する可能性を最大化します。
トークンが収集されると、CanisterWormは自己伝播型サプライチェーンワームに変わります。deploy.jsスクリプトは盗まれた認証情報を使用してnpmレジストリ検索APIに照会し、侵害されたユーザーが公開できるすべてのパッケージを列挙します。
各パッケージについて、パッチバージョンを自動的にバンプし、悪意あるpostinstallペイロードを注入し、npm publish –access public –tagで最新版としてnpmに再プッシュすることで、パブリッシャーのポートフォリア全体を数秒で実質的にバックドア化します。
新たに特定された侵害されたバージョンには、@emilgroup/discount-sdk 1.5.1、@emilgroup/document-uploader 0.0.10、@emilgroup/docxtemplater-util 1.1.2、@emilgroup/numbergenerator-sdk-node 1.3.1、@emilgroup/partner-portal-sdk 1.1.1、@emilgroup/setting-sdk 0.2.1、@emilgroup/task-sdk 1.0.2、および@emilgroup/task-sdk-node 1.0.2が含まれます。これらは最初の公開開示でカバーされていません。
緩和策
リストされているいずれかのバージョンを使用している組織は、侵害を想定して、ワームの拡散能力を迅速に封じ込めることをお勧めします。
まず、影響を受ける可能性のあるホスト上のすべてのnmパブリッシングトークンとCI/CDシークレットをローテーションする必要があります。新しい認証情報は必要最小限のスコープに限定し、有効期限を制限してください。
チームはnpmログとパッケージ履歴を監査して、ネームスペースからの不正な公開を検出し、ダウンストリーム利用者が誤ってインストールできないように悪意あるパッチバージョンを非公開にする必要があります。
Linuxでは、ディフェンダーはpgmon systemdユーザーサービスを停止してオフにし、関連するユニットファイルとデータディレクトリ（~/.config/systemd/user/pgmon.service、~/.local/share/pgmon/、/tmp/pglog、/tmp/.pg_stateを含む）を削除して、永続性層を削除する必要があります。
その後、プロジェクトはnode_modulesを削除し、npmキャッシュをクリーニングし、影響を受けたSDKを攻撃ウィンドウより前の既知の良いバージョンに明示的に固定することで、依存関係をパージして再インストールする必要があります。
今後の同様の攻撃への露出を減らすために、セキュリティチームはnpm config set ignore-scripts trueでライフサイクルスクリプトをグローバルに無効化し、@lavamoat/allow-scriptsなどのツーリングを使用して選択的に再度有効化することを検討できます。
ユーザーsystemdディレクトリへの未承認の書き込みをブロックするようにシステムポリシーを厳格化し、JFrog Curlのようなキュレートされた依存関係ワークフローを導入することで、個々のトークンをエコシステム全体のサプライチェーン侵害に変える攻撃者の負担をさらに増やします。
翻訳元: https://gbhackers.com/canisterworm-hijacks-npm/
