npmパッケージ1,500件超、Trusted Publishingの検証不備で危険にさらされる

npmの信頼モデルに弱点があり、攻撃者が放棄されたGitHubリポジトリ名を取得することで、正規パッケージに更新版を公開できてしまう恐れがあることが、研究者の調査で判明しました。

npmのTrusted Publishing(信頼された公開)の仕組みに欠陥があり、攻撃者が放棄されたGitHubリポジトリ名を再取得することで、正規のソフトウェアパッケージを乗っ取れる可能性があります。これにより、数百万件に及ぶパッケージのダウンロードがサプライチェーン攻撃にさらされる恐れがあります。

Boom Securityの研究者らは、セキュリティスキャナー、認証ツール、暗号関連パッケージなどを含む、1500件を超えるnpmパッケージが脆弱である可能性を確認しました。

「SlugFest」と名付けられたこの脆弱性は、npmが信頼する公開元を検証する際に、リポジトリ固有の数値ID(不変の識別子)ではなく、人間が読めるGitHubリポジトリ名に依存していたことに起因します。攻撃者は、元の所有者が放棄したリポジトリ名を取得するだけで、そのパッケージの公開権限に対する信頼を引き継げる可能性がありました。

この問題はすでに修正されていると、Boom Securityの研究者Golan Myers氏はCSOに語りました。「npmチームは、10月2日に修正を適用したことを確認しました。未検証のTrusted Publishing設定に48時間の有効期限を設ける内容です」と同氏は述べています。

Myers氏によると、Boomは実環境での悪用を確認していませんが、自社の管理下にあるテスト環境では、この欠陥を利用して既存のnpmパッケージの新バージョンを公開することに成功したといいます。今回の修正により、未検証の設定に伴うリスクは解消されます。ただし、メンテナーは既存の信頼関係を自ら見直す必要があると、Boomは火曜日の公開に先立ってCSOに共有したブログ記事で指摘しています。

再取得したリポジトリ名でパッケージの公開が可能に

npmのTrusted Publishingは、パッケージのメンテナーがOpenID Connect(OIDC)を使った自動ワークフローでリリースを公開できる仕組みで、長期間有効な公開用認証情報を使わずに済みます。しかしBoomは、npmの信頼設定が、不変のリポジトリIDではなく、GitHubリポジトリの「所有者/リポジトリ名」に依存していたことを突き止めました。

リポジトリの名前が変更されたり、移管されたり、削除されたりすると、元の名前を別のユーザーが取得できるようになる場合があります。攻撃者はそのアドレスにリポジトリを作成し、期待されるファイル名でGitHub Actionsのワークフローを設定できます。npmはリポジトリ名とワークフローのファイル名しか確認しておらず、恒久的なリポジトリIDを検証していませんでした。そのため攻撃者は、自分が所有していないパッケージの有効な公開用認証情報を入手できる可能性がありました。

研究者らは、自らが管理するパッケージを標的にこの攻撃を実証しました。別の組織に属するGitHubリポジトリから、新バージョンを公開したのです。この攻撃では、正規のメンテナーのGitHubアカウントやnpmアカウントを侵害したり、認証情報を盗んだりする必要はありませんでした。

レジストリ全体を対象としたスキャンでは、1500件を超える脆弱なパッケージが見つかりました。これらの累計ダウンロード数は1,000万件を超え、月間ダウンロード数は100万件以上にのぼります。Boomによると、うち1パッケージだけで月間20万件を超えていました。

AIエージェントがサプライチェーンのリスクを増幅

Boomは、AIコーディングエージェントが人間の関与をほとんど介さずにソフトウェアパッケージを選んでインストールするケースが増えているため、悪意ある依存関係の拡散を加速させかねないと主張しています。

数十の組織を対象とした調査では、エージェントがインストールするパッケージは、1エンドポイントあたり月に約70件でした。開発者のマシンでは約350件にまで増えています。この数字は直接のインストールのみを対象としており、推移的依存関係は含まれていません。

開発者やCIシステムが侵害されたパッケージをインストールすると、悪意あるリリースはインストールフックを通じて、攻撃者が仕込んだコードを実行する恐れがあります。AIエージェントは、開発者が明示的に選ぶことなく、そのような依存関係を取り込んでしまう可能性があります。「乗っ取られたパッケージは、もはや開発者を探す必要がありません。エージェントに選ばれさえすればいいのです」とMyers氏は述べています。

GitHubは、未検証のTrusted Publishing設定を48時間後に失効させることで、この問題に対処しました。これに加えてnpmは、すでにあったpull_request_targetイベントに対する制限に続き、GitHub Actionsのissue_commentイベント経由で発行されたTrusted Publishingトークンも拒否するようにして、保護を強化しています。

Boomはさらに、メンテナーに対し、Trusted Publishingの設定を監査し、信頼するリポジトリ名がそれぞれ自分の管理下にあるリポジトリを指していることを確認するよう推奨しています。必要に応じて、バインディングの削除と再作成も求めています。また研究者らは、セキュリティチームに対しても、環境全体で使われているソフトウェア依存関係とツールを監査し、開発者やAIエージェントがインストールできるものを制御するよう助言しています。

Shwetaは2017年からエンタープライズ技術について執筆しており、最近はCSO onlineでサイバーセキュリティを担当しています。ランサムウェアからゼロトラストアーキテクチャまで、複雑なトピックを専門家にも一般の読者にもわかりやすく解説しています。インド・アジアンジャーナリズム大学院でジャーナリズムの大学院修了資格を取得。サイバー脅威の解読に追われていないときは、小説を読んだり、映画を観たり、新しいレシピを試したりするのが楽しみです。

翻訳元: https://www.csoonline.com/article/4234229/over-1500-npm-packages-exposed-by-trusted-publishing-validation-flaw.html

本記事は csoonline.com の記事を翻訳・要約したものです。