週間ダウンロード数2.7万のnpmパッケージがOpenAIトークンを密かに窃取

codexui-androidという悪意あるnpmパッケージが、インストールした開発者からOpenAIの認証トークンをひそかに窃取していた。期間は不明だが、週間ダウンロード数は約27,000件に達しており、このパッケージはOpenAI Codexモデルの正規のユーザーインターフェースを装っていた。その見慣れた外観の裏では、密かに認証情報を収集する操作が行われており、セキュリティ研究者たちは、これをOpenAIトークンを大規模に狙った典型的なnpmサプライチェーン攻撃に分類している。

今回の発見は、パッケージレジストリが本質的に安全ではなく、人気だけでは信頼性の指標にならないことを、改めて痛感させるものだ。

codexui-androidはいかに正規に見せかけてトークン窃取を隠蔽したか

この攻撃は単純だが効果的な欺瞞に依存していた。それは、開発者が実際に使いたくなるツールを構築し、そこにバックグラウンドで密かに動作する悪意のロジックを追加するというものだ。codexui-androidパッケージはOpenAIのCodexに対する機能的なインターフェースを提供していたため、開発者はそれをインストールし、テストし、プロジェクトに組み込んだまま、パッケージがネットワーク層で何をしているかを疑うことはほとんどなかった。

この手法はトロイの木馬化されたパッケージ攻撃として知られている。悪意のあるコードは、一見便利なツールの中に埋め込まれ、明らかに機能不全または粗末に作られたパッケージが招くであろう自然な警戒心を回避していた。このパッケージはOpenAIのリフレッシュトークン（アプリケーションがユーザーの再ログインなしに新しいアクセストークンを要求できる長寿命の認証情報）を外部に持ち出していた。

codexui-androidという名前も、正規性を匂わせる命名規則に従っていた。OpenAIのCodex製品のブランドエクイティを借用しつつ、特定のプラットフォーム向けを示す接尾辞を付加することで、目的に特化したモバイル関連のツールであるかのように見せかけていた。Codex関連のツールをnpmで検索する開発者にとって、それを疑う明白な理由はなかったのだ。

盗まれたOpenAIリフレッシュトークンで攻撃者が実際にできること

リフレッシュトークンは単なるパスワードではない。多くの認証システムにおいて、実質的にマスターキーに等しい。攻撃者が有効なリフレッシュトークンを入手すると、新しいアクセストークンを繰り返し生成し、元のセッションが終了したりパスワードが変更された後でも、アカウントへの永続的なアクセスを維持できる。

OpenAIアカウントの場合、このアクセスは、有料APIクレジットの不正使用、保存されたプロンプトや微調整されたモデルデータへのアクセス、API経由で渡されたプロプライエタリコードの漏洩、さらに組織的なコンテキストでは、同じアカウントに紐づくチームリソースへの水平アクセスなどにつながる可能性がある。

リスクは開発環境で急速に拡大する。エンジニアはしばしば高い権限を持つAPIキーやトークンを扱う。CI/CDパイプラインや共有開発環境でたった一つのリフレッシュトークンが侵害されれば、攻撃者に検出が難しく完全な修復が困難な持続的な足場を与えかねない。この連鎖的な影響は、Dropbox Signの情報漏洩で起きたことを彷彿とさせる。そこでは、収集された認証情報が最初の侵害地点をはるかに超えて相互接続されたシステムへの経路を開いた。

npmエコシステムがサプライチェーン攻撃を拡大しやすくする理由

npmレジストリには200万以上のパッケージが存在する。新規パッケージの公開に必要な本人確認は最小限であり、このレジストリのオープン性こそが、グローバルな開発コミュニティにとって非常に有用な理由である。しかし、それは同時にサプライチェーン攻撃者の格好の標的にもなっている。

codexui-androidの事例は、オープンソース開発を支える信頼モデルを攻撃者がどのように悪用するかを示している。開発者は一般に、ダウンロード数が多いパッケージはコミュニティによるある程度の精査を経ているはずだと考える。その前提はますます危険になっている。ダウンロード数は人工的に水増し可能であり、実際の使用実績はセキュリティレビューの代わりにはならない。

npmサプライチェーン攻撃という大きな問題自体は新しいものではないが、AIツールを標的にすることは進化を示している。開発者が大規模言語モデルのAPIを本番システムに統合するにつれ、その統合を認証するトークンは高価値の標的となる。攻撃者は明らかにこの変化を認識している。AI開発者ツールを模倣したパッケージは新たな脅威カテゴリーであり、セキュリティコミュニティは依然として大規模な対策に取り組んでいる段階だ。

開発者のための多層防御：資格情報の分離、ネットワークセグメンテーション、その先

codexui-androidのインシデントは、この種の攻撃への露出を減らすためのいくつかの具体的な対策を示している。

資格情報の分離は最も即効性のある緩和策だ。APIトークンとリフレッシュトークンは可能な限りスコープを狭くし、環境変数や設定ファイルではなくシークレットマネージャーに保存し、定期的にローテーションすべきだ。トークンが盗まれても、スコープが制限されていれば被害も限定される。

依存関係の監査は、あらゆる開発ワークフローの標準的な一部であるべきだ。npm auditやサードパーティのソフトウェア構成分析プラットフォームなどのツールは、異常な動作や既知の脆弱性を持つパッケージをフラグ付けできる。依存関係のバージョンをロックファイルで固定し、アップデートを受け入れる前に変更をレビューすることも、悪意あるバージョンのプッシュへの露出を減らす。

ネットワークエグレス監視は、監査ツールが見逃す情報流出の試みを捉えられる。開発環境やCI/CDパイプラインが予期しない外部接続に対してアラートを発するよう設定されていれば、盗んだトークンを持ち帰ろうとするパッケージを検出可能になる。

最小権限の原則はあらゆるレベルに適用される。開発マシンは本番レベルのアクセス権を付与する資格情報を使って実行すべきではない。CI/CDパイプラインは、長期保存されたシークレットではなく、実行時に生成される短命のトークンを使用すべきだ。

最後に、自身がインストールしたパッケージの中で認証フローに関わるものを今すぐ見直すことは価値のある作業だ。codexui-androidのインシデントは孤立した事例である可能性は低い。自身のnode_modulesの中身を監査し、APIトークンが持つ権限を確認し、認証情報の保存に関わるあらゆるパッケージをより高い精査で扱うようにしよう。

サプライチェーン攻撃が成功するのは、信頼を大規模に悪用するからだ。そのセキュリティ姿勢を、最も重要な認証情報から始めて依存関係ごとに再構築することが、今日の個々の開発者にとって最も現実的な対応である。