93分間、BitwardenのいわゆるCLIをインストールすることで、ラップトップがGitHubアカウントを乗っ取るためのローンチパッドと化した

4月22日、BitwardenのコマンドラインインターフェースのマLICIOUSバージョンが、公式パッケージ名 @bitwarden/[email protected] としてnpm上に現れました。93分間、npmを通じてCLIを取得した人は誰でも、正規ツールの代わりにバックドア付きの代替品を受け取ることになりました。

Bitwardenは侵害を検知し、パッケージを削除した上で、攻撃者がエンドユーザーの保管庫データにアクセスしたり、本番システムを侵害したりした証拠は見つからなかったと声明を発表しました。

セキュリティリサーチ企業のJFrogがこの悪意あるペイロードを分析したところ、Bitwardenの保管庫には特段の関心を示していないことがわかりました。標的としたのは、GitHubトークン、npmトークン、SSHキー、シェル履歴、AWS認証情報、GCP認証情報、Azure認証情報、GitHub Actionsシークレット、AIツールの設定ファイルでした。

これらは、チームがインフラをどのように構築・デプロイし、アクセスするかを管理する認証情報です。

Bitwardenは5万社以上の企業と1,000万人以上のユーザーにサービスを提供しており、同社の公式ドキュメントでは、CLIは環境変数を使用した認証を含む自動化ワークフローにおいて、保管庫へのアクセスと管理を行う「強力でフル機能を備えた」手段として紹介されています。

Bitwardenはnpmをレジストリに慣れたユーザー向けの最もシンプルかつ推奨するインストール方法として位置付けています。自動化での利用、開発者マシンへのインストール、そして公式npmからの配布という組み合わせにより、CLIは高価値なインフラシークレットが存在しやすい場所に正確に置かれることになります。

JFrogの分析によると、悪意あるパッケージはpreinstallフックとbwバイナリのエントリポイントの両方を、Bunランタイムを取得して難読化されたペイロードを起動するローダーに差し替えていました。この侵害はインストール時と実行時の両方で発動します。

組織はバックドア付きCLIを実行していても、保存されたパスワードに一切触れることなく、マルウェアがCIパイプライン、クラウドアカウント、デプロイ自動化を管理する認証情報を体系的に収集していた可能性があります。

セキュリティ企業のSocketは、この攻撃はBitwardenのCI/CDパイプラインにおける侵害されたGitHub Actionを悪用したと見ており、これはCheckmarxの研究者たちが追跡してきたパターンと一致しています。

Bitwardenは、このインシデントがより広範なCheckmarxサプライチェーンキャンペーンと関連していることを確認しました。

信頼のボトルネック

npmはまさにこのクラスのリスクに対処するために、信頼できる公開モデルを構築しました。

長期有効なnpm公開トークンをOIDCベースのCI/CD認証に置き換えることで、攻撃者がレジストリリリースを乗っ取るために使う最も一般的な経路の一つを排除し、npmは信頼できる公開を推奨し、重要な前進として位置付けています。

より難しい攻撃対象は、公開ステップを呼び出すワークフローやアクションなど、リリースロジック自体です。npmの公式ドキュメントでは、手動承認要件を伴うデプロイ環境、タグ保護ルール、ブランチ制限など、OIDCを超えた制御を推奨しています。

GitHubの環境設定により、組織はワークフローがデプロイする前にレビュアーの承認を必須にできます。SLSAフレームワークはさらに踏み込み、正しいリポジトリ、ブランチ、タグ、ワークフロー、ビルド設定など、来歴が期待されるパラメーターと一致するかを消費者が検証することを求めています。

Bitwardenのインシデントは、より難しい問題がワークフロー層に存在することを示しています。攻撃者がリリースワークフロー自体を悪用できれば、「公式」バッジは依然として悪意あるパッケージに付随します。

信頼できる公開は、信頼の負担をそれを呼び出すワークフローやアクションの整合性へと上位にシフトさせますが、この層は組織によってほとんど検証されないままになっています。

1つのトークンが多くのドアを開く

開発者やインフラチームにとって、侵害されたリリースワークフローはCIパイプライン、自動化インフラ、そしてそれらを管理する認証情報を露出させます。

JFrogの分析によると、マルウェアがGitHubトークンを入手すると、トークンの検証、書き込み可能なリポジトリの列挙、GitHub Actionsシークレットの一覧取得、ブランチの作成、ワークフローのコミット、実行待機、生成されたアーティファクトのダウンロード、そして痕跡の消去が可能になります。

トークンの取得により、1つの盗まれた認証情報を組織の自動化インフラ全体への持続的なアクセスに変換する自動チェーンが形成されます。

汚染された公式パッケージをインストールした開発者のノートPCは、ホストのローカル認証情報ストアから、GitHubアクセス、そのGitHubトークンがアクセスできるあらゆる場所へのブリッジとなります。

Bybitのインシデントは構造的に近い類似事例です。侵害された開発者ワークステーションが攻撃者に信頼された上流インターフェースを汚染させ、その後被害者の運用プロセスに到達しました。

違いは、Bybitが改ざんされたSafe WebのUIを通じたものであったのに対し、Bitwardenは改ざんされた公式npmパッケージを通じたものだった点です。

暗号資産、フィンテック、カストディ環境では、その経路は保管庫のエントリに一切触れることなく、認証情報ストアからリリース署名者、クラウドアクセス、デプロイシステムへと連鎖する可能性があります。

60日以内に、Checkmarxは侵害されたGitHub Actionsワークフローとおよびが、Cloud Security AllianceはTeamPCPキャンペーンがオープンソースプロジェクトとCI/CD自動化コンポーネントを積極的に侵害していると警告しました。

JFrogは、侵害されたTrivy GitHub ActionがLiteLLMの公開トークンを窃取し、悪意あるPyPIリリースを可能にした経緯を記録し、Axiosは2つの悪意あるnpmバージョンが侵害されたメンテナアカウントを通じて約3時間流通していたことを開示しました。

Sonatypeは2025年だけで45万4,600件以上の新たな悪意あるパッケージをカウントし、累計総数が120万件以上に達しました。Bitwardenは、リリースワークフローとパッケージレジストリが主要な攻撃対象であることを確認する一連のインシデントに加わりました。

正確な根本原因はまだ公開されておらず、BitwardenはCheckmarxキャンペーンとの関連を確認していますが、攻撃者がどのようにしてリリースパイプラインへのアクセスを取得したかについての詳細な説明は発表していません。

攻撃の結果

防御者にとって最も強力な結果は、このインシデントが「公式」の意味の再定義を加速させることです。

現在、信頼できる公開はリリースされた各パッケージに来歴データを付与し、レジストリにおける公開者のIDを確認します。SLSAは、検証者が来歴が期待されるリポジトリ、ブランチ、ワークフロー、ビルドパラメーターと一致するかを確認するための、より高い標準を明示的に文書化しています。

その標準がデフォルトの消費者行動になれば、「公式」は「正しいワークフローによって正しい制約の下で構築された」ことを意味し始め、アクションを侵害したものの来歴の制約をすべて満たせない攻撃者は、自動化された消費者が配布前に拒否するパッケージを生成することになります。

より現実的な近い将来の展開は逆方向に進みます。攻撃者は60日間で少なくとも4件のインシデントにわたり、リリースワークフロー、アクション依存関係、メンテナに隣接した認証情報が比較的低い摩擦で高い価値をもたらすことを実証しました。

各インシデントは、アクション侵害、CIアウトプットからのトークン窃取、メンテナアカウントの乗っ取り、信頼できる公開経路の悪用という公開プレイブックに別の記録された手法を追加します。

来歴検証がオプションのポリシー層ではなくデフォルトの消費者行動にならない限り、公式パッケージ名はそのリリースプロセスが正当化できる以上の信頼を集め続けるでしょう。

この記事はCryptoSlateに最初に掲載されました。