Snykのセキュリティ研究者、Cursor.comを狙った悪性NPMパッケージを公開

 (sourcecodered.com)
1 ポイント 投稿者 GN⁺ 2025-01-14 | 1件のコメント | WhatsAppで共有
  • npmに公開された複数のパッケージに、Cursor.comを狙ったとみられるインストールスクリプトが含まれており、インストール時にシステム情報を外部Webサービスへ送信する
  • 公開者はnpmユーザー sn4k-s3c で、cursor-retreival、cursor-always-local、cursor-shadow-workspace のようにCursorの内部パッケージを想起させる名前を使っていた
  • パッケージが取得する env の出力には、AWSキー、npmトークン、GitHub認証情報などの機密性の高い環境変数が含まれる可能性があり、被害範囲が広がり得る
  • OpenSSF package analysis scannerがパッケージを悪性と判定し、OSVは MAL-2025-27、MAL-2025-28、MAL-2025-29 の3件のアドバイザリを作成した
  • npmメタデータでは、Snyk Security Labsの snyk.ioメールアドレス が公開者として表示されており、その後Snykの研究者がパッケージを削除し、Snykがブログで対応した

Cursorを狙ったとみられるnpmパッケージ

  • SourceCodeRedによる悪性パッケージ検出の過程で、npmに公開された複数のパッケージが確認された
  • パッケージ名はCursor関連の内部パッケージを想起させる形式だった
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • 公開者はnpmユーザー sn4k-s3c と表示されている
  • パッケージ一覧は https://www.npmjs.com/~sn4k-s3c で確認できると案内されている

インストール時に実行される動作

  • パッケージをインストールすると、システムデータを収集して攻撃者が制御するWebサービスへ送信する
  • スクリーンショット上では、パッケージは env コマンドの出力を取得している
  • env の出力には、システム設定に加えて機密性の高い環境変数が含まれる可能性がある
    • AWSキー
    • npmトークン
    • GitHub認証情報
    • その他の機密環境変数
  • 結果として、インストールするだけでローカル環境情報が外部に流出する可能性がある

依存関係混同の可能性と検出結果

  • この種のパッケージは、特定の企業を狙った**依存関係混同（dependency confusion）**攻撃でよく見られる
  • Cursor.comにバグバウンティプログラムがあるかどうかや、具体的な背景は確認されていない
  • SourceCodeRedは、Cursorに cursor-always-local、cursor-retrieval、cursor-shadow-workspace のような非公開npmパッケージが存在する可能性を疑っている
  • 攻撃者は、Cursorの従業員が誤って公開パッケージをインストールし、データを送信することを期待していた可能性がある
  • OpenSSF package analysis scannerがこれらのパッケージを悪性と判定し、OSVは3件のマルウェアアドバイザリを作成した

公開者メタデータ

  • npmパッケージのメタデータ上、公開者はSnyk Security Labsチームの snyk.ioメールアドレス を使用している
  • この公開者メールのメタデータは偽装できない部分だとされている
  • author フィールドはSnykの従業員を具体的に挙げている
  • author フィールドは偽装可能だが、公開者が検証済みのSnykメールアドレスであるため、実際にSnykから出たものだとする推定が示されている

ユーザー対応とその後の更新

  • SourceCodeRedはnpmに通知したが、当時これらのパッケージはまだ悪性として表示されていなかったという
  • 多くのソフトウェアサプライチェーンセキュリティツールは、パッケージが悪性であることを把握して初めてブロックできる
  • npmパッケージをむやみにインストールしないことが推奨される
  • これらのパッケージには package.json と index.js または main.js の2ファイルしか含まれておらず、これは疑わしい兆候の一つと見なせる
  • 2025年1月15日の更新によると、Snykの研究者はブログ公開の翌日にCursor関連パッケージを削除した
  • 2025年1月14日にThe Registerが関連記事を公開した: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • 同日、Snykはブログで対応を投稿し、自分たちに非はないという趣旨を主張した: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

関連記事

1件のコメント

 
GN⁺ 2025-01-14
Hacker Newsの意見

  • [訂正: 下のCursor開発者の回答を見る限り、Cursorが承認したわけではなさそう] Cursor内部に、該当パッケージが存在する非公開NPMレジストリがあり、NPMの動作方式のせいで、攻撃者が公開レジストリから同じパッケージを取得させるようだましやすい状況のように聞こえる
    おそらくSnykの社員が、Cursorのビルドの一部がこのように誤設定されていることを見つけた、あるいは疑って、概念実証としてパッケージを公開したのだと思う。パッケージの説明が「for Cursor」だったのを見ると、この目的で雇われたのだと思っていた
    そうであれば大きく見るべき点はなく、核心が非公開レジストリを迂回する誤設定を示すことなら、セキュリティ研究者が概念実証に非公開NPMレジストリを使うことはできなかったはず
    特に多くのプロキシは、最新パッケージのバージョンがより高い場合、非公開よりも公開レジストリを選ぶ: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Cursorの開発者です。妥当な推測ですが、実際とは少し違います。Snykのパッケージは、私たちがバンドルしている拡張機能名にすぎず、私たちはそれらをパッケージ化したり、どのレジストリにも公開したりしていません
      VS Codeと同じ方法で扱っています: https://github.com/microsoft/vscode/tree/main/extensions
      私たちはSnykを雇っておらず、この件を見た後に連絡したところ謝罪を受けました。正確に何をしようとしていたのかは確認できていませんが、誰かが依存関係混同の脆弱性を疑ったという説明はもっともらしいです。ただ、公開NPM上で実際に環境変数を送信させたのは、かなり無責任だと思います
    • 概念実証は、インストールしたホスト情報とすべての環境変数を外部に送らなくてもできたはず。それは一線を越えているように見える
    • 誰かに自分の環境全体、つまりenvコマンドの出力への完全なアクセスを許すのは、ほとんどの人にとって大問題だろう
    • SnykでDevRel & SecRelを担当しています。噂を整理するために先ほど記事を公開し、状況についてかなり深い情報を盛り込みました: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • これはNPMで修正されるべきだったのでは？ PortSwiggerの研究者が以前これについて発表していた記憶があり、Apple、Microsoft、MetaのようなほぼすべてのFAANGが当時脆弱だったと記憶している

  • 興味深いことに、Snyk共同創業者がCursorの競合を立ち上げている
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    不正行為がなかったことを願う

    • 彼らとのやり取りはすべて非常に否定的なものだったので、不正行為があった可能性はかなり高いと思う

  • これからは、すべての開発を仮想マシンの中で本気でやるべきなのかもしれない。プロジェクト1つにつきVMを1つ。自分でも気づかないうちにミスをしてセキュリティを台無しにしてしまう巧妙な方法が多すぎる。慰めがあるとすれば、盗まれるような秘密や資産のない無名の存在だということくらい
    IDE、プラグイン、開発ユーティリティ、言語ライブラリ、OSパッケージなど、あまりにも多くのコードを盲信している

    • DockerコンテナのせいでVagrantの人気は冷めたように見えるが、開発環境を作る方法としては今でもVagrantが一番気に入っている
      数年前に働いていたところでは、ノートPCでWebブラウザと開発ツールが禁止されていた。ブラウザが必要ならCitrixで使う必要があり、コーディングが必要ならVDIを使うか、VMの中でツールを実行しなければならなかった
      当時はそのやり方がほとんど狂気じみて見えたが、だんだん理解できるようになってきた
    • 本当の問題はVMの映像性能だ。今でも単純にいまいち。VMでCinnamonを動かすと、GLアクセラレーションをまともに動かすのはほぼ不可能
      NVIDIAは仮想化GPU機能をエンタープライズ向けカードの背後に閉じ込めているため、効果のない命令変換に頼ることになる
      他のVMオーバーヘッドはほとんど我慢できるが、途切れて反応の鈍いGUIは思った以上に人間工学的に悪影響があり、妙に他の性能まで引き下げる
      Linux上でLinuxを仮想化する場合だけでもこの問題が解決すれば、すべてを仮想化する選択肢はずっと現実的になるはず
    • 信頼がここまで崩れているのは恐ろしいし、OSに毎月GB単位のアップデートが来ることも安心材料にはならない。プロジェクトごとに安定した隔離VMを置くという考えは気に入っている。このための標準的なオープンソースツールはあるのだろうか？
      具体的には、古いMacからM1のAsahi LinuxへGoとZigの開発環境を移しているところだが、TrueCryptとLittle Snitchの代替を探すところからつまずいている。こうしたVMツールは暗号化されたVMやファイアウォールルールをサポートしているのだろうか？ ここではVagrantが言及されていて、ネットワーク隔離はある程度解決してくれそうだが、それ以外に何を勧められるだろう？
    • その気持ちは分かるし、自分も何度もこれを考えた。今はやりたくないが、主な理由は手間ではない
      VMは自分を守ることはできるが、自分が作るソフトウェアのユーザーを守ることはできない。自分が防護服を着てようやく触れるような製品を顧客に送り、彼らが保護なしで安全に使えるとどう期待できるのか？
      自分が望む環境はそういうものではない
      現在の解決策は、依存関係を極端に厳しく選ぶことだ。より具体的には、プロジェクトや会社を信じるのではなく、人だけを信じるべきだと思っている。簡単ではないが、今のところこれより良い代案は見えていない
    • Linuxで複数のプロジェクトを開発している。主に、ツール、ビルドスクリプト、テストが機密データを読んだり、誤ってデータを破壊したりする可能性を心配して、Linux名前空間とbubblewrapでプロジェクト作業中のファイルアクセスを制限している
      プロジェクトごとの簡単なdotファイルにファイルシステムのバインドを書いておき、作業中に新しいターミナルを開くと、そのdotファイルを基準に自動で隔離される。認知的負荷は非常に低く、ほとんどシームレスに統合されている。多くの開発者が似たようなスクリプトを持っていそうだ。以前こういうプロジェクトを探したが見つからなかった。単純すぎてプロジェクト化するほどのものがないからなのか、それとも他の人たちがこれを何と呼んでいるのか分からないからなのかは分からない。参考になるものがあるとうれしい
      ネットワークアクセスは制限していない。すべてのトラフィックを記録し、自動で中間者プロキシを設定する実験はしたが、一般ユーザーとして使うには十分に快適ではなかった。もちろんカーネルの攻撃面は依然として残っている。ただ、主な心配はファイルが読まれたり破壊されたりすることだ

  • 記事で同意できないのは、「NPMパッケージを盲目的にインストールしないほうがよく、パッケージが怪しいかどうかを見るシグナルがある。このパッケージ群はpackage.jsonとindex.jsまたはmain.jsの2ファイルしかないので、正常かどうかを判断するフラグの1つだ」というくだり
    これはトップレベルのパッケージにはある程度通用するかもしれないが、推移的依存関係まで全部レビューするのはほぼ不可能
    依存関係が400個あるパッケージを取り込むなら、その表面積の10%でさえどうやってまともに確認するのか？ https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • そういう場合に適用すべきセキュリティ助言は別だ。依存関係400個のパッケージを取り込むな、ということ
    • この点では、SELinuxの大きな方向性は正しかった。ファイルを機密度データであらかじめ分類し、それに応じてアクセスを拒否すれば、この問題、たとえばNPMインストールがid_rsaにアクセスできないようにする問題は十分に解決できる
    • Reactのカルーセルコンポーネントが、いったいどうやって依存関係400個超を持つことになるんだ…
    • うちの会社ではSnykという素晴らしいセキュリティツールを使っている。ぜひ確認してみて /s

  • Snykは公開鍵をローテーションせず、ただ予告なく変えてしまう会社でもある: https://github.com/snyk/cli/pull/5649
    プロジェクトがGitHub以外のリポジトリホスティングに移ると「abandoned」と表示し、npm/PyPIに新しいリリースが出ても、放棄されたプロジェクトのままになる
    評判ほど能力は高くないと思う
    それに、Snykの営業担当者がメールで私を侮辱してきた。製品購入に興味がないということは、脆弱性だらけのソフトウェアしか使えない無能な開発者だという意味らしい

    • 開発が終わって最小限の保守だけで十分なライブラリにも減点を付ける
      保険会社がセキュリティチェックリスト項目を埋めろと言うから企業が買う、完全に本末転倒なソフトウェアに見える
    • その「abandoned」ラベル付けは特に残念だ。自分も最近GitHubから離れようとしているところだが、GitHubがあまりにも大きな支配力を持っているように感じる
      Codebergは面白そうだし、保守を引き受けられるならForejoのようなセルフホストの選択肢も良さそう
    • GitHub以外のリポジトリに移っただけで「abandoned」扱いし、npm/PyPIに新しいリリースが出てもそのままだなんて、良いチームの兆候だね /s
      Snykについてはプライドが高いという程度のこと以外あまり聞いたことがなかったが、かなり興味深い見方だ
    • そのメール本文を適切に伏せ字にした形で提供できるよね？

  • 文脈がこれ以上ないなら、Snyk 側にとっても見栄えはよくない。社員が NPM で自社サービスを実環境テストしたか、Cursor に対する合法的な監査を行う中で公開リソースを使わないようにするための統制と手順が不足していたということになる

    • なぜダメなのか？NPM は非公開リポジトリ内のパッケージと同じ名前の公開パッケージがあると奇妙な挙動をし、場合によっては公開パッケージを取得する。パッケージの先取りのような名前で呼ばれるものだと認識している。評価中にこれが可能だと示しただけかもしれない。私の考えでは被害もなく、問題もない

  • Snyk のテストのホワイトハット監査のように見える。oastify.com は Burp Collaborator のデフォルトサーバーなので検出されたようだ
    テストには非公開 npm リポジトリを使うべきだったし、ローカルで上書きするのは難しくない。独自の Collaborator サーバーも使うべきだった

    • データを積極的に持ち出しているのでホワイトハットではない。動作することを証明するだけなら、console.log を出す、npm install を失敗させる、ペイロードを抽出しない、といった方法でも十分だった

  • NPM がセキュリティ業界の雇用を生み出しているように見える。修正不能な混乱状態で、JSR のような競合が組織に十分な圧力をかけてくれることを願う

    • NPM だけの問題ではなく、全般的なサードパーティライブラリの信頼の問題だ。はるかに少ないとはいえ、NuGet のようなプラットフォームでもエクスプロイトは出ている。JSR でも出るだろう。不変性のおかげでセキュリティは高いが、悪意あるパッケージが明らかになる前にダウンロードしてしまうことまでは防げない
      むしろ DORA や NSIS のような規制が、サードパーティパッケージの監査をますます求めるようになる可能性が高い。これは重要産業での開発方法の変更を強制することになるだろう。また LLM の時代には、外部パッケージの利用は大幅に減ると見ている。OpenAPI 仕様の生成のようなことをするために、外部パッケージを持ってくる理由が何なのか？LLM なら 1〜2 時間の設定だけで必要な CLI スクリプトを書いてくれる。同様に、コードの退屈な部分を直接自動生成するために LLM を使わなくても、その作業を行う CLI ツールを作らせることができる。そうすれば外部要因に依存しなくて済むし、その CLI ツール群がひどいカウボーイコードである可能性はほぼ確実だが、出力物はツールを磨き込んで望む形にできる
      Go のように標準パッケージに必要なものを押し込む言語を見ると、標準ライブラリだけでも非常に簡単に多くのことができる世界が見える

  • 少し話題から外れるが、Snyk 自身のツールとサービスについて、まともなSBOMを受け取ったことがある人はいる？うちの会社に SBOM を作るソリューションを売ろうとしてきたので聞いている

    • Snyk はイスラエル軍の Unit 8200 出身者たちが設立した会社だ
      お金をもらってもインストールしないと思う。Unit 8200 が創業者を次々に輩出し、資金を提供していて、NSA のようにすでに足を踏み入れている構造に感じる
    • Syft のほうが良い結果が得られた
    • 私の経験では誤検知が多かった

  • Snyk Research Labs は、一般的なソフトウェアパッケージのテストと研究を通じてコミュニティに定期的に貢献している。今回の Cursor 研究は悪意を持ったものではなく、パッケージには Snyk Research Labs と研究者の連絡先が含まれていた。私たちは一部の VS Code 拡張機能における依存関係の混同を非常に具体的に調査しており、当該パッケージは開発者が直接インストールする対象ではなかった
    Snyk は責任ある公開ポリシーに従っている。誰もこのパッケージを取得しなかったが、もし誰かが取得していれば、ただちにフォローアップしていただろう

    • 攻撃を公開空間にばらまいて標的に当たることを期待するのは、責任ある行動の正反対だ。唯一「良い」点は、他の誰かが流れ弾を受ける前に現場で捕まったことだけだ
      対応としては、撃たれた人の葬式に謝罪文を送ると言っているように聞こえる。「善意」だったとしても、認証情報を侵害すればその人はすでに侵害された状態になり、悪意ある攻撃者にやられた場合とまったく同じ対応が必要になる
      これは悪意との差を感じにくいほど近い
      付け加えると、Snyk の利害関係者が現在 Cursor の競合製品をリリースしようとしている点も、皆覚えておくべきだ。善意を仮定するのがはるかに難しくなる
    • いいだろう。だが、なぜユーザーの環境変数を自分たちのところに送ったのか？脆弱性の確認は実際の環境値ではなく、ダミー値を送るだけでも十分可能だった
    • これは好意的に見てもグレーハットだ。意図は良かったのかもしれないが、このチームは許可なくデータにアクセスして流出させるソフトウェアを作成・配布しており、これは極めて違法だ。公開フォーラムにこうした投稿をする前に、法務チームに相談したほうがいい
    • もっともらしく聞こえるが、なぜ POST で環境変数を送り返したのか？完全に善意だったとしても、任意のパッケージに自分の env 出力を持たせたいとは思わない
    • 実際に Snyk の CTO である可能性があり、公式回答は人々が見るべきなので推薦はするが、これは本当に無責任に感じる。無実の開発者の認証情報を実際に盗まなくても概念実証はできたはずだ
      さらに Cursor の競合製品との利益相反がある以上、より慎重であるべきだった。意思決定も対応もひどい