NPM में 86,000 से अधिक बार डाउनलोड किए गए malicious packages का बड़े पैमाने पर प्रसार

• यह पुष्टि हुई है कि NPM repository में credentials चुराने के लिए 100 से अधिक malicious packages अगस्त के बाद बिना detect हुए upload किए गए और उन्हें कुल 86,000 से अधिक बार डाउनलोड किया गया
• security company Koi ने रिपोर्ट किया कि 'PhantomRaven' नाम का attack campaign, NPM के Remote Dynamic Dependencies(RDD) feature का दुरुपयोग करके 126 malicious packages फैलाने में इस्तेमाल किया गया
• RDD ऐसी संरचना है जो package को untrusted domains से dependency code dynamically डाउनलोड करने देती है, इसलिए इसे static analysis tools detect नहीं कर पाते
• attackers ने इस feature का उपयोग HTTP connection के जरिए malicious code डाउनलोड करने के लिए किया, लेकिन package metadata में यह “0 Dependencies” के रूप में दिखा, जिससे developers और security scanners इसे पहचान नहीं पाए
• यह structural weakness NPM ecosystem की security management limits और automatic installation mechanism के जोखिम को उजागर करती है

---

NPM repository में malicious packages का प्रसार

• attackers ने NPM code repository की structural weakness का फायदा उठाकर अगस्त के बाद credentials चुराने वाले 100 से अधिक packages upload किए
  • अधिकांश packages बिना detect हुए वितरित हुए, और इनका cumulative download count 86,000 से अधिक रहा
• security company Koi ने इस attack को PhantomRaven campaign नाम दिया और विश्लेषण किया कि NPM के एक specific feature का दुरुपयोग किया गया
  • Koi के अनुसार, 126 malicious packages में से लगभग 80 article लिखे जाने के समय तक भी NPM पर मौजूद थे

Remote Dynamic Dependencies(RDD) की कमजोर संरचना

• RDD एक ऐसा feature है जो package को external website से dependency code dynamically डाउनलोड करने की अनुमति देता है
  • आम तौर पर dependencies, NPM की trusted infrastructure से डाउनलोड होती हैं, लेकिन RDD HTTP जैसे unencrypted connections के जरिए डाउनलोड की भी अनुमति देता है
• PhantomRaven attackers ने इस feature का उपयोग code को malicious URL (उदाहरण: http://packages.storeartifact.com/npm/unused-imports) से डाउनलोड कराने के लिए configure किया
  • ऐसी dependencies developers और security scanners को दिखाई नहीं देतीं, और package information में “0 Dependencies” के रूप में दिखती हैं
• NPM के automatic installation feature के कारण ऐसे 'अदृश्य' dependency code अपने आप execute हो जाते हैं

security tools की detection limitations

• Koi के Oren Yomtov ने कहा, “PhantomRaven मौजूदा security tools के blind spot का बेहद परिष्कृत तरीके से दुरुपयोग करने का उदाहरण है”
  • RDD को static analysis tools detect नहीं कर पाते
• इसके कारण attackers security validation को bypass करते हुए malicious code वितरित कर सके

अतिरिक्त कमजोर कारक

• Koi ने बताया कि RDD से डाउनलोड की गई dependencies हर installation पर attacker server से दोबारा डाउनलोड होती हैं
  • cache या version management न होने के कारण, एक ही package में भी installation के समय के अनुसार अलग malicious code inject होने की संभावना रहती है
• ऐसी dynamic download संरचना package integrity verification को कठिन बनाती है

NPM की संरचना और पृष्ठभूमि

• NPM JavaScript के लिए package manager है, जिसे GitHub की subsidiary npm, Inc. manage करती है
  • यह Node.js का default package manager है और command-line client तथा npm registry से मिलकर बना है
  • registry में public और paid private packages store होते हैं, और website के जरिए उन्हें खोजा जा सकता है
• इस घटना को ऐसे उदाहरण के रूप में देखा जा रहा है जो दिखाती है कि NPM की automatic dependency management संरचना हमलों में दुरुपयोग की जा सकती है

अन्य उल्लेख

• लेख के अंत में अनावश्यक JavaScript execution को block करने की आवश्यकता का उल्लेख है
  • हालांकि, यह भी रेखांकित किया गया कि इस बार ज़रूरी JavaScript code तक का दुरुपयोग किया गया

[developerjhp]

मैंने एक रीयल-टाइम स्कैनर स्क्रिप्ट बनाई है.

संदिग्ध repository के path में
npx sha1-hulud-scanner
दर्ज करें.

सोर्स कोड : https://github.com/developerjhp/sha1-hulud-scanner

[GN⁺]

Hacker News राय

• आजकल मैं npm कमांड को Docker container के अंदर चलाने के लिए alias सेट करके रखता हूँ
  ऐसा करने से मेरे environment variables expose नहीं होते, current directory के बाहर की files तक access नहीं मिलता, और .bashrc जैसी config files तक भी पहुँच नहीं हो पाती
  संदर्भ: Run tools inside Docker

  • यह कुछ ज़्यादा ही sandboxing लगता है। वैसे भी npm ऐसा arbitrary code डाउनलोड करता है जो तुरंत चल सकता है
    इसकी जगह pnpm बेहतर है। यह default रूप से lifecycle scripts नहीं चलाता, और जिन scripts को allow करना हो उन्हें whitelist किया जा सकता है
  • post-install scripts को दानवीकरण करना सिर्फ झूठा सुरक्षा-भ्रम देता है
    अगर सच में सुरक्षा चाहिए, तो सिर्फ install नहीं बल्कि पूरे execution को sandbox के अंदर चलाना होगा
    अभी की तरह सिर्फ post-install रोकना आधा-अधूरा उपाय है। supply chain attacks लगातार ज़्यादा खतरनाक होते जा रहे हैं
  • attack vectors बहुत ज़्यादा हैं। अगर किसी की नीयत खराब हो, तो किसी लोकप्रिय plugin या LSP के नाम का typosquatting करके editor शुरू होते ही code अपने-आप चलवाया जा सकता है
    अगर neovim या vscode संक्रमित हो जाए, तो user privileges के साथ ही काफी खतरनाक काम किए जा सकते हैं
  • मैं sandbox-run इस्तेमाल करता हूँ
    साधारण alias node/npm पर तो काम करता है, लेकिन दूसरे programs पर लागू करना कठिन है। क्योंकि container में ज़रूरी resources mount करने पड़ते हैं
  • लेकिन अंत में क्या आप फिर भी malicious package डाउनलोड नहीं कर सकते? dependency खुद भी संक्रमित हो सकती है

• मैं लंबे समय से सोचता रहा हूँ कि लोग इतनी आसानी से npm को सिस्टम पर क्यों चलाते हैं
  make जैसे reproducible build के आदी नज़रिए से देखें, तो npm का हर बार कुछ अलग डाउनलोड करना और अलग परिणाम देना चौंकाने वाला था
  CSS generation तक को npm dependencies से बाँध देना अजीब लगा। इसलिए मैंने Docker के अंदर पूरे npm environment को freeze करने की कोशिश की, लेकिन अंत में यह हारी हुई लड़ाई जैसा लगा

  • आजकल लगभग हर package manager इसी तरह काम करता है। maven, nuget, pip, npm सब ऐसे ही हैं
    अगर हम पहले की तरह सिर्फ distro package managers पर निर्भर रहते, तो आज जैसा तेज़ ecosystem संभव नहीं होता
    हाँ, security को मज़बूत करने वाले नए package managers आ रहे हैं। वजह समझे बिना सिर्फ माध्यम को दोष देना सही नहीं है
  • frontend development कुछ “trust me bro” वाले Wild West जैसा लगता है। browser के विकास-क्रम की वजह से इसे मजबूरी में duct tape की तरह जोड़-तोड़कर बनाया गया है
  • अगर आपने npm को Docker में freeze किया था, तो मैं पूछना चाहूँगा कि dependency update के बाद क्या आप हर बार उस environment को verify करते थे
    दरअसल npm और pnpm पहले से ही default रूप में lock files के जरिए dependencies को pin करते हैं
  • यह समस्या इसलिए है क्योंकि “npm install thing” बहुत आसान और सस्ता है
    बहुत-सा open source quality से ज़्यादा resume-driven code से भर जाता है, और आखिरकार वही किसी बड़ी कंपनी के ad tracker या wallet app जैसी चीज़ों में इस्तेमाल होता है

• npm install सिर्फ package डाउनलोड नहीं करता, बल्कि code execute करता है
  package.json के preinstall, install, postinstall hooks सचमुच चलाए जाते हैं
  install प्रक्रिया के दौरान वैध रूप से arbitrary commands चलाने की ज़रूरत आखिर क्यों होनी चाहिए?
  संबंधित रिपोर्ट: PhantomRaven npm malware
  एक और मामला: Socket.dev ब्लॉग

  • सच कहें तो ऐसा ढाँचा पुराने package managers (DEB, RPM) में भी था
    उदाहरण के लिए Linux kernel package install होने के बाद initramfs को दोबारा बनाना, GRUB update करना जैसी चीज़ों के लिए post-install scripts चलाता है
    ज़्यादातर DEB/RPM packages में ऐसे scripts शामिल होते हैं। यानी यह design का ही मसला है
  • असली समस्या यह है कि npm में कोई भी package publish कर सकता है
    Linux distributions में भरोसेमंद maintainer system होता है, और कई बार PGP-आधारित root of trust भी बनाया जाता है
    जबकि npm, pip, rubygems, cargo वगैरह असल में “curl | bash” का ही एक polished version हैं
  • उदाहरण के लिए Mediasoup project C++ में लिखी streaming library है, और install के समय source को सीधे compile करता है
    maintenance burden घटाने के लिए ऐसे post-install build की ज़रूरत पड़ी
  • Swift Package Manager भी Package.swift file को वास्तव में execute करता है
    लेकिन सुना है कि यह काफ़ी मज़बूती से sandboxed होता है, इसलिए दुरुपयोग कठिन है
    संदर्भ: SwiftPM docs, PackageDescription
  • जानकारी के लिए, pnpm v10 default रूप से सभी lifecycle scripts को disable करता है, और user को उन्हें manually allow करना पड़ता है
    संबंधित चर्चा

• हाल के npm attacks को देखकर लगता है कि अब npm के साथ development करना सुरक्षित है भी या नहीं
  हर बार जब React project शुरू करता हूँ, सैकड़ों packages install हो जाते हैं, और पता ही नहीं चलता कि वे क्या कर रहे हैं
  backend में तो ज़रूरत के packages ही explicitly install करता हूँ, लेकिन frontend vulnerabilities का Pandora’s box जैसा लगता है

  • सच तो यह है कि लगभग हर language ecosystem ऐसा ही है। बस npm सबसे बड़ा है और खबरों में ज़्यादा आता है
  • Rust का jj install किया तो 470 packages आए, और Python के wan2gp में 211 packages। सब जगह लगभग वही हाल है
  • JavaScript ecosystem संरचनात्मक रूप से attacks के लिए कमज़ोर है
    xz घटना की तरह, हर dependency किसी random individual पर टिकी होती है, और हमें भरोसा करना पड़ता है कि वे social engineering attack का शिकार नहीं होंगे
  • जितनी कम dependencies हों उतना बेहतर। 0 हो तो सबसे बढ़िया। वही असली जीत है
  • वैसे PyPI भी सुरक्षित नहीं है। GitHub Actions hack के जरिए legitimate package में malicious code डालने के मामले भी सामने आए हैं

• Angular, Vue जैसे frameworks के साथ development करते समय हर बार घबराहट होती है
  node_modules के अंदर हज़ारों dependencies देखकर यह आने वाली तबाही जैसा लगता है
  कोई एक open source developer phishing का शिकार हो जाए तो तुरंत infection हो सकता है
  JavaScript ecosystem मूल रूप से टूटा हुआ है। सिर्फ एक typo से supply chain attack के सामने आ सकते हैं
  NuGet या Maven में भी यह संभव है, लेकिन वहाँ standard library बड़ी होती है, इसलिए dependencies कम रहती हैं और कुछ नियंत्रण का एहसास होता है

  • Go package names की जगह repo URL इस्तेमाल करता है, जिससे typosquatting कम होता है
    यह परफेक्ट नहीं है, लेकिन फिर भी एक स्तर बेहतर है
  • Deno इस समस्या को हल करता है। यह Node.js / npm की संरचनात्मक समस्या है

• 86,000 downloads में से ज़्यादातर असली users नहीं, बल्कि automated scanners या bots होने की संभावना है
  नई version publish करते ही एक-दो दिन में सैकड़ों downloads दिखते हैं, लेकिन वे असली इंसान न भी हों
  यानी संक्रमित users की संख्या बहुत कम, या शायद लगभग शून्य भी हो सकती है

  • मैंने भी जब library publish की थी, शुरू में हफ़्ते में 300 और बाद में लगभग 100 downloads दिखते थे
    AI chatbots द्वारा hallucination से बनाए गए package names को निशाना बनाने वाले attacks भी बहुत हैं। यह सिर्फ साधारण आँकड़ों की बात नहीं है
  • या फिर किसी का zombie CI लगातार डाउनलोड कर रहा हो सकता है
  • लेकिन अगर हमला LLM द्वारा बनाए गए fake package names को target कर रहा था, तो संभव है कि वास्तव में कई developers संक्रमित हुए हों

• हमले का और विस्तृत विवरण BleepingComputer लेख में देखा जा सकता है

• मैं सोच रहा हूँ कि npm install के दौरान HTTP URL को dependency की तरह इस्तेमाल करने वाले packages को detect या filter करने का कोई तरीका है या नहीं
  क्योंकि requester के हिसाब से अलग payload भेजा जा सकता है, इसलिए सामान्य scanners के लिए इसे पकड़ना कठिन है

• एक hobby developer के रूप में मैं सोचता हूँ कि ऐसे supply chain attacks से बचाव कैसे किया जाए
  मशहूर tutorials को follow करते हुए dependencies install करते-करते कब security के प्रति लापरवाह हो जाते हैं, पता ही नहीं चलता
  मैं अपने homelab में कई services भी चलाता हूँ, और चिंता रहती है कि कहीं कोई bot घुसपैठ न कर ले। शुरुआत कहाँ से करूँ?

  • अगर services को containers या VMs के अंदर अलग-अलग चलाएँ, तो नुकसान को isolate किया जा सकता है
    यह पूरी गारंटी नहीं है, लेकिन पूरे server के compromise होने से कहीं बेहतर है
  • हर dependency को संभावित security risk मानें, और सिर्फ तभी इस्तेमाल करें जब वह सच में ज़रूरी हो
    ज़रूरत का code खुद कॉपी करके इस्तेमाल करना भी सीखने और सुरक्षित रहने का अच्छा तरीका है
  • लोकप्रिय और कम-से-कम 1 साल पुरानी release का इस्तेमाल ज़्यादा सुरक्षित है। अगर कोई समस्या होती, तो उसके अब तक सामने आ जाने की संभावना ज़्यादा रहती है
  • FreeBSD जैसे कुछ OS system package manager का इस्तेमाल करते हैं
    ऐसे ढाँचे में लाखों users को अलग-अलग verify करने की ज़रूरत नहीं पड़ती, क्योंकि distribution स्तर पर भरोसेमंदी सुनिश्चित की जा सकती है
  • मैं 10 लाख साप्ताहिक downloads से ऊपर वाले, बिना dependencies वाले packages को प्राथमिकता देता हूँ
    उदाहरण: Hono, Zod
    मैं हाल ही में Bun पर switch हुआ हूँ, क्योंकि इसमें DB driver या S3 client जैसी चीज़ें default रूप से built-in मिलती हैं, जिससे अतिरिक्त downloads कम हो जाते हैं

• lifecycle hooks के अंदर dependencies लाने वाली संरचना कभी भी attack pivot point बन सकती है
  आज भले वह सामान्य हो, लेकिन बाद में owner hack हो जाए या उसका इरादा बदल जाए, तो वही malicious code बन सकता है
  इस तरह के install hooks आखिरकार टिकाऊ design नहीं हैं