00:00:00यह गंभीर है और कोई मज़ाक नहीं है, पिछले कुछ घंटे बहुत कठिन रहे हैं, क्योंकि
00:00:06Axios पर एक बहुत बड़ा सप्लाई चेन हमला हुआ है, हाँ, वही Axios जिसके साप्ताहिक
00:00:148 करोड़ से ज़्यादा डाउनलोड्स हैं।
00:00:15अब, सबसे पहली बात।
00:00:18यह जाँचने के लिए कि क्या आप प्रभावित हैं, आपको एक लेख का लिंक मिलेगा, और
00:00:23मैं एक सेकंड में और विवरण साझा करूँगा, लेकिन यह महत्वपूर्ण है, यह जाँचने के लिए कि क्या आप
00:00:27प्रभावित हुए हैं, आप नीचे दिए गए उस लिंक पर जाएँ और वहाँ दिए गए कमांड चलाएँ
00:00:32अपने ऑपरेटिंग सिस्टम के लिए, Mac OS, Linux, Windows, वे सभी प्रभावित हैं।
00:00:37यदि आप प्रभावित हैं तो आप इन कमांड्स को चलाना चाहेंगे।
00:00:40और विशेष रूप से यदि यहाँ दिए गए चरण दिखाते हैं कि आपके साथ समझौता हुआ है, तो आपको
00:00:49अपने सीक्रेट्स बदलने होंगे, अपने पासवर्ड बदलने होंगे, अपने क्रेडेंशियल्स, अपने सिस्टम की API कीज़,
00:00:55आपके सिस्टम पर जो कुछ भी है, उसे चोरी हुआ समझें।
00:01:00अपने पासवर्ड चोरी हुए समझें, सब कुछ बदल दें, API कीज़ को डिसेबल कर दें, यह बहुत महत्वपूर्ण है।
00:01:07अब, वास्तव में क्या हुआ?
00:01:09Axios, ज़ाहिर तौर पर बहुत लोकप्रिय जावास्क्रिप्ट लाइब्रेरी है, एक ऐसी लाइब्रेरी जिसका उपयोग
00:01:17उदाहरण के लिए, React ऐप से बैकएंड API तक HTTP अनुरोध भेजने के लिए किया जा सकता है।
00:01:22इसका बहुत अधिक उपयोग किया जा रहा है, जैसा कि आप देख सकते हैं, और इस लाइब्रेरी में
00:01:28कुछ दुर्भावनापूर्ण कोड इंजेक्ट किया गया है।
00:01:29अब, इसका मतलब यह नहीं है कि उस लाइब्रेरी का उपयोग करने वाली वेबसाइटें प्रभावित हुई हैं।
00:01:36इसके बजाय इसका मतलब यह है कि वे सिस्टम जहाँ आपने वह लाइब्रेरी इंस्टॉल की थी, आपका MacBook, आपका
00:01:41PC, या शायद वह VPS जहाँ आपने अपनी वेबसाइट बनाई थी, उनके साथ समझौता किया गया है।
00:01:50यदि आपने पिछले कुछ घंटों में npm install, bun install, npm update, bun update जैसा कुछ भी किया है,
00:01:57तो इस बात का बहुत बड़ा खतरा है कि आप प्रभावित हुए हैं।
00:02:00फिर से, मैंने वे जाँचें साझा की हैं जिन्हें आपको यह देखने के लिए करना चाहिए कि क्या आप प्रभावित हुए हैं।
00:02:05अब, यह सब वास्तव में कैसे हुआ और वास्तव में सप्लाई चेन हमला क्या है?
00:02:10वैसे मैं यह भी साझा करूँगा कि आप भविष्य में इस तरह के हमलों से खुद को कैसे सुरक्षित रख सकते हैं।
00:02:15लेकिन पहले, आइए समझें कि वास्तव में क्या होता है और सप्लाई चेन हमला क्या है।
00:02:20सप्लाई चेन हमला बस एक ऐसा हमला है जो आपके एप्लिकेशन कोड को निशाना नहीं बनाता है।
00:02:24हमलावर सीधे आपके सिस्टम या आपके कोड बेस में घुसपैठ करने की कोशिश नहीं करता है।
00:02:31इसके बजाय, वे इस तथ्य का लाभ उठाते हैं कि आपके एप्लिकेशन कोड में आमतौर पर डिपेंडेंसीज़ होती हैं, जिनकी
00:02:37अपनी खुद की डिपेंडेंसीज़ होती हैं।
00:02:38तो आपके पास वह डिपेंडेंसी चेन है और हमला इसी डिपेंडेंसी चेन को निशाना बनाता है।
00:02:45तो यह आपके कोड से अपस्ट्रीम (upstream) में होता है।
00:02:48तो इनमें से किसी एक डिपेंडेंसी में हमले के कारण कुछ दुर्भावनापूर्ण कोड इंजेक्ट किया गया है,
00:02:54इसलिए नहीं कि मेंटेनर आप पर हमला करने की कोशिश कर रहा है।
00:02:58लेकिन इसके बजाय, उदाहरण के लिए, जैसे इस मामले में, एक मेंटेनर का अकाउंट हैक हो जाता है
00:03:03और हमलावर उसका उपयोग किसी लाइब्रेरी या पैकेज में दुर्भावनापूर्ण कोड इंजेक्ट करने के लिए करता है,
00:03:10जिसका उपयोग कोई दूसरा पैकेज कर रहा हो सकता है और आपका कोड उस पैकेज का उपयोग कर रहा हो सकता है
00:03:16जो दुर्भावनापूर्ण पैकेज का उपयोग करता है, या शायद आपका एप्लिकेशन कोड सीधे दुर्भावनापूर्ण डिपेंडेंसी को खींच लेता है।
00:03:23किसी भी तरह से, आपकी डिपेंडेंसीज़ में से एक में अब अचानक कुछ दुर्भावनापूर्ण कोड आ जाता है।
00:03:28और जैसे ही आप npm install या ऐसा कुछ चलाते हैं, या आप अपडेट करते हैं, वह पैकेज
00:03:36आपके सिस्टम पर डाउनलोड हो जाता है, वह दुर्भावनापूर्ण वाला, वह प्रभावित वाला, और फिर यह
00:03:41आमतौर पर पोस्ट इंस्टॉल स्क्रिप्ट्स की मदद से आपके सिस्टम पर दुर्भावनापूर्ण कोड निष्पादित कर सकता है।
00:03:47तो यदि आप नहीं जानते हैं, तो npm में स्क्रिप्ट्स का यह तंत्र है।
00:03:56हम सभी अपने प्रोजेक्ट्स में उनका उपयोग कर रहे हैं, उदाहरण के लिए, एक देव सर्वर शुरू करने के लिए, अपने प्रोजेक्ट को बनाने के लिए,
00:04:01टेस्ट चलाने के लिए, और इस तरह की चीज़ों के लिए।
00:04:04और वहाँ विशेष रूप से पोस्ट इंस्टॉल स्क्रिप्ट्स भी हैं, जिनका उपयोग आप शायद नहीं कर रहे होंगे जब
00:04:11आप एक React ऐप बना रहे हों, उदाहरण के लिए, लेकिन लाइब्रेरीज़ अक्सर उनका उपयोग करती हैं या शायद अक्सर नहीं,
00:04:17लेकिन लाइब्रेरी इंस्टॉल करने के बाद आपके सिस्टम पर कुछ कोड चलाने के लिए उनका उपयोग कर सकती हैं, आमतौर पर
00:04:23कुछ भी दुर्भावनापूर्ण या बुरा करने के लिए नहीं, बल्कि उदाहरण के लिए, कुछ कोड कंपाइल करने के लिए, एक बाइनरी बनाने के लिए
00:04:31जिसकी उस लाइब्रेरी को ज़रूरत हो सकती है, आपके सिस्टम को किसी भी तरह से तैयार करने के लिए ताकि वह वास्तव में
00:04:36उस लाइब्रेरी का उपयोग कर सके जिसे आपने अभी डाउनलोड किया है।
00:04:40पोस्ट इंस्टॉल स्क्रिप्ट के पीछे यही विचार है।
00:04:42यह एक पैकेज को कुछ कोड परिभाषित करने की अनुमति देता है जिसे npm install के माध्यम से इंस्टॉल होने के बाद
00:04:49निष्पादित किया जाना चाहिए, और आमतौर पर उन सप्लाई चेन हमलों में ठीक इसी चीज़ का लाभ उठाया जाता है।
00:04:55हमलावर किसी पैकेज में कुछ दुर्भावनापूर्ण कोड इंजेक्ट करता है जो अनिवार्य रूप से एक पोस्ट इंस्टॉल
00:04:57स्क्रिप्ट होती है जो संक्रमित पैकेज इंस्टॉल होने के बाद अपने आप चल जाती है।
00:05:04आमतौर पर वह कोड ओबफस्केटेड (obfuscated) होता है ताकि इसे पढ़ना आसान न हो।
00:05:10यह base64 एन्कोडेड हो सकता है ताकि दुर्भावनापूर्ण कोड के लिए पैकेज को स्कैन करने वाले स्कैनर
00:05:14इसका पता न लगा सकें और/या दुर्भावनापूर्ण कोड को डाउनलोड किया जा सके।
00:05:20तो पोस्ट इंस्टॉल स्क्रिप्ट, जैसा कि यहाँ Axios हमले के मामले में है, वास्तव में सीधे
00:05:24दुर्भावनापूर्ण कोड नहीं रखती है।
00:05:30इसके बजाय यह एक सर्वर से संपर्क करती है और वहां से कोड डाउनलोड करती है।
00:05:32यही यहाँ हुआ।
00:05:36और हमारे पास एक विस्तृत रिपोर्ट है कि उस हमले के दौरान वास्तव में क्या हुआ था।
00:05:37यदि आप सभी विवरण पढ़ना चाहते हैं तो आपको वह संलग्न मिलेगी, लेकिन उसमें हम अनिवार्य रूप से
00:05:41सीखते हैं कि Axios पैकेज के दो वर्ज़न, 1.14.1 और 0.30.4 प्रभावित हुए थे, अंत में समझौता किया गया था
00:05:45और वह हमलावर द्वारा Axios पैकेज मेंटेनर्स में से एक के अकाउंट तक पहुँच प्राप्त करने के कारण किया गया था
00:05:57और उन्होंने उस अकाउंट का उपयोग Axios पैकेज का एक नया वर्ज़न प्रकाशित करने के लिए किया
00:06:02जिसमें एक डिपेंडेंसी थी जिसमें बदले में वह पोस्ट इंस्टॉल स्क्रिप्ट थी।
00:06:08तो यह स्वयं Axios पैकेज भी नहीं था जिसमें पोस्ट इंस्टॉल स्क्रिप्ट थी, बल्कि
00:06:14इसके बजाय यह एक अन्य पैकेज था, plaincryptojs पैकेज, जिसे हमलावर द्वारा बनाया गया था,
00:06:19जिसका एकमात्र उद्देश्य एक पोस्ट इंस्टॉल स्क्रिप्ट रखना है जो कुछ दुर्भावनापूर्ण कोड को
00:06:25डाउनलोड करती है और चलाती है।
00:06:31तो Axios को plaincryptojs को Axios में एक डिपेंडेंसी के रूप में जोड़कर समझौता किया गया था।
00:06:32यह एक दुर्भावनापूर्ण पैकेज है।
00:06:39यह उस दुर्भावनापूर्ण कोड को डाउनलोड करने के अलावा और कोई उद्देश्य पूरा नहीं करता है और बस इस
00:06:40डिपेंडेंसी को Axios में जोड़कर, हमला अनिवार्य रूप से पूरा हो गया था।
00:06:46यह पैकेज कहीं भी Axios सोर्स कोड में इम्पोर्ट नहीं किया गया है।
00:06:52इसमें बस यह पोस्ट इंस्टॉल स्क्रिप्ट है और बस इतना ही।
00:06:56जैसा कि उल्लेख किया गया है, यह फिर Windows और Linux के लिए कोड डाउनलोड करने और चलाने में सक्षम है
00:06:59और फिर क्या करना है?
00:07:05खैर, बहुत सारी चीज़ें चुराना।
00:07:06तो यदि आपका सिस्टम प्रभावित है, जैसा कि मैंने शुरू में उल्लेख किया था, क्रेडेंशियल्स, API कीज़, क्रिप्टो टोकन,
00:07:08वह सब मज़ेदार चीज़ें एक ट्रोजन द्वारा एकत्र और बाहर भेजी जा रही हैं जो उस पोस्ट
00:07:14इंस्टॉल स्क्रिप्ट द्वारा डाउनलोड किया जाता है।
00:07:21इस तरह उस हमले ने काम किया।
00:07:22अतीत में इसी तरह के हमलों ने काम किया है।
00:07:24अब जो थोड़ा दिलचस्प है, वैसे, ओह, वैसे, यह हमला आधी रात के आसपास शुरू हुआ,
00:07:29ठीक आज आधी रात UTC के बाद, कुछ घंटे पहले।
00:07:36यह कुछ घंटों तक चला और Axios के दोनों वर्ज़न 1.14.1 और 0.30.4
00:07:4040 मिनट के भीतर, अनिवार्य रूप से सटीक रूप से 39 मिनट के भीतर प्रभावित हुए थे।
00:07:50तो यह एक बहुत ही सुनियोजित और योजनाबद्ध हमला था।
00:07:53ज़ाहिर है कि इस अतिरिक्त पैकेज का निर्माण हमला शुरू होने से
00:07:56मेरे विचार में 18 घंटे पहले हुआ था।
00:08:03यह बहुत ही सुनियोजित और योजनाबद्ध था।
00:08:04अब यहाँ जो थोड़ा अजीब है वह यह है कि NPM में 'trusted publishing' नामक यह तंत्र है, जिसका
00:08:06उपयोग पैकेज मेंटेनर्स द्वारा किया जा सकता है।
00:08:14और यहाँ विचार यह है कि यह पैकेज के नए वर्ज़न को प्रकाशित करने की प्रक्रिया को एक स्पष्ट रूप से
00:08:17परिभाषित प्रक्रिया तक सीमित करता है जहाँ विशेष रूप से आपको एक निश्चित सेटअप के साथ
00:08:26समर्थित CI/CD प्रदाताओं में से एक के माध्यम से नया वर्ज़न बनाना और प्रकाशित करना होता है।
00:08:32और यहाँ विचार यह है कि भले ही आपके NPM अकाउंट के क्रेडेंशियल्स चोरी हो जाएं, सिद्धांत रूप में,
00:08:38हमलावर अपनी मशीन से आपके पैकेज का नया वर्ज़न प्रकाशित नहीं कर सकता क्योंकि उन्हें
00:08:46उस प्रक्रिया से गुज़रना होगा।
00:08:51अब आप तर्क दे सकते हैं कि यदि किसी मेंटेनर का GitHub अकाउंट हैक हो जाता है, तो शायद
00:08:52एक दुर्भावनापूर्ण वर्ज़न GitHub पर पुश किया जा सकता है, जिससे यहाँ डिप्लॉय वर्कफ़्लो ट्रिगर हो जाएगा और इसलिए
00:08:59दुर्भावनापूर्ण कोड उस 'trusted publishing' प्रक्रिया के माध्यम से प्रकाशित हो जाता है।
00:09:06लेकिन यहाँ सुरक्षा रिपोर्ट के अनुसार, यहाँ वैसा नहीं हुआ है।
00:09:11क्योंकि Axios टीम 1.x ब्रांच के लिए इस 'trusted publishing' प्रक्रिया का उपयोग कर रही है, 0.30 ब्रांच के लिए नहीं,
00:09:16लेकिन 1.x ब्रांच के लिए।
00:09:21लेकिन इस रिपोर्ट के अनुसार, Axios GitHub रिपॉजिटरी में कोई कमिट या हमला नहीं हुआ है।
00:09:26इसलिए Axios के उस समझौता किए गए वर्ज़न के साथ GitHub पर कोई पुश नहीं हुआ था।
00:09:33इसलिए 'trusted publishing' प्रक्रिया ट्रिगर नहीं होनी चाहिए थी।
00:09:40इसके बजाय, यह रिपोर्ट कहती है कि हमलावर ने Axios के इस दुर्भावनापूर्ण या इस समझौता किए गए वर्ज़न को
00:09:44प्रकाशित करने के लिए एक लंबे समय तक चलने वाला क्लासिक NPM एक्सेस टोकन प्राप्त किया होगा क्योंकि
00:09:50रिलीज़ केवल NPM पर मौजूद थी, GitHub पर नहीं।
00:09:56शायद यह गलत है।
00:10:01हो सकता है हमला GitHub के माध्यम से हुआ हो।
00:10:02हालाँकि यदि यह सही है, तो मुझे स्पष्ट नहीं है कि इसने वास्तव में कैसे काम किया क्योंकि सिद्धांत रूप में,
00:10:05प्रकाशित करने का यह तरीका संभव नहीं होना चाहिए जब 'trusted publishing' चालू हो।
00:10:11पता नहीं क्या यह कोई सुरक्षा भेद्यता है या NPM के साथ यहाँ कोई समस्या है।
00:10:15कि 'trusted publishing' चालू होने के बाद भी कुछ मौजूदा लंबे समय तक चलने वाले टोकन का
00:10:20उपयोग किया जा सकता था।
00:10:26यह कुछ ऐसा है जिसे मैं पता नहीं लगा पाया कि वास्तव में कैसे हुआ।
00:10:27और यहाँ GitHub पर Axios लाइब्रेरी का एक मुद्दा (issue) है जहाँ इस हमले की
00:10:32रिपोर्ट की गई थी।
00:10:39वैसे, एक साइड नोट, ऐसे और भी मुद्दे बनाए गए थे और उन्हें समझौता किए गए
00:10:40मेंटेनर द्वारा, यानी उस मेंटेनर के अकाउंट द्वारा डिलीट कर दिया गया था जिसका अकाउंट हैक हुआ था।
00:10:45यह मुद्दा बच गया और अंततः हमले को रोक दिया गया।
00:10:48उन्होंने अपने अकाउंट तक वापस पहुँच प्राप्त कर ली, वह मेंटेनर जो प्रभावित हुआ था।
00:10:52और उस चर्चा में, उस मुद्दे में, मेंटेनर पोस्ट करता है और कहता है कि वे 'trusted publishing'
00:10:56का उपयोग कर रहे हैं और यह स्पष्ट नहीं है कि वास्तव में यह कैसे हुआ।
00:11:03यहाँ एक सिद्धांत साझा किया गया था।
00:11:07लेकिन मेरी समझ यह है कि इस सिद्धांत के लिए अभी भी एक नए दुर्भावनापूर्ण या समझौता किए गए वर्ज़न को
00:11:09GitHub पर पुश करने की आवश्यकता होगी, लेकिन फिर से, वह सब स्पष्ट नहीं है।
00:11:16जो स्पष्ट है वह यह है कि समझौता किए गए वर्ज़न प्रकाशित किए गए और NPM पर पहुँचे और
00:11:20इसलिए उन्हें सिस्टम पर डाउनलोड किया जा सका और वहां से चीज़ें चुराई जा सकीं।
00:11:25और निश्चित रूप से प्रति सप्ताह 8 करोड़ से अधिक डाउनलोड के साथ, कुछ ही घंटों के भीतर
00:11:29बहुत सारा नुकसान किया जा सकता है।
00:11:35ज़ाहिर है कि डाउनलोड दिन के सभी घंटों में समान रूप से वितरित नहीं होते हैं, लेकिन यह
00:11:37निश्चित रूप से एक बहुत बड़ी संख्या है और हम मान सकते हैं कि उन कुछ घंटों के भीतर हजारों, दसियों हज़ार सिस्टम
00:11:44प्रभावित हुए होंगे।
00:11:51अब निश्चित रूप से यह पहला सप्लाई चेन हमला नहीं था।
00:11:55पिछले महीनों में हमने कई हमले देखे हैं।
00:11:59पिछले साल के अंत में एक बड़ा हमला, 'shy hulu' हमला जहाँ NPM पर कई पैकेज
00:12:01निष्पादित किए गए थे और उसका पैटर्न भी समान था, उन सिस्टम पर दुर्भावनापूर्ण कोड इंजेक्ट किया गया और चलाया गया
00:12:08जिन्होंने उन समझौता किए गए पैकेजों को डाउनलोड किया और फिर क्रेडेंशियल्स और चीज़ें
00:12:16चुरा ली गईं।
00:12:21तो यह एक बड़ा हमला है।
00:12:22और फिर केवल कुछ दिन पहले हमें पायथन इकोसिस्टम में इसी तरह की घटना देखने को मिली।
00:12:25तो यह जावास्क्रिप्ट तक ही सीमित नहीं है जहाँ 'lightllm' पैकेज प्रभावित हुआ था।
00:12:31बहुत लोकप्रिय पैकेज जो अंततः एक सुविधाजनक इंटरफ़ेस के माध्यम से AI प्रदाताओं का उपयोग करना आसान बनाता है,
00:12:37उस पर भी इसी तरह का हमला हुआ था और वह प्रभावित हुआ था।
00:12:43और इसलिए यह निश्चित रूप से सिर्फ जावास्क्रिप्ट नहीं है।
00:12:49और मुझे लगता है कि इसके कुछ कारण हैं कि हम इस तरह के और हमले होते हुए क्यों देख रहे हैं।
00:12:52क्योंकि सिद्धांत रूप में, इस तरह के हमले अतीत में भी हो सकते थे और शायद हुए भी थे
00:12:57लेकिन स्पष्ट रूप से वे अब और अधिक बार हो रहे हैं और मुझे लगता है कि इसके
00:13:03कुछ कारण हैं।
00:13:08अब निश्चित रूप से एक बड़ा कारण यह है कि हम समय के उस पड़ाव पर हैं जहाँ पहले से कहीं अधिक कोड
00:13:11लिखा जा रहा है, जेनरेट किया जा रहा है।
00:13:17मेरा मतलब है कि आप विभिन्न मैट्रिक्स देख सकते हैं।
00:13:19उदाहरण के लिए मैंने हाल ही में यह चार्ट देखा कि बनाए जा रहे नए GitHub रिपॉजिटरी की संख्या
00:13:22सर्वकालिक उच्च स्तर पर है और निश्चित रूप से इसका कारण AI है।
00:13:27जहाँ लोग प्रोजेक्ट्स पर काम कर रहे हैं, कोड जेनरेट कर रहे हैं।
00:13:31हमारे पास पहले की तुलना में कहीं अधिक कोड आउटपुट है और निश्चित रूप से इसका मतलब है कि इतने सारे प्रोग्राम
00:13:35लिखे जा रहे हैं, इतना सारा कोड जेनरेट किया जा रहा है, हमले की सतह (attack surface) बहुत बड़ी हो गई है।
00:13:42अब और अधिक लक्ष्य हैं।
00:13:47अब और अधिक लोग कोड बना रहे हैं या लिख रहे हैं और पैकेज इंस्टॉल कर रहे हैं।
00:13:48इसलिए यह पहले से कहीं अधिक आकर्षक है।
00:13:52ऐसा नहीं है कि यह अतीत में आकर्षक नहीं था लेकिन अब पहले से कहीं अधिक लोग हैं जिन पर
00:13:54हमला किया जा सकता है।
00:13:59तो यह निश्चित रूप से एक बड़ा कारण है।
00:14:00इन हमलों को चलाना बस अधिक दिलचस्प है लेकिन यही एकमात्र कारण नहीं है।
00:14:03मुझे लगता है कि एक और कारण निश्चित रूप से AI से भी संबंधित है कि एक तरफ, AI की मदद से इस तरह के हमले
00:14:07चलाना शायद आसान हो गया है क्योंकि दुर्भावनापूर्ण कोड निश्चित रूप से
00:14:15AI की मदद से जेनरेट और लिखा जा सकता है, इसलिए इस तरह के हमलों को चलाने के लिए आवश्यक तकनीकी कौशल
00:14:21अतीत की तुलना में अधिक उपलब्ध हैं, मैं तर्क दूँगा, हालाँकि आप डार्कनेट में इस तरह के स्क्रिप्ट
00:14:28या ट्रोजन भी खरीद सकते थे लेकिन फिर भी यह लोगों के लिए अधिक सुलभ हो सकता है।
00:14:33यह निश्चित रूप से सिर्फ AI का अच्छा पक्ष नहीं है कि अधिक लोग सॉफ्टवेयर बना सकते हैं और अपने
00:14:40विचारों को व्यवसायों में बदल सकते हैं बल्कि यह बुरी चीज़ें भी हैं।
00:14:46AI की बदौलत ज़्यादा लोग कोड से जुड़ी बुरी चीज़ें कर सकते हैं, तो यह एक कारण है।
00:14:50आप यह तर्क भी दे सकते हैं कि निश्चित रूप से पैकेज मेंटेनर्स, लाइब्रेरी मेंटेनर्स पुल रिक्वेस्ट
00:14:55(pull requests) से दबे हुए हैं।
00:15:01यह एक और बड़ी समस्या है जो हमें इन दिनों है कि यदि आप एक ओपन सोर्स मेंटेनर हैं तो पहले से
00:15:02कहीं ज़्यादा पुल रिक्वेस्ट आ रही हैं इसलिए आप शायद इस बारे में बहुत सावधान नहीं हो सकते कि आप
00:15:07क्या मर्ज कर रहे हैं।
00:15:13सिर्फ स्पष्ट करने के लिए, यहाँ यह समस्या नहीं है।
00:15:14इस Axios हमले में स्पष्ट रूप से यह एक समझौता किया गया अकाउंट था लेकिन आप सिद्धांत रूप में” यह तर्क दे सकते हैं कि
00:15:16यह संभव हो सकता है कि मेंटेनर अपनी लाइब्रेरी में दुर्भावनापूर्ण कोड या ऐसा कोड जो दुर्भावनापूर्ण
00:15:22डिपेंडेंसीज़ इंस्टॉल करता है, मर्ज कर दें क्योंकि वे इसे नज़रअंदाज़ कर देते हैं या शायद
00:15:29इसलिए क्योंकि उनके पास पूरी तरह से स्वचालित कोड समीक्षा प्रक्रिया है जो इसे नहीं पकड़ पाती।
00:15:34वे बस AI पर भरोसा कर रहे हैं।
00:15:38फिर से, यहाँ ऐसा मामला नहीं है लेकिन आप सोच सकते हैं कि भविष्य में हमलावरों द्वारा इसका उपयोग किया जा सकता है
00:15:40कि वे कोड बेस में दुर्भावनापूर्ण कोड इंजेक्ट करें क्योंकि लोग देखते ही नहीं हैं।
00:15:45इसके अलावा जब आप अपने सिस्टम पर हर तरह के काम करने के लिए Cloth code, OpenCloth या जो कुछ भी उपयोग कर रहे हों,
00:15:51न केवल सॉफ्टवेयर पर काम करने में आपकी मदद करने के लिए बल्कि शायद आपके पूरे सिस्टम को मैनेज करने के लिए,
00:15:56तो निश्चित रूप से कुछ कार्यों के लिए OpenCloth, Cloth code, codecs या जो भी हो, वे कुछ स्क्रिप्ट लिखने
00:16:01और आपके द्वारा मांगे गए किसी कार्य को करने के लिए कुछ कोड चलाने का निर्णय ले सकते हैं और वह
00:16:09कोड जो उन्होंने जेनरेट किया है वह भी Axios जैसी डिपेंडेंसीज़ पर निर्भर हो सकता है।
00:16:15तो फिर से हमले की सतह बड़ी हो रही है, यह फिर से मेरा पहला तर्क है लेकिन
00:16:20सिर्फ क्लासिक सॉफ्टवेयर विकास के बाहर भी, और इन सभी कारणों और शायद कई अन्य कारणों से
00:16:24जिनके बारे में मैंने यहाँ नहीं सोचा, ये हमले अधिक लाभदायक, करने में आसान और अधिक
00:16:30दिलचस्प होते जा रहे हैं और इसीलिए मुझे यकीन है कि हम भविष्य में इस तरह के और हमले देखेंगे।
00:16:37अब आप ऐसे हमलों को रोकने के लिए, खुद को सुरक्षित रखने के लिए क्या कर सकते हैं?
00:16:43सुरक्षा का एक बड़ा कदम, एक चीज़ जो आप कर सकते हैं वह है अपने उन सभी प्रोजेक्ट्स में जहाँ आप
00:16:47एप्लिकेशन्स आदि पर काम कर रहे हैं, अपनी डिपेंडेंसीज़ को मैनेज करने के लिए npm के बजाय pnpm जैसे टूल्स
00:16:55का उपयोग करते समय आप अपनी pnpm workspace yaml फ़ाइल में एक न्यूनतम रिलीज़ आयु (minimum release age) सेटिंग
00:17:02जोड़ सकते हैं। bun में भी इसी तरह की सुविधा है, यदि आप पैकेज मैनेजर के रूप में bun का उपयोग कर रहे हैं
00:17:09तो आप bunfig.toml फ़ाइल जोड़ सकते हैं और उनमें भी न्यूनतम रिलीज़ आयु सेटिंग होती है जिसे आप जोड़ सकते हैं। यह क्या करता है?
00:17:15यह बस यह सुनिश्चित करता है कि जब भी आप कोई पैकेज इंस्टॉल करते हैं, चाहे कैसे भी, यह केवल उन पैकेजों
00:17:21को इंस्टॉल करता है जो कम से कम उतने पुराने हों या पैकेज वर्ज़न जो कम से कम उतने पुराने हों।
00:17:27तो यदि कोई पैकेज पाँच घंटे पहले हैक किया गया था लेकिन आपके पास एक नियम है जो केवल उन वर्ज़न
00:17:34को इंस्टॉल करता है जो कम से कम तीन दिन पुराने हों, तो आपको सुरक्षित रहना चाहिए। यही विचार है और दुर्भाग्य से
00:17:39स्वयं npm में अब वह सुविधा नहीं है। बस यह सुनिश्चित करने के लिए या यह स्पष्ट करने के लिए कि हम अभी भी उन पैकेजों
00:17:46के बारे में बात कर रहे हैं जो npm पर होस्ट किए गए हैं। मैं यहाँ जिस समस्या के बारे में बात कर रहा हूँ वह पैकेज मैनेजर है
00:17:51और आप निश्चित रूप से npm से उन पैकेजों को डाउनलोड करने के लिए bun या pnpm का उपयोग कर सकते हैं और यदि आप
00:17:56सिर्फ npm टूल के बजाय उनका उपयोग कर रहे हैं, तो आप इस तरह की सेटिंग्स का लाभ उठा सकते हैं
00:18:03जो आपको बस वह अतिरिक्त सुरक्षा परत देती हैं क्योंकि आमतौर पर अतीत में वे हमले
00:18:08कुछ घंटों के भीतर पकड़ लिए गए हैं। इसलिए यदि आपके पास उदाहरण के लिए तीन दिन की सीमा
00:18:14है, तो इनमें से अधिकांश हमले तब तक पकड़े जा चुके होंगे और खत्म हो जाएंगे। यह
00:18:20निश्चित रूप से 100% सुरक्षित नहीं है, एक हमला लंबे समय तक चल सकता है लेकिन यह आपको एक स्पष्ट लाभ देता है और यह
00:18:25निश्चित रूप से करने के लिए एक अच्छी चीज़ है। अब और भी अधिक सुरक्षित होने के लिए आप
00:18:32Doppler जैसे समाधानों का उपयोग करने पर विचार कर सकते हैं और यह स्पॉन्सर्ड नहीं है यह सिर्फ एक उदाहरण है, इसके विकल्प भी हैं।
00:18:39मैंने वास्तव में अपना खुद का विकल्प बनाया है जिसे मैं स्वयं उपयोग कर रहा हूँ जो ऐसी सेवाएं या उपकरण हैं जो
00:18:44आपके सीक्रेट्स को मैनेज करते हैं। तो आपकी OpenAI API की जैसी चीज़ को आप एक .env
00:18:49फ़ाइल में डाल सकते हैं लेकिन इसे Doppler जैसी सेवा की मदद से उनके सर्वर पर
00:18:55या आपके अपने VPS पर एनक्रिप्टेड स्टोर करना बेहतर है और फिर जब ज़रूरत हो तो आप इसे अपने एप्लिकेशन के
00:19:02पर्यावरण में इंजेक्ट करते हैं ताकि यदि आपके पास आपके सिस्टम पर कोई ट्रोजन
00:19:08हो जो शायद आपकी सभी .env फ़ाइलों को प्राप्त करता है और उनमें से जानकारी निकालता है,
00:19:13तो उसे वहां कोई सीक्रेट नहीं मिलेगा। यही विचार है। तो उन सीक्रेट्स को
00:19:20अपने सिस्टम पर टेक्स्ट फ़ाइलों में स्टोर न करना (और एक .env फ़ाइल अंततः सिर्फ एक टेक्स्ट फ़ाइल ही है)
00:19:25बल्कि कहीं और एनक्रिप्टेड स्टोर करना निश्चित रूप से कुछ ऐसा है जिसे आप करने पर विचार कर सकते हैं
00:19:32और फिर से यहाँ अलग-अलग समाधान हैं लेकिन यह कुछ ऐसा है जिस पर आप विचार कर सकते हैं
00:19:36और और भी अधिक सुरक्षित होने के लिए आप निश्चित रूप से अपने विकास परिवेश (development environment) को आउटसोर्स कर सकते हैं
00:19:40और इसे अपने MacBook, अपनी मशीन, अपने PC पर न रखकर, इसके बजाय इसे एक VPS पर, एक Mac Mini पर
00:19:45रख सकते हैं जिससे आप SSH या ऐसा ही कुछ करके कनेक्ट होते हैं या शायद एक Docker कंटेनर में ताकि
00:19:50यदि वहां कुछ दुर्भावनापूर्ण कोड निष्पादित किया जाता है तो यह केवल उस Docker कंटेनर या उस
00:19:56VPS को प्रभावित करे न कि आपके पूरे सिस्टम को। तो यह आपके सिस्टम के सभी पासवर्ड और इस तरह की
00:20:02चीज़ें एकत्र नहीं कर सकता। इसके बजाय यह अलग-थलग (isolated) है, आपके पास धमाके का एक छोटा दायरा (blast radius) है क्योंकि वे हमले
00:20:07ज़ाहिर है होते रहेंगे। मुझे पूरा यकीन है कि हमारे पास पैकेजों के सुरक्षित प्रकाशन को
00:20:13सुनिश्चित करने के लिए बेहतर और बेहतर तंत्र होंगे लेकिन इसकी कभी भी 100% गारंटी नहीं होगी कि
00:20:21ऐसे हमले नहीं हो सकते और इसलिए ऐसे पैकेजों के उपयोगकर्ता के रूप में आपको अपने सिस्टम को सुरक्षित करना
00:20:27होगा और वहां बचाव की कई परतें रखनी होंगी ताकि आप किसी
00:20:33समझौता किए गए पैकेज वर्ज़न को डाउनलोड करने की संभावना को कम कर सकें और यदि आप ऐसा करते हैं तो वहां धमाके का दायरा छोटा हो।
00:20:39मैं भविष्य के वीडियो में अपने दूसरे चैनल, 'Academy' चैनल पर भी इस बारे में और अधिक साझा करूँगा।
00:20:45लेकिन हाँ, वहां सुरक्षित रहें, जाँचें कि क्या आप इस हमले से प्रभावित हुए हैं
00:20:50और हाँ, जैसा कि मैंने उल्लेख किया, पिछले कुछ घंटे काफी कठिन रहे हैं।
00:20:55हमला और हाँ, जैसा कि मैंने उल्लेख किया है, यह पिछले कुछ घंटे काफी कठिन रहे हैं