यह कहानी तब शुरू होती है जब रिएक्ट-आधारित ओपन-सोर्स डॉक्यूमेंटेशन प्रोजेक्ट डॉक्यूसॉरस के अनुरक्षक सेबेस्टियन लॉर्बर ने पैकेज मेनिफेस्ट में एक पुल अनुरोध परिवर्तन को नोटिस किया। यहां लोकप्रिय cliui npm पैकेज में प्रस्तावित परिवर्तन है:

विशेष रूप से, हमारा ध्यान एनपीएम निर्भरता परिवर्तन की ओर आकर्षित करना जो एक अपरिचित वाक्यविन्यास का उपयोग करता है:

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"

अधिकांश डेवलपर्स किसी पैकेज या शायद Git या फ़ाइल-आधारित URL के मूल्य में एक सेमेस्टर संस्करण रेंज देखने की उम्मीद करेंगे। हालाँकि, इस मामले में, एक विशेष npm है: उपसर्ग सिंटैक्स। इसका मतलब क्या है?

एनपीएम पैकेज अलियासिंग क्या है?

एनपीएम पैकेज प्रबंधक एक पैकेज अलियासिंग सुविधा का समर्थन करता है जो पैकेजों के लिए कस्टम रिज़ॉल्यूशन नियमों की परिभाषा की अनुमति देता है। इस प्रकार, जहां भी पैकेज को संदर्भित किया जाता है, कोड या लॉकफाइल के माध्यम से, यह उपनाम द्वारा निर्दिष्ट नाम और संस्करण का समाधान करेगा।

इसलिए, इस पुल अनुरोध में प्रस्तावित परिवर्तन के मामले में, पैकेज स्ट्रिंग-चौड़ाई-सीजे ^4.2.0 संस्करणों में पैकेज स्ट्रिंग-चौड़ाई का समाधान करेगा। इसका मतलब है कि स्ट्रिंग-विड्थ-सीजेएस के लिए एक नोड_मॉड्यूल निर्देशिका प्रविष्टि होगी, लेकिन स्ट्रिंग-विड्थ@^4.2.0 की सामग्री और लॉकफाइल (पैकेज-लॉक.जेसन) में समान व्यवहार के साथ।

पैकेज एलियासिंग एक एनपीएम पैकेज प्रबंधक सुविधा है जिसका उपयोग ईएसएम बनाम सीजेएस का समर्थन करने जैसे मामलों में किया जा सकता है।

उसके अनुसार, पैकेज अलियासिंग का दुरुपयोग किया जा सकता है। 2021 के एक लेख और सुरक्षा प्रकटीकरण में, निशांत जैन, एक स्निक एंबेसडर, ने प्रदर्शित किया कि कैसे आधिकारिक एनपीएमजेएस रजिस्ट्री को निर्भरता भ्रम और आपूर्ति श्रृंखला सुरक्षा चिंता के हिस्से के रूप में पैकेज अलियासिंग के आधार पर निर्भरता की जानकारी को गलत सूचना देने के लिए मूर्ख बनाया जा सकता है।

पुल अनुरोध सौम्य था और आपूर्ति श्रृंखला पर हमले का कोई जोखिम नहीं था। हालाँकि, पैकेज के नाम पर सेबेस्टियन की चिंता के कारण संभावित सुरक्षा जोखिम का पता चला।

दुर्भावनापूर्ण मॉड्यूल से संबंधित एनपीएम लॉकफाइल्स में संदिग्ध व्यवहार का पता लगाना

पुल अनुरोध की जांच करने के लिए, सेबेस्टियन ने लॉकफाइल-लिंट का उपयोग किया। यह टूल छेड़छाड़ के संकेतों के लिए पैकेज-लॉक.जेसन या यार्न.लॉक जैसे लॉकफ़ाइलों की जांच करता है, यह सुनिश्चित करता है कि मूल एनपीएम पैकेज के बजाय दुर्भावनापूर्ण पैकेज इंजेक्ट नहीं किए गए हैं।

टूल चलाने पर निम्नलिखित चेतावनियाँ दिखाई दीं:

npx lockfile-lint --path package-lock.json --allowed-hosts yarn npm --validate-https --validate-package-names

detected resolved URL for package with a different name: string-width-cjs
    expected: string-width-cjs
    actual: string-width

detected resolved URL for package with a different name: strip-ansi-cjs
    expected: strip-ansi-cjs
    actual: strip-ansi

detected resolved URL for package with a different name: wrap-ansi-cjs
    expected: wrap-ansi-cjs
    actual: wrap-ansi

 ✖ Error: security issues detected!

अस्वीकरण: लॉकफाइल-लिंट एक उपकरण है जिसे मैंने 2019 में अपने प्रकाशन के बाद विकसित किया, जिसने लॉकफाइल्स के साथ सुरक्षा चिंता का खुलासा किया: एनपीएम लॉकफाइल्स दुर्भावनापूर्ण मॉड्यूल को इंजेक्ट करने के लिए एक सुरक्षा ब्लाइंडस्पॉट क्यों हो सकता है.

हाई-अलर्ट: एनपीएम पर लोकप्रिय पैकेज एक जैसे दिखते हैं

उपरोक्त लॉकफ़ाइल-लिंट परिणामों को देखते हुए, सेबेस्टियन ने एनपीएम पर इन पैकेज नामों को देखा और आश्चर्यजनक रूप से पाया कि ये सार्वजनिक एनपीएम रजिस्ट्री पर मौजूद हैं:

• https://www.npmjs.com/package/string-width-cjs
• https://www.npmjs.com/package/strip-ansi-cjs
• https://www.npmjs.com/package/wrap-ansi-cjs

सेबेस्टियन ने देखा कि ये पैकेज नाम न केवल एनपीएम पर मौजूद हैं, बल्कि संदिग्ध विशेषताओं को भी प्रदर्शित करते हैं। पैकेज किसी सार्वजनिक स्रोत कोड भंडार से बंधे नहीं थे, निरीक्षण करने पर उनमें कोई भी वास्तविक कोड नहीं था, और बिना किसी संबंधित व्यक्तिगत जानकारी के गुमनाम रूप से प्रकाशित किए गए थे।

एनपीएम पैकेज स्ट्रिप-एएनएसआई-सीजेएस को देखते हुए, कोई रीडमी या स्रोत कोड रिपॉजिटरी नहीं है। हालाँकि, समान व्यवहार का हवाला देते हुए कई वैध और लोकप्रिय पैकेज हैं।

वास्तव में, यह विशेष पैकेज लोकप्रिय है, जैसा कि हम इसके 529 आश्रितों (अन्य पैकेज जो इस पर निर्भर हैं) और 7,274 साप्ताहिक डाउनलोड द्वारा देख सकते हैं।

स्ट्रिप-एएनएसआई-सीजेएस के कोड को देखने से पता चलता है कि इस पैकेज में केवल एक ही फ़ाइल है, पैकेज मेनिफेस्ट पैकेज.जेसन फ़ाइल।

तो, जो पैकेज कुछ नहीं करता उसे इतने सारे डाउनलोड क्यों मिलते हैं, और इतने सारे अन्य पैकेज उस पर निर्भर क्यों होते हैं?

आइए इन एनपीएम पैकेजों के लेखक का निरीक्षण करें।

सभी तीन पैकेजों का स्वामित्व heanshutester002 के पास है, और उनके सभी पैकेज पिछले साल प्रोग्रामेटिक संस्करण संख्याओं के साथ प्रकाशित किए गए थे। ध्यान देने योग्य कुछ दिलचस्प टिप्पणियाँ:

• isaacs-cliui npm पैकेज संभावित रूप से इसहाक के cliui प्रोजेक्ट के अपने फोर्क और उनके नेमस्पेस के तहत वैध npm पैकेज पर एक टाइपिंग का प्रयास है: @isaacs/cliui।
• Azure-sdk-for-net npm पैकेज संभावित रूप से समान नाम के निजी पैकेजों पर हमला करने के लिए निर्भरता भ्रम अभियान का एक प्रयास है।
• लिंक-डीप एनपीएम पैकेज लॉश और अन्य जैसे उपयोगिता पैकेजों से संबंधित एक लोकप्रिय क्षमता पर कब्ज़ा कर रहा है।

आप यह भी नोट कर सकते हैं कि उपयोगकर्ता heanshutester002 के पास npmjs पर इस उपयोगकर्ता प्रोफ़ाइल पृष्ठ पर कोई पहचान योग्य जानकारी नहीं है।

हमने पहले नोट किया था कि स्ट्रिप-एएनएसआई-सीजेएस एनपीएम पैकेज में 500 से अधिक अन्य पैकेज हैं जो इसका उपयोग करते हैं, इसलिए, यह संभवतः लोकप्रियता के लिए एक सकारात्मक संकेतक है। आइए उन पर नजर डालें:

सूची में शामिल होने के कारण यह विश्वसनीय लग सकता है, लेकिन क्या यह वास्तव में है?
उदाहरण के लिए, क्लैज़-ट्रांसफॉर्मर या रिएक्ट-नेटिव-मल्टीप्ली या शायद जीएच-मोनोप्रोजेक्ट-सीएलआई जैसे नाम वैध लगते हैं, लेकिन क्या वे हैं?

यहां प्रतिक्रिया-मूल-गुणा एनपीएम पैकेज पृष्ठ है:

इस पैकेज का वस्तुतः कोई डाउनलोड नहीं है और इसका लेखक एक गुमनाम एनपीएम उपयोगकर्ता है जिसके पास कोई पहचान योग्य जानकारी नहीं है। यह पैकेज जिस स्रोत URL रिपॉजिटरी पर रीडायरेक्ट करता है वह अस्तित्वहीन https://github[.]com/hasandader/react-native-multiply है। GitHub उपयोगकर्ता प्रोफ़ाइल भी बहुत संदिग्ध लगती है और इसमें व्यावहारिक गतिविधि का अभाव है।

हालांकि एनपीएम पैकेज में स्रोत कोड शामिल प्रतीत होता है, करीब से देखने पर पता चलता है कि यह "हैलो वर्ल्ड" एप्लिकेशन प्रोटोटाइप के लिए जेनरेट किया गया कोड नमूना है।

आपको यह भी आश्चर्य होगा कि यदि यह पैकेज सिर्फ एक गुणन पुस्तकालय है, तो इसे निम्नलिखित कार्य करने के लिए 776 निर्भरताओं की आवश्यकता क्यों है:

import { multiply } from 'react-native-multiply';
const result = await multiply(3, 7);

हालांकि अत्यधिक निर्भरता उपयोग के माध्यम से नेस्टेड पैकेजों के एक खगोलीय वृक्ष में जावास्क्रिप्ट के योगदान के बारे में कुछ मज़ाक हैं, 776 प्रत्यक्ष निर्भरता वाला एक प्रोजेक्ट अनुचित रूप से बड़ा है।

इन सभी निर्भरताओं के बीच, 3 संदिग्ध एनपीएम पैकेज हैं जिनके साथ हमारी कहानी शुरू हुई: स्ट्रिंग-चौड़ाई-सीजेएस, स्ट्रिप-एएनएसआई-सीजेएस, और रैप-एएनएसआई-सीजेएस:

हमने बताया कि स्ट्रिप-एनएसआई-सीजेएस निर्भरताओं में से एक को क्लैज़-ट्रांसफॉर्मर नाम दिया गया था। आइए इसे देखें:

आइए समझाएं कि यहां क्या हो रहा है। ​एनपीएम पैकेज क्लैज़-ट्रांसफॉर्मर को जानबूझकर इसके रीडमी पेज पर क्लास-ट्रांसफॉर्मर शीर्षक के साथ गलत नाम दिया गया है। इसके अतिरिक्त, इसका स्रोत कोड भंडार, https://github[.]com/typestack/class-transformer, पैकेज नाम से संबंधित नहीं है, जो इसकी वैधता के बारे में चिंता पैदा करता है।

GitHub पर संबंधित रिपॉजिटरी के टाइपस्टैक/क्लास-ट्रांसफॉर्मर में package.json फ़ाइल इस प्रकार है:

GitHub पर package.json फ़ाइल निर्भरता की कोई घोषणा नहीं दिखाती है, फिर भी यदि हम npmjs पर वास्तविक पैकेज के स्रोत कोड का निरीक्षण करते हैं, तो हम 437 निर्भरताएँ देखते हैं जिनके साथ यह क्लैज़-ट्रांसफॉर्मर पैक किया गया है। फिर, उन्होंने बहुत आसानी से 3 संदिग्ध *-सीजेएस पैकेजों को बंडल कर दिया:

संदिग्ध एनपीएम पैकेज निष्कर्षों पर आगे के विचार

आगे निष्कर्ष निकालने से पहले, ऊपर देखे गए एनपीएम पैकेजों की कुछ विशेषताओं का उल्लेख करना महत्वपूर्ण है:

• रिएक्ट नेटिव पैकेज क्रिएट-रिएक्शन-नेटिव-लाइब्रेरी स्कैफोल्ड टूल से लिया गया प्रतीत होता है। यह टूल एक नए प्रोजेक्ट के लिए जेनरेट किए गए स्टॉक सोर्स कोड के हिस्से के रूप में डिफ़ॉल्ट मल्टीप्ल फ़ंक्शन उदाहरण भी पेश करता है।
• पैकेज में निर्देशिका और फ़ाइल संरचनाएं और निर्भरताएं होती हैं जिन्हें Next.js 14 स्टार्टर बॉयलरप्लेट से प्राप्त किया जा सकता है, जैसे कि npx create-next-app@14 के साथ बनाए गए।

सोनाटाइप में हमारे साथियों ने पहले भी पैकेजों के साथ ओपन-सोर्स रजिस्ट्रियों की बाढ़ के ऐसे ही मामलों की पहचान की है। इन मामलों में, डेवलपर्स के लिए अंतिम लक्ष्य खुद को टी टोकन से पुरस्कृत करना था, जो ओपन-सोर्स सॉफ़्टवेयर से कमाई करने के लिए एक वेब3 प्लेटफ़ॉर्म है।

उल्लेखित पैकेजों में कुछ Tea.yaml फ़ाइलें ढूंढना इस थीसिस का समर्थन करता है कि इस अभियान का उद्देश्य चाय के दुरुपयोग के माध्यम से चाय टोकन प्राप्त करना है।

इस साल की शुरुआत में, 14 अप्रैल, 2024 को, एक चाय मंच उपयोगकर्ता ने एक टिप्पणी पोस्ट की जो चाय के दुरुपयोग की चिंता का समर्थन करती है:

समापन विचारों पर पहुंचने से पहले, मैं सेबेस्टियन लॉर्बर को उनकी सतर्क अनुरक्षक मानसिकता और संभावित एनपीएम आपूर्ति श्रृंखला हमले के इन धागों का अनावरण करने में मदद करने के लिए ईमानदारी से धन्यवाद देना चाहता हूं।

स्ट्रिंग-चौड़ाई-सीजेएस के साथ क्या हो रहा है?

इस बिंदु पर, मुझे पूरा विश्वास है कि मैं बाकी पैकेजों में छेद करना जारी रख सकता हूं जो प्रामाणिक वैधता के बहुत संदिग्ध संकेतक खोजने के लिए स्ट्रिंग-चौड़ाई-सीजे पर निर्भर हैं।

यह मेरी धारणा है कि ये सभी आश्रित पैकेज और डाउनलोड बूस्ट 3 *-सीजेएस पैकेजों के लिए झूठी वैधता बनाने के एकमात्र उद्देश्य की ओर ले जा रहे हैं ताकि उचित समय में, उचित शिकार के साथ, ये नकली पैकेज काम में आ सकें। इंस्टॉल करें और फिर एक नए दुर्भावनापूर्ण संस्करण के साथ चलें।

ओपन-सोर्स सॉफ़्टवेयर के साथ काम करते समय आपको सुरक्षित रहने में मदद करने के लिए, मैं सुरक्षा प्रथाओं और विशेष रूप से इन अनुवर्ती शैक्षिक संसाधनों को अपनाने की अत्यधिक अनुशंसा करता हूं:

• एनपीएम लॉकफाइल्स दुर्भावनापूर्ण मॉड्यूल को इंजेक्ट करने के लिए एक सुरक्षा ब्लाइंडस्पॉट क्यों हो सकता है
• 10 एनपीएम सुरक्षा सर्वोत्तम अभ्यास
• एनपीएम सुरक्षा: आपूर्ति श्रृंखला हमलों को रोकना

क्या हमने उनकी बेईमानी के बीच आपूर्ति श्रृंखला सुरक्षा अभियान को पकड़ लिया, या यह सब पैसे के लेन-देन के बारे में है और इसे चाय टोकन के लिए एनपीएम और गिटहब जैसी सार्वजनिक रजिस्ट्रियों के स्पैम और दुरुपयोग के लिए जिम्मेदार ठहराया जा सकता है?

हालांकि यह सामने आए, सतर्क रहें।