ダウンロード数の水増し: サプライチェーン攻撃を狙う新たな npm 欺瞞手法

攻撃者がソフトウェアサプライチェーン攻撃の一環として自動化されたボットトラフィックを悪用し、ダウンロードカウンターを人為的に水増しし、悪意のあるペイロードを正規のものとして隠蔽する方法をご覧ください。

ダウンロード数指標

Tenableは、攻撃者が開発者のワークステーションやCI/CDビルドサーバからアクセストークンやシークレットを盗むのを目撃した最近のソフトウェアサプライチェーン攻撃を受けて、パブリックレジストリにアップロードされたnpmパッケージの積極的なモニタリングと分析を開始しました。 当初、パッケージの関連性を判断する主な指標として、ダウンロード数を用いていました。

モニタリングの過程で、私たちは繰り返し起こる異常を確認しました。真新しいパッケージは、アップロード後数時間で異常に高いダウンロード数を示しました。さらに調べてみると、それらのパッケージにも多くのバージョンがあることがわかりました。

コンテンツが頻繁に更新されるパッケージでは、ダウンロード数が異常に多くなる傾向が確認されました。これは通常、同一パッケージの新バージョンが多数アップロードされることによるものです。

私たちは、攻撃者が700以上のバージョンをアップロードした後、3日間で5万以上のダウンロードに達した悪意のある「ambar-src」パッケージの分析において、この手法が意図的に出回っていることを初めて確認しました。私たちはこのテクニックを "ダウンロード・ポンピング "と名付けました。

開発者やセキュリティツールは、パッケージの正当性を評価する指標の一つとして、ダウンロード数を頻繁に使用します。 パッケージが正規のものかどうかを判断する簡単な方法はないため、この人工的なインフレは脅威を効果的に偽装します。

分析

ambar-src」キャンペーンでは、実際の悪意のあるペイロードを導入する前に、攻撃者は何百もの無害なバージョンのパッケージを組織的に公開していました。

npmはこれらの更新とのやりとりをトラフィックとして登録するため、この反復的なバージョン公開プロセスは2つの目標を達成しました。

• パッケージのリリース履歴を大量に入力し、濃密な変更履歴を作成することで、プロジェクトを評価する開発者たちに、プロジェクトが活発にメンテナンスされ、歴史的に正当なものであるかのように見せました。
• 新しいバージョンが公開されるたびに、リポジトリミラーや分析ボットのような自動化システムが自動的にダウンロードしました。 攻撃者は組織的に何百ものバージョンをアップロードしたため、人為的に自動トラフィックの大波を発生させ、パッケージのダウンロード数をわずか3日間で5万ダウンロード以上に膨れ上がらせました。

Tenableの初期分析によると、npmパブリックレジストリにアップロードされた各バージョンは、通常、自動化されたシステムから100から150のダウンロードを受けています。 私たちは、概念実証（POC）を実行し、ダウンロード数を分析することで、その事実を検証しました。

ポンピングPoCのダウンロード

これらのメカニズムを検証するため、ダウンロードポンピング動作をレプリケーションするPOCを実施しました。私たちはテストパッケージを作成し、大量の新バージョンをnpmレジストリに体系的に公開しました。 

npmチームがブログで述べているように、彼らのダウンロード統計は設計上素朴なものであり、自動化されたボット・トラフィックのフィルタリングにはあまり力を入れていません。 

そのため、さまざまなリポジトリミラー、分析ボット、自動化されたセキュリティスキャナーなどが、私たちがアップロードした新バージョンを即座に引き抜きました。 これにより、攻撃者は、自動化されたパブリッシングによって、有機的なユーザーインタラクションをまったく必要とせずに、ベースラインのダウンロードを予測可能な形で生成できることが検証されました。

POCでは、パッケージのプロパティの違いが自動ダウンロード量にどのような影響を与えるかを確かめたかったのです。 私たちは、ポストインストールスクリプトのあるパッケージはセキュリティスキャナーの関心を高めるという前提で作業していました。

ポストインストールスクリプトは、攻撃者がこれらのライフサイクルフックを頻繁に使用し、パッケージがインストールされた瞬間に悪意のあるペイロードを自動的に実行するため、防御者にとって重要なポイントです。 これは一般的なマルウェアのデプロイメント手法であるため、自動化されたセキュリティスキャナーは、これらのスクリプトが設定されているパッケージを優先的にダウンロードし、検査します。

セキュリティスキャナーは、npmパッケージにポストインストールスクリプトが設定されているかどうかを判断するために、パッケージそのものをダウンロードする必要がないことに注意することが重要です。このデータは、パブリックレジストリのパッケージメタデータで利用可能だからです。

これらの理由から、インストールスクリプトが設定されたパッケージは、悪意のあるコードを含んでいる可能性が高いため、セキュリティスキャナがダウンロードする可能性が高いと考えました。 npmに3つの異なるテストパッケージをデプロイし、我々の仮定をテストしたところ、以下のような結果が得られました。

• バージョンアップのみ： 135.55 downloads per version
  これがベースラインのテストパッケージです。 新バージョンを公開する際にコードを追加したり削除したりすることはなかったし、パッケージを面白く見せるための他の試みもしなかったのです。そのたびにバージョン番号を上げただけです。
   
• 静的ポストインストールスクリプト： 141.91ダウンロード/バージョン
  これは2つ目のテストパッケージで、ポストインストールスクリプトを設定した最初のものでしたが、新しいバージョンを公開する際にスクリプトを変更しませんでした。
   
• 動的ポストインストールスクリプト： 158.16ダウンロード/バージョン
  この3つ目のテストパッケージでは、バージョンを上げるたびにポストインストールスクリプトを変更しました。 これは、セキュリティスキャナーが、インストール後のスクリプトが変更されたパッケージにより興味を持つだろうと考えたからです。
   

Tenableの最初のPOCソフトウェアパッケージが、新バージョンの公開開始時にダウンロード数が急増したことを示すグラフ。 

このデータは、因果関係を端的に示しています。自動化されたインフラとセキュリティ・スキャナーは、興味深い、あるいは活発に変化する挙動を示すパッケージに対して、より多くのダウンロード・トラフィックを自然に生成します。

その他のパッケージ・マネージャー

我々のリサーチエンジニアは特にnpmエコシステムに焦点を当てましたが、このテクニックの背後にある基本的な仕組みはnpm特有のものではありません。PyPI、RubyGems、NuGetのような他のパッケージレジストリは、ミラー、セキュリティスキャナー、解析ボットといった同様の自動化されたインフラで運営されており、新しいバージョンが公開されると、それをプルします。具体的なダウンロードの増幅と信頼の指標はエコシステムによって異なるかもしれませんが、核となる原則は変わりません。つまり、自動化されたシステムが新しい出版物に反応する場合、悪用の可能性があります。

ダウンロード・ポンプの実例

すでに述べたように、私たちは「ambar-src」パッケージの分析で、この手法が出回っていることを初めて確認しました。

もう少し詳しく見てみましょう。

攻撃者は、MathUtils、StringUtils、Time関数など、正当な目的で使用できるユーティリティコードを含むnpmパッケージを作成しました。攻撃者はその後、わずか2時間の間に428の正規バージョンのパッケージを組織的にアップロードしました。攻撃者は最初の信用を得るためにこのようなことを行い、開発者を誘い込んで自分たちのコードを使わせようとしました。

その3日後、攻撃者は悪質なコードを含む新しいバージョンをアップロードしました。 この時点で、攻撃者のパッケージはすでに3万ダウンロードを超えていました。

攻撃者は、悪意のあるバージョンと正規のバージョンを合わせて724バージョンをアップロードしました。 この結果、人為的に自動トラフィックの波が引き起こされ、合計で約5万ダウンロードが記録されました。

この反復的なバージョン公開プロセスにより、パッケージのダウンロード数が増加し、リリースの履歴が濃密になり、マルウェアがデプロイされる前に、プロジェクトが歴史的に正当であるかのように見せることに成功しました。

npmのダウンロード操作に関する過去のリサーチ

npmのダウンロード・メトリクスの操作は、新しい発見ではありません。2021年のリサーチ・ブログで、独立系開発者のAndy Richardson氏は、npmレジストリのダウンロード追跡がいかに悪用されやすいかを、悪質な行為者がパッケージのtarball URLにHTTPリクエストを送り、ダウンロードを偽装できることを実証することで示しました。 

リサーチエンジニアは自動化ツールを使い、全く使われていないパッケージを1週間で100万件近くなりすましダウンロードさせることに成功しました。

Tenableは、この手法が2026年にも有効であることを検証しました。 Tenableは、パッケージのtarボールのURLに直接HTTPリクエストを送信することで、標準的なオフィスのラップトップとインターネット接続のみを使用して、約1時間でテストパッケージのメトリックを17,000ダウンロードに膨らませることに成功しました。

しかし、私たちが発見したこの新しいバージョン・フラッド方式には、2つの明確な利点があります。

• 第一に、攻撃者はHTTPリクエストごとに1回ダウンロードするだけでなく、アップロードしたバージョンごとに100から150の自動ダウンロードをリポジトリミラーから得ることができます。
• 第二に、このようなアップデートを体系的に公開することで、リリース履歴が蓄積され、パッケージが活発に保守され、歴史的に正当なものであるかのように見える、詳細なバージョンログが作成されます。

サプライチェーン攻撃の軽減

組織は、パッケージが正当なものかどうかを判断するために、ダウンロード数やバージョン履歴に依存すべきではありません。私たちが実証したように、攻撃者は自動化されたシステムを使って簡単にこれらのメトリクスを偽造することができ、偽の信頼感を作り出すことができます。

その代わりに、組織は、バージョンの固定や最小パッケージ年齢の制限の実施など、一般的な業界のベストプラクティスを採用すべきです。 

これらのベストプラクティスは効果的です。セキュリティベンダーとオープンソースコミュニティは、これらのレジストリを積極的にモニタリングしており、通常、悪意のあるパッケージをかなり迅速に、長くても数日以内に検出するからでです。 

新しいパッケージや既存のパッケージの新バージョンを環境に入れる前に、3〜4日の短い待機期間を強制することで、コミュニティが公開レジストリでこれらの脅威を特定する時間を確保することができます。 検出されれば、公開登録から削除され、リスクはなくなります。

npmがエコシステムのセキュリティ向上に積極的に取り組んでいることは注目に値します。最近の取り組みとしては、npm CLIで直接パッケージエイジチェックのサポートを追加したり、アカウント乗っ取りのリスクを減らすためにパッケージメンテナの認証メカニズムを強化したりしました。 

これらは正しい方向への有意義なステップではありますが、現実には、悪意のあるコードがパブリック・レジストリに到達するのを完全に防止できる対策はひとつもありません。サプライチェーンの攻撃者は今後も進化し続けるため、組織はエコシステムだけに頼るのではなく、独自の防御策を重ねるべきです。

例えば、マルウェアの残存を防ぐために、1回使用したらすぐに破棄される一時的なCI/CDランナーをデプロイメントすることで、CI/CDビルドサーバの保護を強化することができます。 このような一時的なランナーを永続ストレージなしで運用すると、攻撃者がペイロードを保存したり、異なるビルドジョブ間で持続性を確立したりすることが難しくなります。

さらに、組織は最小権限でのネットワークアクセスを強制すべきです。 アウトバウンドトラフィックを制限することで、ビルドサーバー上で実行されている悪意のあるペイロードがオープンインターネットに到達しにくくなり、"msinit.exe "のようなセカンドステージのマルウェアペイロードをダウンロードしにくくなります。

なぜこれが問題なのか

現在、開発者はオープンソースのサプライチェーン技術によってハッキングされています。 開発者やセキュリティ・ツールが頼りにしているメトリクス（ダウンロード数、バージョン履歴、メンテナンス活動）は、表面的な指標であり、攻撃者が最小限の労力で操作できることを、私たちが実証したとおりです。 しかし、問題は偽のシグナルよりも深いのです。

信頼できるメンテナが背後にいる正当な実績のあるパッケージであっても、その信頼は一夜にして損なわれる可能性があります。 最近、アカウントの乗っ取り、ソーシャルエンジニアリングキャンペーン、そして確立されたメンテナを標的にしたクレデンシャル盗難の波が、正当なパッケージであっても、パッケージの履歴が現在の安全性を保証するものではないことを示しています。信頼できる名前で発行された新しいバージョンは、悪意のあるペイロードを運ぶ可能性があり、パッケージマネージャにはそれを捕捉するメカニズムが組み込まれていません。

実際には、新しいパッケージが悪意のあるものかどうかを決定する決定論的な方法はありません。 したがって、インストールして使用する各パッケージは、悪意のある可能性があるものとして扱わなければなりません。セキュリティベンダーやオープンソースコミュニティは、パッケージが公開されると、積極的にスキャンし、分析します。

新パッケージや新バージョンに最低年齢を課すことが効果的なコントローラーとなるのは、まさにこのためです。数日間という短い待機期間は、セキュリティ・コミュニティに、脅威があなたの環境に到達する前に、一般レジストリから脅威を検出し、フラグを立て、削除する時間を与えます。 パッケージが公開された瞬間にそれを消費する組織は、完全に回避可能なリスクを受け入れています。

ダウンロード・ポンプは結局のところ、もっと大きな目的のための最初の入り口ベクトルにすぎないのです。 これらのテクニックを使用する攻撃者は、一般的に2つの結果のいずれかを目指しています。

まず、ビルドサーバーとCI/CDパイプラインを危険にさらすことを目的としています。 これらのシステムに悪意のある依存関係を仕込むことに成功すると、攻撃者はインフラ全体の制御権を握り、本番環境全体が侵害される可能性があります。

第二に、さらに悪いことに、非常に人気のあるパッケージの開発者を危険にさらすことを目的としています。 信頼できるメンテナの環境を乗っ取ることで、攻撃者は悪意のあるコードを注入することができ、それを何千もの下流の組織が自動的に引き込むことで、より広範なソフトウェアのサプライチェーンに大規模な連鎖効果をもたらします。

Tenableが提供するサプライチェーン攻撃対策

サプライチェーン攻撃を防御するためには、あなたの環境で実行されているコードを正確に知る必要があります。 Tenable One サイバーエクスポージャー管理プラットフォームとTenable Nessusは、組織全体で使用されているnpmパッケージの完全な資産インベントリを構築するのに役立ちます。

以下の Nessus プラグインを使用して、環境内の npm モジュールのインベントリを構築します。

• 200172 - Node.js Modules Installed (Windows)
• 179440 - Node.js Modules Installed (macOS)
• 178772 - Node.js Modules Installed (Linux)

Tenableがお客様の環境を継続的に分析するため、お客様はシステムに何がインストールされているかを直接把握することができます。 この可視性により、新たな脅威が発見されるとすぐに、侵害されたパッケージの場所を特定し、削除することができます。

完全なインベントリーを構築するだけでなく、企業は、ライブの脅威に対して積極的に環境をモニタリングする必要があります。CNAPPであるTenable One Cloud Exposure は、クラウド環境を継続的にモニタリングすることで、このようなサプライチェーンへの攻撃をリアルタイムでプロアクティブに検出します。

これらのツールは、Tenable One エクスポージャー管理プラットフォームの一部として連携することで、環境全体にわたるサプライチェーン攻撃をプロアクティブに検出し、攻撃者が本番システムを完全に侵害する前に、セキュリティチームが悪意のある活動を即座に特定して無力化できるようにします。