Peneliti keamanan Snyk menyebarkan paket NPM berbahaya yang menargetkan Cursor.com

 (sourcecodered.com)
1 poin oleh GN⁺ 2025-01-14 | 1 komentar | Bagikan ke WhatsApp
  • Beberapa paket yang diunggah ke npm menyertakan skrip instalasi yang tampaknya menargetkan Cursor.com, dan saat diinstal mengirim informasi sistem ke layanan web eksternal
  • Pendistribusinya adalah pengguna npm sn4k-s3c, dan menggunakan nama yang mengingatkan pada paket internal Cursor seperti cursor-retreival, cursor-always-local, cursor-shadow-workspace
  • Output env yang diambil paket dapat mencakup variabel lingkungan sensitif seperti kunci AWS, token npm, dan kredensial GitHub, sehingga cakupan dampaknya bisa besar
  • OpenSSF package analysis scanner mengidentifikasi paket-paket itu sebagai berbahaya, dan OSV membuat 3 advisori: MAL-2025-27, MAL-2025-28, MAL-2025-29
  • Dalam metadata npm, email snyk.io milik Snyk Security Labs muncul sebagai penerbit, lalu setelah itu peneliti Snyk menurunkan paket-paket tersebut dan Snyk merespons lewat blog

Paket npm yang tampaknya menargetkan Cursor

  • Dalam proses deteksi paket berbahaya oleh SourceCodeRed, ditemukan beberapa paket yang diunggah ke npm
  • Nama paketnya berbentuk seperti paket internal terkait Cursor
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • Pendistribusinya ditampilkan sebagai pengguna npm sn4k-s3c
  • Disebutkan bahwa daftar paket dapat dilihat di https://www.npmjs.com/~sn4k-s3c

Tindakan yang dilakukan saat instalasi

  • Saat paket diinstal, paket mengumpulkan data sistem lalu mengirimkannya ke layanan web yang dikendalikan penyerang
  • Dari tangkapan layar, paket mengambil output perintah env
  • Output env dapat berisi pengaturan sistem sekaligus variabel lingkungan yang sensitif
    • kunci AWS
    • token npm
    • kredensial GitHub
    • variabel lingkungan sensitif lainnya
  • Akibatnya, hanya dengan instalasi saja, informasi lingkungan lokal dapat bocor ke luar

Kemungkinan dependency confusion dan hasil deteksi

  • Paket dengan bentuk seperti ini sering muncul dalam serangan dependency confusion yang menargetkan perusahaan tertentu
  • Tidak dipastikan apakah Cursor.com memiliki program bug bounty atau apa latar belakang spesifiknya
  • SourceCodeRed menduga Cursor mungkin memiliki paket npm privat seperti cursor-always-local, cursor-retrieval, cursor-shadow-workspace
  • Penyerang mungkin berharap karyawan Cursor secara tidak sengaja memasang paket publik tersebut lalu mengirimkan data
  • OpenSSF package analysis scanner mengidentifikasi paket-paket tersebut sebagai berbahaya, dan OSV membuat 3 advisori malware

Metadata penerbit

  • Dalam metadata paket npm, penerbit menggunakan alamat email snyk.io milik tim Snyk Security Labs
  • Disebutkan bahwa metadata email penerbit ini adalah bagian yang tidak bisa dipalsukan
  • Field author secara spesifik menyebut karyawan Snyk
  • Field author bisa dipalsukan, tetapi karena penerbit memakai email Snyk yang terverifikasi, muncul dugaan bahwa ini memang berasal dari Snyk

Tanggapan pengguna dan pembaruan berikutnya

  • SourceCodeRed mengatakan sudah memberi tahu npm, tetapi saat itu paket-paket tersebut masih belum ditandai sebagai berbahaya
  • Banyak alat keamanan rantai pasok perangkat lunak hanya bisa memblokir jika sudah mengetahui bahwa paket itu berbahaya
  • Disarankan untuk tidak sembarang memasang paket npm
  • Paket-paket tersebut hanya berisi dua file, yaitu package.json dan index.js atau main.js, yang dapat dilihat sebagai salah satu tanda mencurigakan
  • Menurut pembaruan 15 Januari 2025, peneliti Snyk menurunkan paket terkait Cursor sehari setelah blog dipublikasikan
  • Pada 14 Januari 2025, The Register menerbitkan artikel terkait: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • Di hari yang sama, Snyk memposting tanggapan di blog dan menyatakan pada intinya bahwa mereka tidak melakukan kesalahan: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-14
Pendapat di Hacker News

  • [Koreksi: melihat jawaban pengembang Cursor di bawah, sepertinya ini bukan sesuatu yang disetujui Cursor] Kedengarannya seperti ada registry NPM privat di dalam Cursor yang berisi paket-paket tersebut, dan karena cara kerja NPM, situasinya memudahkan penyerang untuk menipu agar paket dengan nama yang sama diambil dari registry publik
    Mungkin seorang karyawan Snyk menemukan atau mencurigai bahwa sebagian build Cursor salah dikonfigurasi seperti ini, lalu mengunggah paket sebagai proof of concept. Melihat deskripsi paketnya “for Cursor”, saya sempat mengira mereka dipekerjakan untuk tujuan ini
    Kalau begitu, sebenarnya tidak ada hal besar; jika intinya adalah menunjukkan salah konfigurasi yang melewati registry privat, peneliti keamanan memang tidak mungkin memakai registry NPM privat untuk proof of concept
    Terutama karena banyak proxy memilih registry publik ketimbang privat jika versi paket terbaru di publik lebih tinggi: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Saya pengembang Cursor. Dugaan itu masuk akal, tapi agak berbeda dari kenyataannya. Paket-paket Snyk itu hanya nama ekstensi yang kami bundel, dan kami tidak memaketkannya atau mengunggahnya ke registry mana pun
      Kami menanganinya dengan cara yang sama seperti VS Code: https://github.com/microsoft/vscode/tree/main/extensions
      Kami tidak mempekerjakan Snyk, dan setelah mengetahui hal ini kami menghubungi mereka lalu menerima permintaan maaf. Kami belum mendapat konfirmasi persis apa yang ingin mereka lakukan, tetapi penjelasan bahwa seseorang mencurigai adanya kerentanan dependency confusion terdengar masuk akal. Namun, membuatnya benar-benar mengirim variabel lingkungan dari NPM publik menurut saya cukup tidak bertanggung jawab
    • Proof of concept bisa dilakukan tanpa mengirim informasi host yang menginstalnya dan semua variabel lingkungan ke luar. Itu tampaknya sudah melewati batas
    • Memberi seseorang akses penuh ke seluruh lingkungan saya, yaitu seluruh output perintah env, akan menjadi masalah besar bagi kebanyakan orang
    • Saya menangani DevRel & SecRel di Snyk. Untuk meluruskan rumor, saya baru saja menerbitkan tulisan yang berisi informasi cukup mendalam tentang situasinya: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • Bukankah ini seharusnya sudah diperbaiki di NPM? Saya ingat ada peneliti dari PortSwigger yang dulu mempresentasikan hal ini, dan seingat saya hampir semua FAANG seperti Apple, Microsoft, dan Meta rentan saat itu

  • Menariknya, co-founder Snyk memulai pesaing Cursor
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    Semoga tidak ada kecurangan

    • Karena semua interaksi saya dengan mereka sangat negatif, saya pikir kemungkinan adanya kecurangan cukup tinggi

  • Rasanya sekarang semua pengembangan harus benar-benar dilakukan di dalam mesin virtual. Satu VM untuk satu proyek. Ada terlalu banyak cara licik yang bisa membuatku tanpa sadar melakukan kesalahan dan merusak keamanan. Satu-satunya penghiburan adalah aku orang tak dikenal yang tidak punya rahasia atau aset untuk dicuri
    Kita terlalu banyak memercayai kode begitu saja, mulai dari IDE, plugin, utilitas pengembangan, library bahasa, paket sistem operasi, dan sebagainya

    • Popularitas Vagrant tampaknya meredup karena container Docker, tetapi sebagai cara membuat lingkungan pengembangan, aku masih paling suka Vagrant
      Di tempatku bekerja beberapa tahun lalu, laptop dilarang menjalankan browser web dan alat pengembangan. Kalau butuh browser harus lewat Citrix, dan kalau perlu coding harus memakai VDI atau menjalankan alat di dalam VM
      Saat itu cara itu terlihat hampir gila, tetapi lama-lama aku makin memahaminya
    • Masalah sebenarnya adalah performa grafis VM. Sampai sekarang masih buruk. Menjalankan Cinnamon di VM membuat akselerasi GL hampir mustahil berfungsi dengan benar
      Karena NVIDIA mengunci fitur GPU virtualisasi di balik kartu enterprise, kita jadi bergantung pada penerjemahan instruksi yang tidak efektif
      Hampir semua overhead VM lain masih bisa kutoleransi, tetapi GUI yang tersendat dan tidak responsif berdampak buruk pada ergonomi lebih dari yang diduga, dan anehnya ikut menurunkan performa lain
      Kalau masalah ini bisa diselesaikan setidaknya untuk virtualisasi Linux di atas Linux, opsi untuk memvirtualisasikan semuanya akan jauh lebih realistis
    • Mengerikan melihat kepercayaan runtuh sampai sejauh ini, dan update sistem operasi berukuran GB setiap bulan pun tidak membuat tenang. Aku suka gagasan memiliki VM terisolasi yang stabil untuk tiap proyek. Apakah ada alat open source standar untuk ini?
      Secara spesifik, aku sedang memindahkan lingkungan pengembangan Go dan Zig dari Mac lama ke Asahi Linux di M1, tetapi sudah tersendat sejak mencari pengganti TrueCrypt dan Little Snitch. Apakah alat VM seperti ini mendukung VM terenkripsi dan aturan firewall? Vagrant disebut di sini dan sepertinya bisa menangani isolasi jaringan sampai batas tertentu, tetapi apa lagi yang bisa direkomendasikan?
    • Aku mengerti perasaan itu, dan aku juga sudah berkali-kali memikirkannya. Sekarang aku tidak ingin melakukannya, dan alasan utamanya bukan karena repot
      VM bisa melindungiku, tetapi tidak melindungi pengguna software yang kubuat. Bagaimana aku bisa mengirim produk yang hanya berani kusentuh dengan pakaian pelindung kepada pelanggan, lalu berharap mereka bisa memakainya dengan aman tanpa perlindungan?
      Itu bukan lingkungan yang kuinginkan
      Solusi saat ini adalah memilih dependensi dengan sangat ketat. Lebih spesifiknya, menurutku yang harus dipercaya bukan proyek atau perusahaan, melainkan orangnya saja. Ini tidak mudah, tetapi untuk saat ini aku belum melihat alternatif yang lebih baik
    • Aku mengembangkan beberapa proyek di Linux. Karena terutama khawatir alat, skrip build, dan test bisa membaca data sensitif atau tanpa sengaja merusak data, aku membatasi akses file saat bekerja pada proyek dengan namespace Linux dan bubblewrap
      Aku menuliskan bind filesystem di file dot sederhana per proyek, lalu saat membuka terminal baru ketika bekerja, terminal itu otomatis terisolasi berdasarkan file dot tersebut. Beban kognitifnya sangat rendah dan integrasinya hampir mulus. Kurasa banyak developer punya skrip serupa. Dulu aku pernah mencari proyek seperti ini tetapi tidak menemukannya; entah karena terlalu sederhana untuk dijadikan proyek, atau karena aku tidak tahu orang lain menyebutnya apa. Akan bagus kalau ada referensi yang bisa dilihat
      Akses jaringan tidak kubatasi. Aku pernah bereksperimen mencatat semua traffic dan otomatis menyiapkan proxy man-in-the-middle, tetapi belum cukup nyaman untuk dipakai sebagai pengguna biasa. Tentu saja permukaan serangan kernel masih tetap ada. Namun kekhawatiran utamaku adalah file dibaca atau dihancurkan

  • Bagian tulisan yang tidak kusetujui adalah: “Sebaiknya jangan memasang paket NPM secara membabi buta, dan ada sinyal untuk melihat apakah paket mencurigakan. Paket-paket ini hanya punya dua file, package.json dan index.js atau main.js, jadi itu salah satu flag untuk menilai apakah normal”
    Ini mungkin cukup berlaku untuk paket tingkat atas, tetapi hampir mustahil meninjau semua dependensi transitif
    Kalau mengambil paket dengan 400 dependensi, bagaimana mungkin memeriksa bahkan 10% dari permukaan itu dengan benar? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • Saran keamanan yang berlaku dalam kasus seperti itu berbeda: jangan mengambil paket dengan 400 dependensi
    • Pada titik ini, arah besar SELinux memang benar. Jika file diklasifikasikan lebih dulu sebagai data sensitif, lalu akses ditolak berdasarkan klasifikasi itu, masalah ini—misalnya mencegah instalasi NPM mengakses id_rsa—bisa cukup terselesaikan
    • Bagaimana mungkin komponen carousel React punya lebih dari 400 dependensi…
    • Di perusahaan kami, kami memakai alat keamanan hebat bernama Snyk. Sangat disarankan untuk mencobanya /s

  • Snyk juga perusahaan yang tidak merotasi kunci publik, melainkan menggantinya begitu saja tanpa pemberitahuan: https://github.com/snyk/cli/pull/5649
    Jika sebuah proyek pindah ke hosting repositori selain GitHub, mereka menandainya sebagai “abandoned”, dan meskipun ada rilis baru di npm/PyPI, proyek itu tetap dianggap ditinggalkan
    Menurutku kemampuan mereka tidak sebesar reputasinya
    Selain itu, sales Snyk pernah menghinaku lewat email. Rupanya kalau tidak tertarik membeli produk mereka, itu berarti aku developer tidak kompeten yang hanya bisa memakai software penuh kerentanan

    • Library yang pengembangannya sudah selesai dan hanya perlu pemeliharaan minimal pun diberi penalti
      Terlihat seperti software yang sepenuhnya terbalik, dibeli perusahaan karena perusahaan asuransi menyuruh mereka mengisi item checklist keamanan
    • Label “abandoned” itu sangat disayangkan. Aku juga belakangan ini sedang mencoba keluar dari GitHub, dan rasanya GitHub punya terlalu banyak kendali
      Codeberg terlihat menarik, dan kalau sanggup mengurus pemeliharaannya, opsi self-hosted seperti Forejo juga tampak bagus
    • Dipindah ke repositori selain GitHub lalu dianggap “abandoned”, dan meski ada rilis baru di npm/PyPI tetap begitu? Sinyal tim yang bagus sekali /s
      Aku belum banyak mendengar tentang Snyk selain bahwa mereka cukup tinggi hati, jadi ini sudut pandang yang cukup menarik
    • Kamu tentu bisa memberikan isi email itu dalam bentuk yang sudah disensor seperlunya, kan?

  • Tanpa konteks lebih lanjut, ini juga tidak terlihat baik bagi Snyk. Artinya, seorang karyawan menguji layanan perusahaannya sendiri di lingkungan nyata melalui NPM, atau saat melakukan audit yang sah terhadap Cursor, mereka kekurangan kontrol dan prosedur untuk memastikan tidak menggunakan sumber daya publik

    • Kenapa tidak boleh? NPM berperilaku aneh jika ada paket publik dengan nama yang sama dengan paket di repositori privat, dan dalam beberapa kasus akan mengambil paket publik. Seingat saya ini disebut semacam package squatting. Mungkin saja selama evaluasi mereka hanya menunjukkan bahwa hal ini mungkin dilakukan. Menurut saya tidak ada kerugian dan tidak ada masalah

  • Ini terlihat seperti audit white-hat dari pengujian Snyk. oastify.com adalah server default Burp Collaborator, jadi mungkin itu sebabnya terdeteksi
    Seharusnya pengujian memakai repositori npm privat, dan tidak sulit untuk menimpanya secara lokal. Mereka juga seharusnya memakai server Collaborator sendiri

    • Itu bukan white-hat karena mereka secara aktif mengekstraksi data. Jika hanya ingin membuktikan bahwa ini bekerja, cukup dengan mencetak console.log, membuat npm install gagal, atau memakai cara yang tidak mengekstrak payload

  • NPM tampaknya menciptakan lapangan kerja bagi industri keamanan. Ini kekacauan yang tidak bisa diperbaiki, dan saya berharap pesaing seperti JSR bisa memberi tekanan yang cukup pada organisasi tersebut

    • Ini bukan hanya masalah NPM, melainkan masalah kepercayaan pada library pihak ketiga secara umum. Meski jauh lebih jarang, eksploit juga muncul di platform seperti NuGet. Di JSR pun akan muncul. Immutability memang membuatnya lebih aman, tetapi tidak mencegah orang mengunduh paket berbahaya sebelum paket itu terungkap
      Justru regulasi seperti DORA dan NSIS kemungkinan besar akan makin menuntut audit paket pihak ketiga. Ini akan memaksa industri penting mengubah cara pengembangan. Selain itu, di era LLM saya rasa penggunaan paket eksternal akan jauh berkurang. Untuk apa mengambil paket eksternal hanya demi hal seperti membuat spesifikasi OpenAPI? Dengan satu-dua jam pengaturan, LLM bisa menuliskan skrip CLI yang dibutuhkan. Demikian pula, meski tidak memakai LLM untuk langsung menghasilkan bagian kode yang membosankan, kita bisa memintanya membuat tool CLI yang melakukan pekerjaan itu. Dengan begitu tidak perlu bergantung pada faktor eksternal, dan meskipun hampir pasti tool CLI itu berupa kode koboi yang berantakan, output-nya bisa dibentuk sesuai keinginan dengan menyempurnakan tool tersebut
      Jika melihat bahasa seperti Go yang memasukkan hal-hal yang dibutuhkan ke paket standar, tampak sebuah dunia tempat banyak hal bisa dilakukan dengan sangat mudah hanya memakai standard library

  • Sedikit keluar topik, tetapi apakah ada yang pernah mendapatkan SBOM yang layak untuk tool dan layanan Snyk sendiri? Saya bertanya karena mereka mencoba menjual solusi pembuat SBOM ke perusahaan kami

    • Snyk adalah perusahaan yang didirikan oleh orang-orang dari Unit 8200 militer Israel
      Saya rasa saya tidak akan memasangnya meski dibayar. Unit 8200 terus melahirkan pendiri dan mendanai mereka, terasa seperti struktur yang sudah menaruh kaki di pintu, mirip NSA
    • Saya mendapat hasil yang lebih baik dengan Syft
    • Dalam pengalaman saya, false positive-nya banyak

  • Snyk Research Labs secara rutin berkontribusi kepada komunitas melalui pengujian dan riset atas paket perangkat lunak umum. Riset Cursor kali ini tidak berniat jahat, dan paketnya mencantumkan Snyk Research Labs serta kontak penelitinya. Kami secara sangat spesifik meneliti dependency confusion pada beberapa ekstensi VS Code, dan paket-paket tersebut memang bukan sesuatu yang ditujukan untuk dipasang langsung oleh developer
    Snyk mengikuti kebijakan disclosure yang bertanggung jawab. Tidak ada yang mengambil paket ini, tetapi jika ada yang melakukannya, kami akan segera melakukan tindak lanjut

    • Menebarkan serangan di ruang publik dan berharap mengenai target adalah kebalikan dari tindakan yang bertanggung jawab. Satu-satunya bagian yang “baik” adalah mereka tertangkap di tempat sebelum orang lain terkena peluru nyasar
      Responsnya terdengar seperti akan mengirim surat permintaan maaf ke pemakaman orang yang tertembak. Sekalipun “berniat baik”, jika kredensial seseorang dikompromikan, orang itu sudah berada dalam kondisi terkompromikan dan harus merespons sama seperti ketika terkena penyerang jahat
      Ini begitu dekat sampai sulit merasakan bedanya dengan niat jahat
      Selain itu, semua orang juga perlu ingat bahwa pemangku kepentingan Snyk saat ini sedang mencoba meluncurkan produk pesaing Cursor. Menjadi jauh lebih sulit untuk berprasangka baik
    • Baiklah. Tapi kenapa mengirim environment variable pengguna pulang ke server mereka? Untuk memverifikasi kerentanan, mengirim nilai dummy saja sudah cukup, bukan nilai lingkungan yang sebenarnya
    • Sebaik-baiknya, ini gray-hat. Niatnya mungkin baik, tetapi tim ini membuat dan mendistribusikan perangkat lunak yang mengakses serta mengekfiltrasi data tanpa izin, dan itu sangat ilegal. Sebaiknya berkonsultasi dengan tim hukum sebelum mengunggah tulisan seperti ini di forum publik
    • Kedengarannya masuk akal, tetapi kenapa mengirim balik environment variable lewat POST? Sekalipun sepenuhnya beritikad baik, saya tidak ingin paket sembarang memiliki output env saya
    • Ini mungkin benar-benar CTO Snyk dan jawaban resmi perlu dilihat orang, jadi saya upvote, tetapi ini terasa sangat tidak bertanggung jawab. Mereka bisa membuat proof of concept tanpa benar-benar mencuri kredensial developer yang tidak bersalah
      Terlebih lagi, karena ada konflik kepentingan dengan produk pesaing Cursor, mereka seharusnya lebih berhati-hati. Pengambilan keputusan maupun responsnya buruk sekali