Snyk güvenlik araştırmacıları, Cursor.com’u hedef alan kötü amaçlı NPM paketleri yayımladı

 (sourcecodered.com)
1 puan yazan GN⁺ 2025-01-14 | 1 yorum | WhatsApp'ta paylaş
  • npm’e yüklenen birden fazla paket, Cursor.com’u hedef aldığı düşünülen kurulum betikleri içeriyordu ve kurulum sırasında sistem bilgilerini harici bir web servisine gönderiyordu
  • Dağıtımı yapan kişi npm kullanıcısı sn4k-s3c idi ve cursor-retreival, cursor-always-local, cursor-shadow-workspace gibi Cursor iç paketlerini çağrıştıran adlar kullandı
  • Paketlerin topladığı env çıktısında AWS anahtarları, npm token’ları, GitHub kimlik bilgileri gibi hassas ortam değişkenleri bulunabileceğinden etkinin kapsamı büyüyebilir
  • OpenSSF package analysis scanner paketleri kötü amaçlı olarak tanımladı ve OSV, MAL-2025-27, MAL-2025-28, MAL-2025-29 olmak üzere 3 uyarı oluşturdu
  • npm meta verilerinde, yayımlayıcı olarak Snyk Security Labs’in snyk.io e-posta adresi görünüyordu; daha sonra bir Snyk araştırmacısı paketleri kaldırdı ve Snyk bir blog yazısıyla yanıt verdi

Cursor’u hedef aldığı düşünülen npm paketleri

  • SourceCodeRed’in kötü amaçlı paket tespit sürecinde npm’e yüklenen birden fazla paket belirlendi
  • Paket adları, Cursor ile ilişkili iç paketleri akla getiren bir biçimdeydi
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • Dağıtıcı, npm kullanıcısı sn4k-s3c olarak görünüyordu
  • Paket listesine https://www.npmjs.com/~sn4k-s3c adresinden bakılabileceği belirtildi

Kurulum sırasında gerçekleştirilen işlemler

  • Paketler kurulduğunda sistem verilerini toplayıp saldırganın kontrolündeki bir web servisine gönderiyordu
  • Ekran görüntüsüne göre paketler env komutunun çıktısını alıyordu
  • env çıktısı, sistem ayarlarıyla birlikte hassas ortam değişkenlerini de içerebilir
    • AWS anahtarları
    • npm token’ları
    • GitHub kimlik bilgileri
    • Diğer hassas ortam değişkenleri
  • Sonuç olarak yalnızca kurulumla birlikte yerel ortam bilgileri harici tarafa sızdırılabilir

Bağımlılık karışıklığı olasılığı ve tespit sonuçları

  • Bu tür paketler, belirli bir şirketi hedef alan dependency confusion saldırılarında sık görülür
  • Cursor.com’un bir bug bounty programı olup olmadığı veya somut arka plan doğrulanmadı
  • SourceCodeRed, Cursor’un cursor-always-local, cursor-retrieval, cursor-shadow-workspace gibi özel npm paketlerine sahip olabileceğinden şüphelendi
  • Saldırgan, bir Cursor çalışanının yanlışlıkla herkese açık paketi kurup verileri göndermesini ummuş olabilir
  • OpenSSF package analysis scanner bu paketleri kötü amaçlı olarak tanımladı ve OSV 3 kötü amaçlı yazılım uyarısı oluşturdu

Yayımlayıcı meta verileri

  • npm paket meta verilerine göre yayımlayıcı, Snyk Security Labs ekibine ait snyk.io e-posta adresini kullanıyordu
  • Bu yayımlayıcı e-posta meta verisinin taklit edilemeyen bir alan olduğu belirtildi
  • author alanı belirli bir Snyk çalışanından söz ediyordu
  • author alanı taklit edilebilir olsa da, yayımlayıcının doğrulanmış bir Snyk e-postası olması nedeniyle bunun gerçekten Snyk kaynaklı olduğu yönünde bir çıkarım yapıldı

Kullanıcıların alabileceği önlemler ve sonraki güncellemeler

  • SourceCodeRed npm’i bilgilendirdi ancak o sırada paketlerin henüz kötü amaçlı olarak işaretlenmediği aktarıldı
  • Pek çok yazılım tedarik zinciri güvenlik aracı, bir paketin kötü amaçlı olduğunu bilmeden engelleme yapamaz
  • npm paketlerinin gelişigüzel kurulmamasi tavsiye ediliyor
  • Söz konusu paketler yalnızca package.json ile index.js veya main.js olmak üzere iki dosya içeriyordu; bu da şüphe işaretlerinden biri sayılabilir
  • 15 Ocak 2025 güncellemesine göre bir Snyk araştırmacısı, blog yazısının yayımlanmasından sonraki gün Cursor ile ilgili paketleri kaldırdı
  • 14 Ocak 2025’te The Register konuyla ilgili bir haber yayımladı: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • Aynı gün Snyk de blogunda bir yanıt yayımladı ve özünde kendilerinin bir hatası olmadığını savundu: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

İlgili okumalar

1 yorum

 
GN⁺ 2025-01-14
Hacker News görüşleri

  • [Düzeltme: Aşağıdaki Cursor geliştiricisinin yanıtına bakınca bunun Cursor tarafından onaylanmış olmadığı anlaşılıyor] Cursor içinde söz konusu paketlerin bulunduğu özel bir NPM registry var ve NPM’in çalışma biçimi nedeniyle saldırganın aynı paketleri genel registry’den çektirmesi kolaymış gibi görünüyor
    Muhtemelen bir Snyk çalışanı, Cursor build’inin bir bölümünün bu şekilde yanlış yapılandırıldığını buldu ya da bundan şüphelendi ve bir kavram kanıtı olarak paketi yayımladı. Paket açıklamasında “for Cursor” yazdığını görünce bunun için tutulduklarını sanmıştım
    Eğer durum buysa burada çok büyük bir şey yok; asıl mesele özel registry’yi atlayan bir yanlış yapılandırmayı göstermekse, güvenlik araştırmacısı kavram kanıtı için özel NPM registry kullanamazdı
    Özellikle birçok proxy, en güncel paket sürümü daha yüksekse özel registry yerine genel registry’yi seçer: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Cursor geliştiricisiyim. Makul bir tahmin ama gerçekte olan biraz farklı. Snyk paketleri sadece bizim bundle’a dahil ettiğimiz uzantı adları ve biz onları paketlemiyor ya da herhangi bir registry’ye yüklemiyoruz
      Bunu VS Code ile aynı şekilde ele alıyoruz: https://github.com/microsoft/vscode/tree/main/extensions
      Snyk’yı biz tutmadık; bunu gördükten sonra onlarla iletişime geçtik ve özür aldık. Tam olarak ne yapmaya çalıştıkları doğrulanmadı ama birinin dependency confusion zafiyeti olduğundan şüphelenmiş olması kulağa mantıklı geliyor. Yine de genel NPM üzerinden gerçekten ortam değişkenlerini göndertmiş olmaları bana oldukça sorumsuzca geliyor
    • Kavram kanıtı, kurulu host bilgilerini ve tüm ortam değişkenlerini dışarı göndermeden de yapılabilirdi. Bu, sınırı aşmış gibi görünüyor
    • Birine tüm ortamıma, yani env komutunun çıktısının tamamına erişim vermek, çoğu kişi için büyük bir sorun olurdu
    • Snyk’te DevRel & SecRel’den sorumluyum. Söylentileri netleştirmek için az önce bir yazı yayımladım ve olayla ilgili epey derin bilgi içeriyor: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • Bunun NPM tarafında düzeltilmiş olması gerekmiyor muydu? PortSwigger tarafındaki bir araştırmacının bunu daha önce anlattığını hatırlıyorum ve o dönemde Apple, Microsoft, Meta gibi neredeyse tüm FAANG şirketlerinin etkilenebilir olduğunu hatırlıyorum

  • İlginç olan, Snyk kurucu ortaklarından biri Cursor’a rakip bir şirket kurdu
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    Umarım ortada bir usulsüzlük yoktur

    • Onlarla yaşadığım tüm etkileşimler çok olumsuz olduğu için, usulsüzlük olmuş olma ihtimalinin epey yüksek olduğunu düşünüyorum

  • Artık tüm geliştirmeyi sanal makine içinde ciddi ciddi yapmam gerekecek gibi geliyor. Proje başına bir VM. Ben fark etmeden hata yapıp güvenliği bozmanın çok fazla sinsi yolu var. Tek tesellim, çalınacak sırları ya da serveti olmayan isimsiz biri olmam
    IDE, eklentiler, geliştirme yardımcı araçları, dil kütüphaneleri, işletim sistemi paketleri gibi fazlasıyla çok koda körü körüne güveniyoruz

    • Docker konteynerleri yüzünden Vagrant’ın popülerliği sönmüş gibi görünüyor ama geliştirme ortamı kurma yöntemi olarak hâlâ en çok Vagrant hoşuma gidiyor
      Birkaç yıl önce çalıştığım bir yerde dizüstünde web tarayıcısı ve geliştirme araçları yasaktı. Tarayıcı gerekirse Citrix üzerinden kullanmak gerekiyordu; kod yazmak gerekirse ya VDI kullanılıyor ya da araçlar bir VM içinde çalıştırılıyordu
      O zamanlar bu yaklaşım neredeyse delilik gibi görünüyordu ama giderek daha iyi anlıyorum
    • Asıl sorun VM’in grafik performansı. Hâlâ düpedüz kötü. VM içinde Cinnamon çalıştırırken GL hızlandırmayı düzgün çalıştırmak neredeyse imkânsız
      NVIDIA sanallaştırılmış GPU özelliklerini kurumsal kartların arkasına kilitlediği için, etkisiz komut çevirilerine bel bağlamak zorunda kalıyorsunuz
      Diğer VM ek yüklerinin neredeyse hepsine katlanabiliyorum ama takılan, tepki vermeyen GUI ergonomi açısından beklenenden daha kötü etki yapıyor ve garip şekilde diğer performansı da aşağı çekiyor
      En azından Linux üzerinde Linux sanallaştırırken bu sorun çözülse, her şeyi sanallaştırma seçeneği çok daha gerçekçi olurdu
    • Güvenin bu kadar çökmesi korkunç ve işletim sistemine GB’larca güncelleme gelmesi de güven vermiyor. Proje başına kararlı bir yalıtım VM’i fikri hoşuma gidiyor. Bunun için standart bir açık kaynak araç var mı?
      Daha somut söylersem, eski bir Mac’ten M1’deki Asahi Linux’a Go ve Zig geliştirme ortamını taşıyorum; daha TrueCrypt ve Little Snitch alternatifleri bulmakta zorlanıyorum. Bu VM araçları şifrelenmiş VM’leri ve güvenlik duvarı kurallarını destekliyor mu? Burada Vagrant’tan bahsedilmiş ve ağ yalıtımını bir ölçüde çözecek gibi duruyor ama onun dışında ne önerilebilir?
    • Ne hissettiğini anlıyorum, ben de bunu birçok kez düşündüm. Şu anda yapmak istemiyorum ama ana sebep zahmeti değil
      VM beni koruyabilir ama ürettiğim yazılımın kullanıcılarını korumaz. Ben ancak koruyucu kıyafet giyince dokunabildiğim bir ürünü müşteriye gönderip onların korumasız şekilde güvenle kullanmasını nasıl bekleyebilirim?
      Benim istediğim ortam bu değil
      Şu anki çözümüm bağımlılıkları aşırı seçici davranarak belirlemek. Daha açık söylemek gerekirse, projelere ya da şirketlere değil yalnızca insanlara güvenmek gerektiğini düşünüyorum. Kolay değil ama şimdilik daha iyi bir alternatif göremiyorum
    • Linux’ta birden fazla proje geliştiriyorum. Özellikle araçların, build script’lerin ve testlerin hassas verileri okuma ya da yanlışlıkla veriyi yok etme ihtimalinden endişe ettiğim için, proje üzerinde çalışırken dosya erişimini sınırlamak amacıyla Linux namespace’leri ve bubblewrap kullanıyorum
      Proje başına basit bir dot dosyasına dosya sistemi bind’lerini yazıyorum; çalışırken yeni bir terminal açıldığında o dot dosyasına göre otomatik olarak yalıtılıyor. Zihinsel yükü çok düşük ve neredeyse kusursuz biçimde entegre oluyor. Birçok geliştiricinin benzer script’leri vardır diye düşünüyorum. Geçmişte böyle bir proje aradım ama bulamadım; ya fazla basit olduğu için projeye dönüşmemiştir ya da başkalarının buna ne dediğini bilmiyorumdur. Başvurulacak bir şey olsa iyi olurdu
      Ağ erişimini kısıtlamıyorum. Tüm trafiği kaydedip otomatik bir man-in-the-middle proxy kuran denemeler yaptım ama sıradan kullanıcı kullanımı için yeterince rahat değildi. Elbette çekirdek saldırı yüzeyi hâlâ duruyor. Yine de asıl kaygım dosyaların okunması ya da yok edilmesi

  • Yazıda katılmadığım nokta, “NPM paketlerini körü körüne kurmamak iyi olur ve paketin şüpheli olup olmadığını gösteren sinyaller vardır. Bu paketlerde yalnızca package.json ile index.js veya main.js adlı iki dosya bulunuyor; bu da normal olup olmadığını anlamaya yarayan işaretlerden biridir” kısmı
    Bu, üst düzey paketler için bir ölçüde geçerli olabilir ama geçişli bağımlılıkların tamamını incelemek neredeyse imkânsız
    400 bağımlılığı olan bir paket alıyorsan, bunun yüzey alanının %10’unu bile nasıl düzgün kontrol edeceksin? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • Böyle durumlarda uygulanacak güvenlik tavsiyesi farklıdır. 400 bağımlılığı olan bir paketi hiç alma demektir
    • Bu noktada SELinux’un büyük resmi doğruydu. Dosyaları hassasiyet verisine göre önceden sınıflandırıp buna göre erişimi engellersen, bu sorunu — örneğin bir NPM kurulumunun id_rsa dosyasına erişememesi meselesini — gayet iyi çözersin
    • Bir React carousel bileşeni nasıl oluyor da 400’den fazla bağımlılığa sahip oluyor…
    • Bizim şirkette Snyk diye harika bir güvenlik aracı kullanıyoruz. Kesin bakın /s

  • Snyk, açık anahtarları değiştirmeden önce duyuru yapmadan doğrudan değiştiren bir şirket aynı zamanda: https://github.com/snyk/cli/pull/5649
    Proje GitHub dışı bir kod barındırma hizmetine taşınırsa “abandoned” olarak işaretliyorlar ve npm/PyPI’de yeni sürümler çıksa bile proje terk edilmiş olarak kalıyor
    Bence yetkinlikleri itibarları kadar yüksek değil
    Ayrıca bir Snyk satış temsilcisi beni e-postayla aşağıladı. Görünüşe göre ürünlerini satın almakla ilgilenmemen, yalnızca güvenlik açığı dolu yazılım kullanabilen beceriksiz bir geliştirici olduğun anlamına geliyor

    • Geliştirmesi bitmiş ve artık yalnızca asgari bakım gerektiren kütüphaneleri de eksi puanlıyorlar
      Sigorta şirketleri güvenlik kontrol listesi maddeleri doldurulsun diye baskı yaptığı için şirketlerin satın aldığı, tamamen tersine dönmüş bir yazılım gibi görünüyor
    • O “abandoned” etiketi özellikle üzücü. Ben de son zamanlarda GitHub’dan uzaklaşmaya çalışıyorum; GitHub’ın fazla kontrol sahibi olduğu hissine kapılıyorum
      Codeberg ilginç görünüyor; bakım yükünü kaldırabiliyorsan Forejo gibi self-hosted seçenekler de iyi duruyor
    • GitHub dışı bir depoya taşındı diye “abandoned” sayıp npm/PyPI’de yeni sürümler çıkmasına rağmen öyle bırakmaları, iyi bir ekibin işareti gerçekten /s
      Snyk hakkında kibirli oldukları dışında pek bir şey duymamıştım; oldukça ilginç bir bakış açısı
    • O e-postanın gövdelerini uygun şekilde sansürlenmiş hâliyle paylaşabilirsin herhâlde?

  • Daha fazla bağlam yoksa, bu Snyk açısından da iyi görünmüyor. Ya bir çalışan NPM ile kendi hizmetlerini gerçek ortamda test etti ya da Cursor’a yönelik meşru bir denetim yürütürken herkese açık kaynakları kullanmamak için gerekli kontrol ve prosedürler eksikti

    • Neden olmasın? NPM, özel depodaki bir paketle aynı ada sahip herkese açık bir paket varsa garip davranıyor ve bazı durumlarda herkese açık paketi çekiyor. Sanırım buna package squatting benzeri bir ad veriliyor. Belki de değerlendirme sırasında bunun mümkün olduğunu göstermişlerdi. Bence ortada ne zarar ne de sorun var

  • Snyk testine bir white hat denetimi gibi görünüyor. oastify.com, Burp Collaborator’ın varsayılan sunucusu olduğu için tespit edilmiş gibi duruyor
    Test için özel bir npm deposu kullanılmalıydı ve yerelde üzerine yazmak zor değil. Kendi Collaborator sunucuları da kullanılmalıydı

    • Verileri aktif olarak dışarı çıkardıkları için bu white hat değil. Sadece çalıştığını kanıtlamak isteselerdi, console.log yazdırmak, npm install işlemini başarısız kılmak ya da payload’u dışarı çıkarmayan bir yöntem kullanmak yeterli olurdu

  • Görünüşe göre NPM, güvenlik sektöründe iş yaratıyor. Düzeltilemeyecek kadar dağınık bir karmaşa ve umarım JSR gibi rakipler kurumlar üzerinde yeterli baskıyı kurar

    • Bu sadece NPM’in sorunu değil, genel olarak üçüncü taraf kütüphanelere güven sorunu. Çok daha nadir olsa da NuGet gibi platformlarda da exploit’ler çıkıyor. JSR’de de olacaktır. Değiştirilemezlik sayesinde daha güvenli ama kötü amaçlı paket ortaya çıkmadan önce indirilmesini engellemiyor
      Aslında DORA ve NSIS gibi düzenlemelerin giderek daha fazla üçüncü taraf paket denetimi gerektirmesi daha olası. Bu, kritik sektörlerde yazılım geliştirme biçimini değiştirmeye zorlayacak. Ayrıca LLM çağında dış paket kullanımının çok daha azalacağını düşünüyorum. OpenAPI tanımı üretmek gibi işler için neden dış paket getiresiniz? Bir LLM, bir iki saatlik kurulumla ihtiyaç duyduğunuz CLI script’ini yazabilir. Aynı şekilde, kodun sıkıcı kısımlarını doğrudan otomatik üretmek için LLM kullanmak zorunda da değilsiniz; bunun yerine bu işleri yapan CLI araçları yazdırabilirsiniz. Böylece dış etkenlere bağımlı olmazsınız ve bu CLI araçlarının berbat kovboy kodu olma ihtimali neredeyse garantidir, ama çıktıyı aracı törpüleyerek istediğiniz şekle sokabilirsiniz
      Go gibi gerekli şeyleri standart pakete dahil eden dillere bakınca, sadece standart kütüphaneyle çok kolay şekilde pek çok şey yapabildiğiniz bir dünya görüyorsunuz

  • Konudan biraz sapıyor ama, Snyk’in kendi araç ve hizmetleri için düzgün bir SBOM alan oldu mu? Bunu sormamın nedeni, şirketimize SBOM oluşturan bir çözüm satmaya çalışmaları

    • Snyk, İsrail ordusunun Unit 8200 biriminden çıkan kişiler tarafından kurulmuş bir şirket
      Para verseler bile kuracağımı sanmıyorum. Unit 8200 sürekli kurucu çıkarıp fon sağladığı için, tıpkı NSA gibi daha en baştan kapıdan içeri ayağını sokmuş bir yapı hissi veriyor
    • Syft ile daha iyi sonuçlar aldım
    • Benim deneyimimde çok fazla false positive vardı

  • Snyk Research Labs, yaygın yazılım paketlerini test edip araştırarak topluluğa düzenli katkı sağlıyor. Cursor üzerine yapılan bu araştırma kötü niyetli değildi ve paketin içinde Snyk Research Labs ile araştırmacının iletişim bilgileri bulunuyordu. Bazı VS Code uzantılarındaki dependency confusion durumunu çok spesifik olarak inceliyorduk ve söz konusu paketler geliştiricilerin doğrudan kurması gereken türden değildi
    Snyk, sorumlu ifşa politikasını izliyor. Bu paketi kimse çekmedi ama biri çekmiş olsaydı hemen gerekli takibi yapardık

    • Saldırıyı kamusal alana saçıp hedefe isabet etmesini ummak, sorumlu davranışın tam tersidir. Tek “iyi” yanı, başka biri başıboş kurşuna hedef olmadan sahada yakalanmış olması
      Buna verdikleri yanıt, vurulan kişinin cenazesine özür mektubu göndereceklerini söylemeye benziyor. “İyi niyetli” olsa bile kimlik bilgileri ihlal edilmişse, o kişi zaten ihlal edilmiştir ve kötü niyetli bir saldırgana maruz kalmış gibi aynı şekilde müdahale etmek gerekir
      Bu, kötü niyetten ayırt etmenin zor olduğu kadar ona yakın
      Ayrıca, bir Snyk paydaşının şu anda Cursor’a rakip bir ürün çıkarmaya çalıştığını da herkes hatırlamalı. Bu da iyi niyet varsaymayı çok daha zorlaştırıyor
    • Güzel. Peki neden kullanıcının ortam değişkenlerini eve gönderdiniz? Açığı doğrulamak için gerçek ortam değerleri yerine sahte değerleri göndermek de yeterliydi
    • En iyi ihtimalle bu gray hat. Niyet iyi olabilir ama bu ekip, izin almadan verilere erişip sızdıran yazılım geliştirdi ve dağıttı; bu da son derece yasa dışı. Böyle bir şeyi kamuya açık forumda yazmadan önce hukuk ekibiyle görüşmek iyi olurdu
    • Kulağa makul geliyor ama neden POST ile ortam değişkenlerini geri gönderdiniz? Tamamen iyi niyetli olsanız bile, rastgele bir paketin benim env çıktımı almasını istemem
    • Bunun gerçekten Snyk CTO’su olması ve resmi yanıtın insanlar tarafından görülmesi gerektiği için upvote ederim, ama bu gerçekten çok sorumsuzca geliyor. Masum geliştiricilerin kimlik bilgilerini fiilen çalmadan da bir proof of concept yapılabilirdi
      Üstelik Cursor’a rakip bir ürünle çıkar çatışması varken çok daha dikkatli olmaları gerekirdi. Hem karar alma süreci hem de verdikleri yanıt berbattı