Snyk के सुरक्षा शोधकर्ता ने Cursor.com को निशाना बनाकर दुर्भावनापूर्ण NPM पैकेज प्रकाशित किए

 (sourcecodered.com)
1 पॉइंट द्वारा GN⁺ 2025-01-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • npm पर अपलोड किए गए कई पैकेजों में ऐसी इंस्टॉलेशन स्क्रिप्ट शामिल थी जो Cursor.com को निशाना बनाती हुई लगती है, और इंस्टॉल होने पर सिस्टम जानकारी को बाहरी वेब सेवा पर भेजती है
  • इन्हें प्रकाशित करने वाला npm उपयोगकर्ता sn4k-s3c था, और उसने cursor-retreival, cursor-always-local, cursor-shadow-workspace जैसे नामों का इस्तेमाल किया जो Cursor के आंतरिक पैकेजों की याद दिलाते हैं
  • पैकेज द्वारा प्राप्त env आउटपुट में AWS keys, npm tokens, GitHub credentials जैसे संवेदनशील environment variables शामिल हो सकते हैं, जिससे नुकसान का दायरा बढ़ सकता है
  • OpenSSF package analysis scanner ने पैकेजों को दुर्भावनापूर्ण के रूप में पहचाना, और OSV ने MAL-2025-27, MAL-2025-28, MAL-2025-29 नाम से 3 advisories बनाई
  • npm metadata में Snyk Security Labs की snyk.io email publisher के रूप में दिखाई दी, और बाद में Snyk शोधकर्ता ने पैकेज हटा दिए जिसके बाद Snyk ने ब्लॉग पोस्ट के जरिए प्रतिक्रिया दी

Cursor को निशाना बनाते दिखने वाले npm पैकेज

  • SourceCodeRed द्वारा दुर्भावनापूर्ण पैकेजों का पता लगाने की प्रक्रिया में npm पर अपलोड किए गए कई पैकेज मिले
  • पैकेज नाम Cursor से जुड़े आंतरिक पैकेजों की याद दिलाने वाले थे
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • publisher के रूप में npm उपयोगकर्ता sn4k-s3c दिखा
  • बताया गया कि पैकेजों की सूची https://www.npmjs.com/~sn4k-s3c पर देखी जा सकती है

इंस्टॉल करते समय होने वाली गतिविधि

  • पैकेज इंस्टॉल करने पर यह सिस्टम डेटा इकट्ठा करके हमलावर के नियंत्रण वाली वेब सेवा को भेजता है
  • स्क्रीनशॉट के अनुसार पैकेज env कमांड का आउटपुट लेता है
  • env आउटपुट में सिस्टम सेटिंग्स के साथ संवेदनशील environment variables भी शामिल हो सकते हैं
    • AWS keys
    • npm tokens
    • GitHub credentials
    • अन्य संवेदनशील environment variables
  • नतीजतन, सिर्फ इंस्टॉल करने से ही लोकल environment की जानकारी बाहरी रूप से लीक हो सकती है

dependency confusion की संभावना और डिटेक्शन परिणाम

  • इस तरह के पैकेज अक्सर किसी खास कंपनी को निशाना बनाने वाले dependency confusion हमलों में दिखाई देते हैं
  • Cursor.com का bug bounty program है या नहीं, या इसकी विशिष्ट पृष्ठभूमि क्या थी, यह पुष्टि नहीं हुई
  • SourceCodeRed को संदेह है कि Cursor के पास cursor-always-local, cursor-retrieval, cursor-shadow-workspace जैसे private npm पैकेज हो सकते हैं
  • हमलावर को शायद उम्मीद थी कि Cursor का कोई कर्मचारी गलती से public पैकेज इंस्टॉल कर लेगा और डेटा भेज देगा
  • OpenSSF package analysis scanner ने इन पैकेजों को दुर्भावनापूर्ण के रूप में पहचाना, और OSV ने 3 malware advisories बनाई

publisher metadata

  • npm package metadata में publisher ने Snyk Security Labs टीम का snyk.io email address इस्तेमाल किया
  • कहा गया कि publisher email metadata ऐसा हिस्सा है जिसे spoof नहीं किया जा सकता
  • author फ़ील्ड में Snyk कर्मचारी का विशिष्ट उल्लेख है
  • author फ़ील्ड spoof की जा सकती है, लेकिन publisher verified Snyk email होने के कारण यह अनुमान लगाया गया कि यह वास्तव में Snyk से आया था

उपयोगकर्ता प्रतिक्रिया और बाद के अपडेट

  • SourceCodeRed ने npm को सूचित किया, लेकिन उस समय तक पैकेजों को अभी भी दुर्भावनापूर्ण के रूप में चिह्नित नहीं किया गया था
  • कई software supply chain security tools तभी ब्लॉक कर पाते हैं जब उन्हें पता हो कि कोई पैकेज दुर्भावनापूर्ण है
  • बिना सोचे-समझे npm पैकेज इंस्टॉल न करने की सलाह दी गई
  • इन पैकेजों में केवल package.json और index.js या main.js ये दो फ़ाइलें थीं, जिसे एक संदिग्ध संकेत माना जा सकता है
  • 15 जनवरी 2025 के अपडेट के अनुसार, Snyk शोधकर्ता ने ब्लॉग प्रकाशित होने के अगले दिन Cursor-संबंधित पैकेज हटा दिए
  • 14 जनवरी 2025 को 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 के अंदर एक private NPM registry है जिसमें ये पैकेज मौजूद हैं, और NPM के काम करने के तरीके की वजह से attacker के लिए public registry से वही पैकेज उठवाने का झांसा देना आसान हो सकता है
    शायद Snyk के किसी कर्मचारी ने पाया या शक किया कि Cursor build का कुछ हिस्सा इस तरह गलत तरीके से configured है, और proof of concept के तौर पर पैकेज publish कर दिए। पैकेज description “for Cursor” देखकर मुझे लगा था कि उन्हें इसी काम के लिए hire किया गया होगा
    अगर ऐसा है, तो इसमें बहुत बड़ी बात नहीं है; और अगर मुख्य मुद्दा private registry को bypass करने वाली misconfiguration दिखाना था, तो security researcher proof of concept में private NPM registry का इस्तेमाल कर ही नहीं सकता था
    खासकर कई proxy latest package version ज्यादा होने पर private registry के बजाय public registry को चुन लेते हैं: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • मैं Cursor developer हूं। यह reasonable अनुमान है, लेकिन हकीकत से थोड़ा अलग है। Snyk packages बस उन extensions के नाम हैं जिन्हें हम bundle करते हैं, और हम उन्हें package नहीं करते या किसी भी registry पर upload नहीं करते
      हम इसे VS Code की तरह ही handle करते हैं: https://github.com/microsoft/vscode/tree/main/extensions
      हमने Snyk को hire नहीं किया था, और यह देखने के बाद उनसे संपर्क किया तो उन्होंने माफी मांगी। वे असल में क्या करने की कोशिश कर रहे थे, इसकी पुष्टि हमें नहीं मिली, लेकिन यह explanation plausible है कि किसी ने dependency confusion vulnerability का शक किया था। हालांकि public NPM से सच में environment variables भेजवाना मुझे काफी irresponsible लगता है
    • proof of concept installed host की जानकारी और सभी environment variables बाहर भेजे बिना भी किया जा सकता था। यह सीमा पार करने जैसा लगता है
    • किसी को मेरे पूरे environment, यानी env command के output तक पूरा access देना, ज्यादातर लोगों के लिए बड़ी समस्या होगा
    • मैं Snyk में DevRel & SecRel संभालता हूं। अफवाहों को clear करने के लिए अभी-अभी एक पोस्ट publish की है, और इसमें स्थिति के बारे में काफी गहरी जानकारी है: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • क्या यह NPM में fix नहीं हो जाना चाहिए था? मुझे याद है कि PortSwigger के एक researcher ने पहले इसी पर talk दिया था, और याद है कि Apple, Microsoft, Meta जैसी लगभग सभी FAANG कंपनियां उस समय vulnerable थीं

  • दिलचस्प बात यह है कि Snyk co-founder ने Cursor की competitor कंपनी शुरू की है
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    उम्मीद है कोई foul play नहीं हुआ होगा

    • उनके साथ मेरी हर interaction बहुत negative रही है, इसलिए मुझे लगता है कि foul play होने की संभावना काफी ज्यादा है

  • अब लगता है कि सारा development सच में virtual machine के अंदर ही करना पड़ेगा। हर project के लिए एक VM। ऐसी बहुत-सी चालाक तरकीबें हैं जिनसे मैं अनजाने में गलती करके security बिगाड़ सकता हूँ। तसल्ली बस यही है कि मैं कोई बड़ा नाम नहीं हूँ, इसलिए चुराने लायक secrets या संपत्ति नहीं है
    IDE, plugins, development utilities, language libraries, operating system packages वगैरह—हम बहुत ज्यादा code पर आंख मूंदकर भरोसा कर रहे हैं

    • Docker containers की वजह से Vagrant की popularity शायद कम हो गई है, लेकिन development environment बनाने के तरीके के रूप में मुझे अब भी Vagrant सबसे अच्छा लगता है
      कुछ साल पहले जहाँ काम करता था, वहाँ laptops पर web browser और development tools ban थे। Browser चाहिए तो Citrix से इस्तेमाल करना पड़ता था, और coding करनी हो तो VDI इस्तेमाल करना पड़ता था या tools को VM के अंदर चलाना पड़ता था
      उस समय यह तरीका लगभग पागलपन जैसा लगता था, लेकिन अब धीरे-धीरे समझ आने लगा है
    • असली समस्या VM की video performance है। अब भी बस ठीक नहीं है। VM में Cinnamon चलाने पर GL acceleration को ठीक से काम करवाना लगभग असंभव है
      NVIDIA virtualization GPU features को enterprise cards के पीछे lock कर देता है, इसलिए बेअसर command translation पर निर्भर रहना पड़ता है
      VM का बाकी overhead लगभग सब सहन हो जाता है, लेकिन अटकता और response न देने वाला GUI ergonomics पर उम्मीद से ज्यादा बुरा असर डालता है और अजीब तरह से बाकी performance को भी नीचे खींच देता है
      अगर सिर्फ Linux पर Linux virtualize करने के मामले में भी यह समस्या हल हो जाए, तो सब कुछ virtualize करने का विकल्प कहीं ज्यादा practical हो जाएगा
    • भरोसे का इस हद तक टूटना डरावना है, और operating system में हर महीने GB-level updates आना भी भरोसा नहीं दिलाता। हर project के लिए stable isolated VM रखने का विचार अच्छा लगता है। क्या इसके लिए कोई standard open source tool है?
      खास तौर पर, मैं पुराने Mac से M1 के Asahi Linux पर Go और Zig development environment शिफ्ट कर रहा हूँ, लेकिन TrueCrypt और Little Snitch के alternatives ढूँढने से ही उलझा हुआ हूँ। क्या ऐसे VM tools encrypted VM और firewall rules support करते हैं? यहाँ Vagrant का जिक्र हुआ है और network isolation शायद कुछ हद तक हल हो जाए, लेकिन इसके अलावा क्या recommend किया जा सकता है?
    • मैं समझता हूँ यह कैसा लगता है, और मैंने भी इस पर कई बार सोचा है। अभी मैं ऐसा नहीं करना चाहता, और मुख्य वजह मेहनत नहीं है
      VM मुझे protect कर सकता है, लेकिन मेरे बनाए software के users को protect नहीं करता। जिस product को छूने के लिए मुझे protective suit पहनना पड़ता है, उसे customers को भेजकर मैं कैसे उम्मीद कर सकता हूँ कि वे बिना protection के उसे safe तरीके से use करेंगे?
      मुझे ऐसा environment नहीं चाहिए
      अभी का solution dependencies को बेहद सख्ती से चुनना है। और खास तौर पर, मेरा मानना है कि project या company पर नहीं, सिर्फ लोगों पर भरोसा करना चाहिए। यह आसान नहीं है, लेकिन फिलहाल इससे बेहतर alternative नहीं दिखता
    • मैं Linux पर कई projects develop करता हूँ। मुख्य चिंता यह रहती है कि tools, build scripts और tests sensitive data पढ़ सकते हैं या गलती से data destroy कर सकते हैं, इसलिए project पर काम करते समय file access सीमित करने के लिए Linux namespaces और bubblewrap इस्तेमाल करता हूँ
      हर project के लिए simple dot file में file system binds लिख देता हूँ, और काम के दौरान नया terminal खोलने पर उस dot file के आधार पर automatic isolation हो जाता है। Cognitive burden बहुत कम है और integration लगभग seamless है। लगता है बहुत से developers के पास ऐसे ही scripts होंगे। पहले मैंने ऐसा project ढूँढा था लेकिन नहीं मिला; समझ नहीं आया कि यह इतना simple है कि project बनाने लायक कुछ नहीं, या बाकी लोग इसे किस नाम से बुलाते हैं। कोई reference मिल जाए तो अच्छा होगा
      Network access को restrict नहीं करता। सारे traffic को log करने और automatically man-in-the-middle proxy set करने के experiments किए थे, लेकिन ordinary user की तरह इस्तेमाल करने के लिए यह पर्याप्त convenient नहीं था। बेशक kernel attack surface अब भी बचा रहता है। हालांकि मुख्य चिंता files के पढ़े जाने या destroy होने की है

  • लेख में जिस हिस्से से मैं सहमत नहीं हूँ, वह यह है: “NPM packages को blindly install न करना बेहतर है, और package suspicious है या नहीं यह देखने के संकेत होते हैं। इन packages में सिर्फ दो files हैं—package.json और index.js या main.js—इसलिए यह normal है या नहीं तय करने वाले flags में से एक है”
    यह top-level packages पर कुछ हद तक काम कर सकता है, लेकिन transitive dependencies तक सबकी review करना लगभग असंभव है
    अगर आप 400 dependencies वाला package ला रहे हैं, तो उस surface area के 10% को भी ठीक से कैसे check करेंगे? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • ऐसे समय लागू होने वाली security advice अलग है: 400 dependencies वाला package मत लाओ
    • इस मामले में SELinux की बड़ी दिशा सही थी। Files को पहले से sensitivity data के हिसाब से classify कर दिया जाए और उसके अनुसार access deny किया जाए, तो यह समस्या—जैसे NPM install को id_rsa access न करने देना—काफी हद तक हल हो जाती है
    • एक React carousel component के पास आखिर 400 dependencies से ज्यादा कैसे हो सकती हैं…
    • हमारी company में Snyk नाम का शानदार security tool इस्तेमाल होता है। जरूर check करें /s

  • Snyk वह company भी है जो public key को rotate नहीं करती, बस बिना notice बदल देती है: https://github.com/snyk/cli/pull/5649
    अगर project GitHub के अलावा किसी दूसरे repository hosting पर चला जाए तो उसे “abandoned” mark कर देती है, और npm/PyPI पर नई release आने के बाद भी वह project abandoned ही रहता है
    मुझे नहीं लगता कि उनकी क्षमता उनकी reputation जितनी बड़ी है
    और Snyk के sales rep ने email में मेरा अपमान किया था। शायद product खरीदने में interest न होना मतलब मैं ऐसा incompetent developer हूँ जो सिर्फ vulnerabilities से भरा software ही use कर सकता है

    • जिन libraries का development पूरा हो चुका है और जिन्हें बस minimal maintenance चाहिए, उन्हें भी penalty मिलती है
      यह पूरी तरह उल्टा software लगता है, जिसे companies इसलिए खरीदती हैं क्योंकि insurer security checklist के items भरने को कहता है
    • वह “abandoned” labeling खास तौर पर दुखद है। मैं भी हाल में GitHub से बाहर निकलने की कोशिश कर रहा हूँ, और लगता है GitHub के पास बहुत ज्यादा control है
      Codeberg interesting लगता है, और अगर maintenance संभाल सकें तो Forejo जैसे self-hosting options भी अच्छे लगते हैं
    • GitHub के अलावा किसी दूसरे repository पर move किया तो “abandoned” mark करना, और npm/PyPI पर नई release आने के बाद भी वही रखना—अच्छी team का संकेत है /s
      Snyk के बारे में मैंने ज्यादा नहीं सुना, सिवाय इसके कि उनमें ego काफी है; यह perspective काफी interesting है
    • उस email का body उचित redaction के साथ दे सकते हो न?

  • अगर और संदर्भ न हो, तो Snyk के लिए भी यह अच्छा नहीं दिखता। इसका मतलब है कि किसी कर्मचारी ने NPM के जरिए अपनी ही सेवा का real-environment test किया, या Cursor का वैध audit करते समय public resources का इस्तेमाल न हो, इसके लिए जरूरी controls और procedures की कमी थी

    • यह क्यों गलत है? अगर NPM में private repository के package जैसे ही नाम का कोई public package हो, तो यह अजीब तरह से behave करता है, और कुछ मामलों में public package उठा लेता है। मेरी जानकारी में इसे package preemption जैसा कुछ कहा जाता है। हो सकता है evaluation के दौरान सिर्फ यह दिखाया गया हो कि यह संभव है। मेरे हिसाब से कोई नुकसान नहीं हुआ और कोई समस्या भी नहीं है

  • यह Snyk test की white-hat audit जैसा दिखता है। oastify.com Burp Collaborator का default server है, इसलिए शायद detect हुआ
    test में private npm repository इस्तेमाल करनी चाहिए थी, और local में override करना मुश्किल नहीं है। अपना Collaborator server भी इस्तेमाल करना चाहिए था

    • डेटा actively exfiltrate किया गया था, इसलिए यह white-hat नहीं है। अगर मकसद सिर्फ यह साबित करना था कि यह काम करता है, तो console.log करना, npm install fail कराना, या payload extract न करने वाला तरीका भी काफी था

  • ऐसा लगता है NPM security industry में jobs पैदा कर रहा है। यह एक ऐसा messy सिस्टम है जिसे ठीक नहीं किया जा सकता, और उम्मीद है कि JSR जैसे competitors संगठन पर पर्याप्त दबाव डालेंगे

    • यह सिर्फ NPM की समस्या नहीं, बल्कि कुल मिलाकर third-party library trust की समस्या है। बहुत कम सही, लेकिन NuGet जैसे platforms पर भी exploits आते हैं। JSR में भी आएंगे। immutability की वजह से security बेहतर है, लेकिन यह malicious package के उजागर होने से पहले उसे download करने से नहीं रोकती
      उल्टे DORA और NSIS जैसे regulations के चलते third-party package audits की मांग बढ़ने की संभावना ज्यादा है। यह critical industries में development practices बदलने के लिए मजबूर करेगा। साथ ही, LLM के दौर में बाहरी packages का इस्तेमाल काफी कम हो जाएगा, ऐसा मुझे लगता है। OpenAPI spec generation जैसी चीजों के लिए external package लाने की जरूरत ही क्या है? LLM एक-दो घंटे की setup में जरूरी CLI script लिख सकता है। इसी तरह, code के boring हिस्सों को सीधे auto-generate कराने के लिए LLM इस्तेमाल न भी करें, तो उससे ऐसा CLI tool बनवाया जा सकता है जो यह काम करे। तब बाहरी factors पर निर्भर नहीं रहना पड़ेगा, और उन CLI tools के messy cowboy code होने की संभावना लगभग तय है, लेकिन output को tool refine करके मनचाहे रूप में बनाया जा सकता है
      Go जैसी languages को देखें, जो standard packages में जरूरी चीजें डालती हैं, तो एक ऐसी दुनिया दिखती है जहां standard library भर से बहुत सारे काम बेहद आसानी से किए जा सकते हैं

  • थोड़ा off-topic है, लेकिन क्या किसी ने Snyk के अपने tools और services के लिए proper SBOM लिया है? पूछ इसलिए रहा हूं क्योंकि वे हमारी company को SBOM बनाने वाला solution बेचने की कोशिश कर रहे थे

    • Snyk ऐसी company है जिसे Israeli military की Unit 8200 के पूर्व लोगों ने बनाया है
      पैसे दें तब भी शायद मैं इसे install नहीं करूंगा। Unit 8200 लगातार founders निकालती और fund करती रहती है, जिससे यह NSA की तरह पहले से ही दरवाजे के अंदर पैर जमा लेने वाली structure लगती है
    • Syft से मुझे बेहतर results मिले
    • मेरे अनुभव में false positives बहुत थे

  • Snyk Research Labs आम software packages की testing और research के जरिए community में नियमित योगदान देता है। यह Cursor research malicious intent से नहीं की गई थी, और packages में Snyk Research Labs और researcher के contact details शामिल थे। हम कुछ VS Code extensions में dependency confusion को बहुत specific तौर पर देख रहे थे, और वे packages ऐसे नहीं थे जिन्हें developers को खुद install करना था
    Snyk responsible disclosure policy का पालन करता है। किसी ने भी यह package नहीं उठाया, लेकिन अगर कोई उठाता तो हम तुरंत follow-up करते

    • public space में attack छोड़कर target पर लगने की उम्मीद करना responsible behavior का ठीक उल्टा है। इसमें एकमात्र “अच्छी” बात यह है कि किसी और के collateral damage बनने से पहले यह मौके पर पकड़ा गया
      response ऐसा सुनाई देता है जैसे प्रभावित व्यक्ति के funeral पर apology letter भेजने की बात हो। “अच्छे इरादे” हों तब भी अगर credentials compromise होते हैं, तो वह व्यक्ति पहले ही compromised हो चुका होता है, और उसे malicious attacker से compromise होने जैसी ही response देनी पड़ती है
      यह maliciousness से फर्क महसूस कर पाना मुश्किल हो, इतना करीब है
      साथ ही, सभी को यह भी याद रखना चाहिए कि Snyk का एक stakeholder अभी Cursor का competing product launch करने की कोशिश कर रहा है। good faith assume करना कहीं ज्यादा मुश्किल हो जाता है
    • ठीक है। लेकिन फिर user के environment variables घर क्यों भेजे गए? vulnerability confirm करने के लिए actual environment values की जगह dummy values भेजना ही काफी था
    • best case में भी यह gray-hat है। इरादा अच्छा हो सकता था, लेकिन इस team ने बिना अनुमति data access और exfiltrate करने वाला software बनाया और distribute किया, और यह बहुत illegal है। public forum में ऐसी post डालने से पहले legal team से consult करना बेहतर होगा
    • सुनने में plausible है, लेकिन environment variables को POST करके वापस भेजने की क्या वजह थी? पूरी तरह अच्छे इरादे हों तब भी, मैं नहीं चाहता कि कोई arbitrary package मेरे env output को अपने पास रखे
    • असल में यह Snyk CTO हो सकते हैं और official response लोगों को दिखना चाहिए, इसलिए upvote कर रहा हूं, लेकिन यह सचमुच बेहद irresponsible लगता है। निर्दोष developers के credentials सच में चुराए बिना भी proof of concept किया जा सकता था
      ऊपर से Cursor के competing product के साथ conflict of interest है, इसलिए और ज्यादा सावधानी बरतनी चाहिए थी। decision-making भी खराब और response भी खराब