TanStack और कई अन्य पैकेज प्रभावित - एक विस्तृत चर्चा और विश्लेषण
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsInternet Technology
Transcript
00:00:00अभी एक और बड़ा, वास्तव में बहुत बड़ा सप्लाई चेन हमला हो रहा है और यह अभी भी जारी है
00:00:06और यह NPM से पाइथन इकोसिस्टम तक फैल गया है, इसलिए शायद अभी कोई भी
00:00:12NPM या पाइथन पैकेज इंस्टॉल न करें। और सुनिश्चित करें कि आपका सिस्टम सुरक्षित रूप से सेट है। मेरे पास एक और वीडियो है
00:00:19उस पर, मैं नीचे एक लिंक साझा करूँगा और मैं इस वीडियो में भी उस पर वापस आऊँगा, लेकिन पहले मैं
00:00:23आपको कुछ विवरण देना चाहता हूँ कि क्या प्रभावित है और यह कैसे पता करें कि आप प्रभावित हैं या नहीं। यह शुरू हुआ
00:00:30TanStack पैकेजों के साथ, TanStack query, TanStack router, TanStack start आदि। कल, 11 मई को,
00:00:36बहुत कम समय के भीतर कुछ दुर्भावनापूर्ण पैकेज या वास्तव में सभी TanStack पैकेज
00:00:43दुर्भावनापूर्ण वर्जनों के साथ प्रकाशित किए गए थे और इसे 20 मिनट के भीतर जल्दी से रोक लिया गया था। अंत में
00:00:50इसका पता चल गया और इसे जल्दी रोक लिया गया लेकिन इस बीच ये सभी दुर्भावनापूर्ण पैकेज प्रकाशित हो चुके थे
00:00:57उस समय सीमा में या यहाँ उस छोटी समय सीमा में। और फिर यह फैलता रहा और यह अभी भी
00:01:03फैल रहा है। यह Mistral पैकेजों तक फैल गया जिनके केवल चार उपयोगकर्ता हैं लेकिन फिर भी वह
00:01:09प्रभावित हुआ क्योंकि यह मैलवेयर एक वर्म की तरह काम करता है और डेटा चोरी करता है, क्रेडेंशियल चोरी करता है, संभवतः
00:01:16आपके भी यदि यह आपके सिस्टम पर इंस्टॉल है। मैं बस एक सेकंड में इस पर वापस आऊँगा कि कैसे पता करें कि आप प्रभावित हैं या नहीं
00:01:20लेकिन यह अधिक NPM पैकेजों में फैलता रहा क्योंकि इसके पीछे यही विचार है और
00:01:26फिर पाइथन इकोसिस्टम में भी और ऐसा अभी हो रहा है। यह जानकारी सिर्फ कुछ घंटे पुरानी है,
00:01:32जिस समय मैं इसे रिकॉर्ड कर रहा हूँ उस समय से दो घंटे पहले। अब आप कैसे पता लगा सकते हैं कि आप
00:01:39प्रभावित हैं? यदि आपने कल शाम कोई TanStack पैकेज इंस्टॉल किया था, मेरे मामले में यहाँ जर्मन
00:01:45टाइम ज़ोन में, तो आपको खुद को प्रभावित मानना चाहिए। यदि आपने इसे उस समय के आसपास इंस्टॉल किया था, ध्यान रखें
00:01:54वह UTC है इसलिए आपको उसे अपने टाइम ज़ोन में बदलना होगा, उस समय में आपको खुद को
00:02:00प्रभावित मानना चाहिए। लेकिन चूँकि यह Mistral पैकेजों और कई और जावास्क्रिप्ट पैकेजों में फैल रहा है,
00:02:06जितने मैं यहाँ सूचीबद्ध कर सकता हूँ उससे कहीं अधिक, तो आपको खुद को या अपनी मशीन को प्रभावित और समझौता ग्रस्त मानना चाहिए।
00:02:13और मैं नीचे इन पोस्ट के लिंक साझा करूँगा ताकि आप गहराई से जान सकें और पूरी सूची देख सकें
00:02:18उन सभी प्रभावित पैकेजों की जैसा कि उन्हें प्रकाशित किया गया है। लेकिन जैसा कि बताया गया है, यह अभी भी जारी है,
00:02:22तो शायद अभी कुछ भी इंस्टॉल न करें। समझौते के संकेत भी हैं। आप
00:02:31खास फ़ाइल हैश, SHA हैश देखना चाहेंगे, राउटर के लिए एक JS फ़ाइल में। मैं नीचे इस पोस्ट को भी लिंक करूँगा।
00:02:38और यदि आपके पास यह निगरानी करने का कोई तरीका है कि आपकी मशीन पर कौन सा नेटवर्क अनुरोध हुआ,
00:02:42तो आप इस URL पर जाने वाले ट्रैफ़िक को देखना चाहेंगे, जो एक और स्पष्ट संकेत होगा
00:02:48कि आपके सिस्टम से डेटा चोरी किया गया है। विस्तार से समझौते का क्या मतलब है? इसका मतलब है कि
00:02:55यह मैलवेयर मुख्य रूप से दो काम करता है। पहली महत्वपूर्ण चीज़ जो यह करता है वह है डेटा इकट्ठा करना। यह
00:03:03NPM टोकन, GitHub टोकन, AWS क्रेडेंशियल और अन्य रहस्यों की तलाश करता है। तो यह आपके सिस्टम को स्कैन करता है
00:03:12उन सामान्य स्थानों के लिए जहाँ आप क्रेडेंशियल और रहस्य स्टोर करते हैं, और यह उन्हें इकट्ठा करके
00:03:18मेरे दिखाए गए इस URL पर भेज देता है। तो यह इन रहस्यों को चुराता है। लेकिन यह सिर्फ इतना ही नहीं करता। जैसा कि मैंने बताया,
00:03:26यह एक वर्म की तरह काम करता है, इसलिए यह चोरी किए गए इन GitHub टोकन का भी उपयोग करता है। उदाहरण के लिए,
00:03:33यह उनका और NPM टोकन का उपयोग अधिक प्रभावित पैकेज प्रकाशित करने के लिए करता है। यदि आप किसी अन्य
00:03:40पैकेज के मेंटेनर हैं, या शायद आपका कोई CI/CD वर्कफ़्लो है जो उस समय सीमा में चला और जो
00:03:46निर्भर करता था, तो उस CI/CD वर्कफ्लो में, वो दुर्भावनापूर्ण, समझौता किए गए
00:03:53TanStack पैकेज आ गए होंगे। दुर्भावनापूर्ण कोड वहाँ निष्पादित हुआ होगा। और फिर उस
00:04:00वर्कफ़्लो में, आपकी मशीन पर नहीं बल्कि उस वर्कफ़्लो में, यह कुछ क्रेडेंशियल चुरा सकता था
00:04:06उस पैकेज का एक दुर्भावनापूर्ण, समझौता ग्रस्त संस्करण प्रकाशित करने के लिए जिसे आपका CI/CD वर्कफ़्लो
00:04:14बनाने की कोशिश कर रहा था। तो इस तरह से यह फैलता है। जैसा कि मैंने बताया, यह एक वर्म के रूप में कार्य करता है। यह इन
00:04:20चोरी किए गए क्रेडेंशियल्स और टोकन का उपयोग अधिक प्रभावित पैकेज प्रकाशित करने के लिए कर रहा है। और इसी तरह यह
00:04:26Mistral और फिर अन्य जावास्क्रिप्ट पैकेजों में, और फिर पाइथन इकोसिस्टम में भी फैलता है। और यह
00:04:32वही स्थिति है जहाँ हम अभी हैं। और जहाँ तक मुझे पता है यह अभी भी फैल रहा है। अब, आप इससे कैसे
00:04:39बच सकते हैं? मैंने अपने दूसरे चैनल, AkataMind पर इसके बारे में एक वीडियो बनाया है। मैं उसे भी नीचे लिंक करूँगा।
00:04:44संक्षेप में यह है कि आप यह सुनिश्चित करना चाहते हैं कि आप अपना कोड चलाएँ या अपना विकास कार्य करें,
00:04:51सीधे अपनी मुख्य मशीन पर नहीं, बल्कि किसी वर्चुअल मशीन में या डेव कंटेनर में,
00:04:57इस तरह की किसी चीज़ में। आप अपनी मशीन पर सीधे रहस्य (secrets) स्टोर नहीं करना चाहते। मेरा मतलब है, AWS के लिए,
00:05:03उदाहरण के लिए, आप अपनी मशीन पर IAM क्रेडेंशियल स्टोर करने के बजाय उनके सिंगल साइन ऑन दृष्टिकोण का उपयोग करना चाहेंगे,
00:05:10उदाहरण के लिए, और अन्य सेवाओं के लिए भी इसी तरह की तकनीकों का उपयोग करें। इसके अलावा,
00:05:16आप अपने रहस्यों को स्टोर करने के लिए InPhysical या Doppler जैसी सेवाओं का उपयोग करने पर भी विचार करना चाहेंगे
00:05:25क्लाउड में न कि अपनी हार्ड ड्राइव पर, .env फ़ाइलों में नहीं। यह कुछ ऐसा है जो आप करना चाहेंगे।
00:05:30और फिर से, मैं उस वीडियो में ऐसी चीज़ों के बारे में बात करता हूँ। और आप पैकेज प्रबंधकों और
00:05:38कॉन्फ़िगरेशन का उपयोग करना चाहते हैं जो आपको न्यूनतम रिलीज़ आयु जैसी चीज़ों को कॉन्फ़िगर करने की अनुमति देते हैं, जैसा कि Bun आपको
00:05:44करने देता है। bunfig.toml फ़ाइल में, आप एक न्यूनतम रिलीज़ आयु सेट कर सकते हैं, जो यह सुनिश्चित करती है कि भले ही
00:05:49आप bun install चलाएँ, आप केवल वही पैकेज इंस्टॉल करते हैं जो कम से कम X सेकंड पुराने या इस उदाहरण में X दिन पुराने हों।
00:05:56अब, pnpm में भी समान विशेषता है। npm के नवीनतम वर्जनों में भी समान विशेषता है।
00:06:02फिर से, मैंने इसे उस दूसरे वीडियो में कवर किया है। और यदि आप Bun जैसा कुछ उपयोग करते हैं या यदि आपके पास
00:06:09npm के लिए सही कॉन्फ़िगरेशन है, लेकिन Bun इसे डिफ़ॉल्ट रूप से करता है, उदाहरण के लिए, तो यह
00:06:15पोस्ट इंस्टॉल स्क्रिप्ट के निष्पादन को भी रोकता है, जो उन पैकेजों के लाइफ़साइकिल स्क्रिप्ट हैं जिन्हें आप
00:06:21इंस्टॉल कर रहे हैं, जो आपको एक और सुरक्षा तंत्र देता है क्योंकि वह मैलवेयर आमतौर पर
00:06:28आपके सिस्टम पर ऐसी स्क्रिप्ट निष्पादित होने पर निर्भर करता है। इसलिए एक सुरक्षित पैकेज प्रबंधक और या सुरक्षित
00:06:36कॉन्फ़िगरेशन का उपयोग करना, अपने कोड को वर्चुअल मशीन या डेव कंटेनर में चलाना
00:06:41और अपने सिस्टम पर सादे रहस्य स्टोर न करना। यही वह है जो आप सामान्य रूप से करना चाहते हैं, लेकिन अब शायद
00:06:46और भी अधिक क्योंकि इस तरह के हमले अधिक गंभीर हो जाएँगे और हम यह देखेंगे कि वह हमला कैसे हुआ क्योंकि यह वास्तव में दिलचस्प है।
00:06:52लेकिन बेशक, हमारे पास ऐसे और भी हमले हो रहे हैं। मैं अब लगभग हर महीने या शायद उससे भी अधिक बार ऐसा वीडियो बनाता हूँ,
00:06:58क्योंकि एक तो मुझे लगता है कि उन्हें अंजाम देना अब आसान हो गया है। अब AI के युग में, उन पैकेजों या
00:07:04निर्भरताओं का विश्लेषण करना आसान है जिन्हें आप प्रभावित करना चाहते हैं और संभावित
00:07:12हमले के रास्तों के लिए उनके सोर्स कोड या CICD सेटअप का विश्लेषण करना आसान है। TanStack के लिए यही हुआ।
00:07:22ऐसा नहीं है कि किसी मेंटेनर की मशीन प्रभावित हुई थी, बल्कि इसके बजाय TanStack CICD वर्कफ़्लो पर हमला किया गया था।
00:07:28और मैं उस पर वापस आऊँगा। तो AI के साथ कमजोरियों को खोजना आसान है। कोड लिखना आसान है,
00:07:34बेशक दुर्भावनापूर्ण कोड भी शामिल है। और साथ ही, हमारे पास सॉफ़्टवेयर का विस्फोट हुआ है। हमारे पास पहले से कहीं अधिक
00:07:40सॉफ़्टवेयर लिखा जा रहा है। इसलिए बाहर अधिक लक्ष्य हैं, जिनमें कई लक्ष्य ऐसे भी शामिल हैं
00:07:45जो शायद सुरक्षा की ज्यादा परवाह नहीं करते। तो यह उन हमलों को और भी दिलचस्प बनाता है।
00:07:51अब, यह सब कैसे शुरू हुआ? यह वास्तव में दिलचस्प है। जैसा कि मैंने बताया, यह कोई बिल्कुल नया तरीका नहीं है,
00:07:57ऐसा नहीं है जिसे हमने पहले कभी नहीं देखा, लेकिन फिर भी काफी विस्तृत है। TanStack टीम ने एक
00:08:03पोस्टमॉर्टम प्रकाशित किया, एक लेख जहाँ वे बताते हैं कि हमला कैसे हुआ। और मैं उसे भी नीचे लिंक करूँगा।
00:08:09लेकिन निश्चित रूप से, मैं आपको यहाँ सारांश दूँगा क्योंकि अंत में, यह हमला
00:08:15तीन मुख्य चरणों पर निर्भर था, जिन्हें मैं विस्तार से समझाऊँगा। एक 'पुल रिक्वेस्ट टारगेट पॉन रिक्वेस्ट' पैटर्न।
00:08:22मैं समझाऊँगा कि वह क्या है। फिर 'फोर्क बेस्ड ट्रस्ट बाउंड्री' के पार GitHub एक्शन्स कैश पॉइज़निंग
00:08:30और OIDC टोकन का रनटाइम मेमोरी एक्सट्रैक्शन। ठीक है, इन सब का क्या मतलब है? फिर से,
00:08:38आप सभी विवरणों के लिए लेख पढ़ सकते हैं, लेकिन मुझे आपको सारांश देने दें। और चलिए
00:08:45'पुल रिक्वेस्ट पॉन रिक्वेस्ट' पैटर्न से शुरू करते हैं। वह क्या है? इसे समझने के लिए हमें यह समझना होगा
00:08:50कि GitHub एक्शन्स निश्चित रूप से GitHub द्वारा CI/CD समाधान, एक CI/CD उत्पाद है। और मेरे पास
00:08:58GitHub एक्शन्स पर एक कोर्स भी है, वैसे, यदि आप सीखना चाहते हैं कि GitHub एक्शन्स कैसे सेट करें,
00:09:05CI/CD कार्यों के लिए उत्पाद का उपयोग कैसे करें, अपने पैकेज या अपनी वेबसाइट को कैसे प्रकाशित करें आदि।
00:09:10अब, सभी CI/CD वर्कफ़्लो टूल्स की तरह, GitHub एक्शन्स उन घटनाओं (events) पर निर्भर करता है जो वर्कफ़्लो को ट्रिगर करती हैं क्योंकि
00:09:16बेशक CI/CD का मतलब ही स्वचालित तरीके से कुछ करना है। उदाहरण के लिए, अपनी वेबसाइट को स्वचालित तरीके से रिलीज़ करना,
00:09:24प्रकाशित करना, तैनात करना जब आप मुख्य शाखा (main branch) पर पुश करते हैं, उदाहरण के लिए।
00:09:29तो आपके पास विभिन्न घटनाएँ हैं जो एक वर्कफ़्लो को ट्रिगर कर सकती हैं और पुश एक ऐसी ही घटना है,
00:09:34ताकि आप कह सकें, ठीक है, अगर मैं मुख्य शाखा पर पुश करता हूँ, उदाहरण के लिए, तो आप अलग-अलग शाखाओं के लिए फ़िल्टर कर सकते हैं।
00:09:40फिर मैं कुछ कार्यों को निष्पादित करना चाहता हूँ। मैं अपनी निर्भरताएँ इंस्टॉल करना चाहता हूँ। मैं
00:09:44प्रोजेक्ट बनाना चाहता हूँ। मैं इसे अपने सर्वर पर अपलोड करना चाहता हूँ। आप ऐसा कर सकते थे। अब, एक और ट्रिगर
00:09:49'पुल रिक्वेस्ट टारगेट' है। यह ट्रिगर तब सक्रिय होता है जब आपके रिपॉजिटरी के लिए कोई पुल रिक्वेस्ट खोला जाता है।
00:09:56और इसका मतलब निश्चित रूप से यह है कि कोई भी आपके रिपॉजिटरी को फ़ोर्क कर सकता है, उसमें कुछ कर सकता है, अपने फ़ोर्क में कुछ पुश
00:10:05कर सकता है, और फिर आपके रिपॉजिटरी के साथ एक पुल रिक्वेस्ट खोल सकता है। और वह इस वर्कफ़्लो को ट्रिगर कर देगा।
00:10:14खतरनाक लग रहा है? खैर, यह एक तरह से है। और इसी से यह हमला शुरू हुआ।
00:10:19एक 'पुल रिक्वेस्ट' ट्रिगर भी होता है। तो मैंने पहले 'पुल रिक्वेस्ट टारगेट' के बारे में बात की थी,
00:10:25लेकिन हमारे पास 'पुल रिक्वेस्ट' भी है, जो उसी तरह काम करता है, लेकिन फिर पुल रिक्वेस्ट
00:10:31CI/CD वर्कफ़्लो को फ़ोर्क किए गए रिपॉजिटरी के संदर्भ में चलाता है। तो वहाँ जो कुछ भी दुर्भावनापूर्ण चल रहा हो,
00:10:38वह फ़ोर्क किए गए रिपॉजिटरी में होता है, बेस रिपॉजिटरी में नहीं। इसलिए यह कोई समस्या नहीं है।
00:10:45दूसरी ओर 'पुल रिक्वेस्ट टारगेट' बेस रिपॉजिटरी के संदर्भ में चलता है। और वह निश्चित रूप से
00:10:52संभावित रूप से खतरनाक है। यह संभावित रूप से खतरनाक है क्योंकि कोई भी पुल रिक्वेस्ट खोल सकता है। और निश्चित रूप से,
00:10:58TanStack हमले के लिए इस मामले में जो हुआ, उस पुल रिक्वेस्ट में, उस फ़ोर्क में, हमलावर ने
00:11:04दुर्भावनापूर्ण कोड, वर्म कोड, मैलवेयर को TanStack रिपॉजिटरी के फ़ोर्क में शामिल किया।
00:11:10फिर हमलावर ने पुल रिक्वेस्ट खोला, और इसके कारण 'पुल रिक्वेस्ट टारगेट' निष्पादित हुआ। और फिर जैसा कि बताया गया है,
00:11:20यह एक GitHub एक्शन्स रनर शुरू करता है, और यह बेस रिपॉजिटरी के संदर्भ में चलता है।
00:11:26इसका क्या मतलब है? इसका मतलब यह नहीं है कि हमलावर को बेस कोड तक पहुँच मिल जाती है या वह दुर्भावनापूर्ण कोड को
00:11:33रिपॉजिटरी में मिला सकता है, लेकिन इसका मतलब यह है कि, उदाहरण के लिए, जो कैश वहाँ उपयोग किया जा रहा है
00:11:40उसे बाद के GitHub एक्शन्स निष्पादन के साथ साझा किया जाएगा जो बेस रिपॉजिटरी से निकलते हैं,
00:11:46जो संभवतः पूरी तरह से अलग हुक या पुश ट्रिगर जैसे इवेंट ट्रिगर से हों। अगली चीज़ जो हुई वह थी
00:11:53कैश पॉइज़निंग। लेकिन इसका क्या मतलब है? खैर, हमलावर ने अपने फ़ोर्क में कोड जोड़ा जो यह सुनिश्चित करेगा कि
00:12:00जब पुल रिक्वेस्ट टारगेट ट्रिगर के लिए GitHub एक्शन्स चले, तो यह एक कमांड, 'hash files' कमांड चलाए,
00:12:05जो GitHub एक्शन्स द्वारा समर्थित है, ताकि GitHub एक्शन्स कैश में कुछ स्टोर किया जा सके। अब,
00:12:11वह कैश किस बारे में है? GitHub एक्शन्स कैश के पीछे का विचार बस उन GitHub एक्शन्स वर्कफ़्लो को तेज़ करना है।
00:12:17तो आप, उदाहरण के लिए, निर्भरताओं (dependencies) का हैश बना सकते हैं। विचार यह है कि यदि आपके पैकेज की
00:12:23कोई निर्भरता नहीं बदली है, तो आप फिर से पूरी स्थापना प्रक्रिया से क्यों गुजरेंगे? इसमें बस समय लगता है,
00:12:28और समय पैसा है क्योंकि आपसे आपके GitHub एक्शन्स वर्कफ़्लो के रनटाइम के लिए शुल्क लिया जाता है। और निश्चित रूप से,
00:12:33आप ऐसे वर्कफ़्लो नहीं चाहेंगे जो हमेशा के लिए चलें। इसलिए अधिकांश वर्कफ़्लो में, उदाहरण के लिए, TanStack पैकेज बनाते समय,
00:12:39आप TanStack पैकेजों की निर्भरताओं को इंस्टॉल करते हैं, और फिर आप बिल्ड स्टेप करते हैं और अपना TanStack पैकेज बनाते हैं।
00:12:46फिर से, यदि TanStack की वे निर्भरताएँ नहीं बदली हैं, तो उन्हें फिर से क्यों इंस्टॉल करें? यही कैशिंग के पीछे का विचार है।
00:12:52और यह समझ में आता है। बेशक समस्या यह है कि चूँकि वह पुल रिक्वेस्ट टारगेट GitHub एक्शन्स निष्पादन
00:12:56और अन्य GitHub एक्शन्स निष्पादन, जैसे पुश ट्रिगर के लिए, एक ही संदर्भ साझा करते हैं, वे एक ही कैश
00:13:00साझा करते हैं। और यहीं से कैश पॉइज़निंग शुरू होती है, क्योंकि हमलावर एक दुर्भावनापूर्ण संस्करण को कैश करने में या
00:13:06उस दुर्भावनापूर्ण कोड को TanStack की एक निर्भरता में डालने और उसे कैश करने में सक्षम था। तो फिर हमलावर
00:13:12को बस TanStack पैकेजों के लिए एक सामान्य GitHub एक्शन्स वर्कफ़्लो के चलने का इंतज़ार करना था।
00:13:18यानी किसी मेंटेनर के कुछ कोड पुश करने का, और फिर वह दूसरा GitHub एक्शन्स निष्पादन उसी कैश का पुन: उपयोग
00:13:24करेगा जो पहले दुर्भावनापूर्ण निष्पादन द्वारा सेट किया गया था, और अब वह तैयार किए गए ज़हरीले (poisoned) कैश
00:13:31को ले लेगा, जिसमें दुर्भावनापूर्ण कोड शामिल था। तो इस तरह से दुर्भावनापूर्ण कोड फ़ोर्क से एक सामान्य मेंटेनर
00:13:39द्वारा किए गए सामान्य पुश के सामान्य GitHub एक्शन्स निष्पादन में पहुँच गया जो किसी दुर्भावनापूर्ण कोड से प्रभावित नहीं था।
00:13:46इस तरह कैश का उपयोग अंततः इन दो GitHub एक्शन्स निष्पादनों के बीच एक परिवहन वाहन के रूप में किया गया था।
00:13:53और फिर तीसरे चरण के रूप में, एक बार जब दुर्भावनापूर्ण कोड ने उस पुश इवेंट के कारण TanStack CI/CD वर्कफ़्लो
00:14:01के नियमित निष्पादन में जगह बना ली, तो उसने TanStack पैकेज का एक दुर्भावनापूर्ण संस्करण
00:14:08प्रकाशित करने के लिए एक अल्पकालिक NPM टोकन, अंततः एक OIDC टोकन चुरा लिया। अब, मैं यहाँ किस बारे में बात कर रहा हूँ?
00:14:13तो इस तरह से वह द्वेषपूर्ण कोड फोर्क से निकलकर एक सामान्य मेंटेनर द्वारा किए गए सामान्य पुश के लिए सामान्य GitHub actions एक्जीक्यूशन में पहुँचा,
00:14:21अधिक सुरक्षित बनाती है, क्योंकि NPM पर पैकेज प्रकाशित करने के मुख्य रूप से दो तरीके हैं। एक यह कि आप
00:14:28अपने NPM खाते के साथ एक टोकन बनाते हैं और आप उसका उपयोग अपने पैकेज के नए संस्करण प्रकाशित करने के लिए करते हैं।
00:14:35समस्या यह है कि यदि वह टोकन चोरी हो जाता है, तो कोई भी उस पैकेज का नया संस्करण प्रकाशित कर सकता है। सुरक्षा
00:14:44बढ़ाने के लिए, यह trusted publishing प्रक्रिया है जहाँ NPM कहता है कि नहीं, आप अपनी मशीन से पैकेज प्रकाशित नहीं
00:14:54कर सकते, आपको इनमें से किसी एक भरोसेमंद प्रदाता के माध्यम से जाना होगा, GitHub एक्शन्स उनमें से एक है,
00:15:00और GitHub एक्शन्स के लिए एक trusted publishing एकीकरण है जिसे आप सेट कर सकते हैं। और फिर उस trusted publishing प्रक्रिया
00:15:04के हिस्से के रूप में, एक अल्पकालिक प्रकाशन टोकन प्राप्त किया जाएगा या उसका अनुरोध किया जाएगा। और फिर
00:15:11उस अल्पकालिक टोकन का उपयोग प्रकाशित किए जा रहे उस नए पैकेज संस्करण पर हस्ताक्षर करने के लिए किया जाएगा।
00:15:19तो सिद्धांत रूप में, विचार यह है कि टोकन को चुराना मुश्किल है क्योंकि वह किसी भी मेंटेनर की मशीन पर नहीं है। और
00:15:26इसके अलावा, यह अल्पकालिक है। यदि इसे चुरा भी लिया गया, तो यह बहुत लंबे समय तक सक्रिय नहीं रहता। बेशक,
00:15:33अपनी मशीन से, आपको इन भरोसेमंद प्रोवाइडर्स के ज़रिए जाना होगा, GitHub actions उनमें से एक है,
00:15:37और GitHub actions के लिए एक 'ट्रस्टेड पब्लिशिंग' इंटीग्रेशन है, जिसे आप सेटअप कर सकते हैं। और फिर
00:15:44होगी। और यही यहाँ हुआ। इसलिए उस दुर्भावनापूर्ण कोड ने इस टोकन का दुरुपयोग किया या इस टोकन का उपयोग किया
00:15:50TanStack पैकेज का एक नया संस्करण प्रकाशित करने के लिए। अब, दिलचस्प बात यह है कि यह हमला वास्तव में थोड़ा विफल
00:15:57रहा क्योंकि इसे वह भरोसेमंद टोकन तो मिल गया और इसने इसका उपयोग NPM API तक पहुँचने के लिए किया ताकि TanStack
00:16:03पैकेज का नया संस्करण प्रकाशित किया जा सके जिसमें यह वर्म और दुर्भावनापूर्ण कोड शामिल था। लेकिन यह वास्तव में
00:16:08एक ऐसे GitHub एक्शन्स वर्कफ़्लो में समाप्त हुआ जो पूरा होने में विफल रहा क्योंकि CICD को भेजे गए कोड में कुछ गड़बड़ थी।
00:16:15इसलिए यदि हमलावरों ने अपने हमले को ऐसे समय में चलाने पर ध्यान दिया होता जब वैध कोड भेजा जा रहा होता,
00:16:21तो निश्चित रूप से यह वर्कफ़्लो पूरा हो गया होता और उन्हें NPM API तक पहुँचकर मैन्युअल रूप से एक दुर्भावनापूर्ण पैकेज प्रकाशित
00:16:27करने पर निर्भर नहीं रहना पड़ता, बल्कि वे इस वर्कफ़्लो में दुर्भावनापूर्ण कोड इंजेक्ट कर सकते थे जैसा कि उन्होंने किया,
00:16:36इस वर्कफ़्लो को सफलतापूर्वक पूरा होने देते और फिर TanStack का एक समझौता ग्रस्त संस्करण प्रकाशित हो जाता
00:16:44जो बिल्कुल वैध दिखता क्योंकि यह एक मेंटेनर द्वारा किया गया सामान्य पुश था और वर्कफ़्लो सफलतापूर्वक समाप्त हुआ था।
00:16:52जिस तरह से इस हमले ने काम किया क्योंकि वह वर्कफ़्लो सफलतापूर्वक पूरा नहीं हुआ था, उसे अंततः यहाँ एक
00:16:58बाहरी योगदानकर्ता द्वारा पकड़ना थोड़ा आसान हो गया क्योंकि आप देख सकते थे कि TanStack पैकेजों का एक नया
00:17:06संस्करण प्रकाशित किया गया था भले ही GitHub एक्शन्स वर्कफ़्लो विफल रहा था, इसलिए कोई नया संस्करण प्रकाशित नहीं होना
00:17:12चाहिए था। तो आप वहाँ एक बेमेल देख सकते थे जिसने इस हमले का पता लगाना थोड़ा आसान बना दिया जो एक तरह से
00:17:19वह हिस्सा है जहाँ TanStack मेंटेनर्स और हम सभी भाग्यशाली रहे। फिर भी यह एक बहुत ही विस्तृत हमला था जैसा कि
00:17:26आप शायद बता सकते हैं जो किसी की मशीन से समझौता किए बिना पूरी तरह से काम कर गया और भले ही इसे जल्दी पकड़ लिया गया
00:17:32इसने गंभीर नुकसान किया क्योंकि जैसा कि मैंने बताया यह अभी भी फैल रहा है और वह एक लंबा
00:17:38एपिसोड था इन सब के बारे में मुझे पता है लेकिन मैं वास्तव में इस बात पर जोर देना चाहता हूँ कि आपको अपने सिस्टम को
00:17:45सुरक्षित बनाने पर काम करना होगा जैसा कि मैंने पहले बताया जैसा कि मैं इस वीडियो में साझा करता हूँ आप यह सुनिश्चित
00:17:51करना चाहते हैं कि आप प्रभावित होने के खतरे को कम करें यह हमला फिर से जल्दी पकड़ लिया गया था और फिर भी यह अभी भी फैल रहा है
00:18:00क्योंकि आप देख सकते थे कि TanStack पैकेज का एक नया संस्करण प्रकाशित किया गया था भले ही
00:18:05GitHub actions वर्कफ़्लो विफल रहा, इसलिए कोई नया संस्करण प्रकाशित नहीं होना चाहिए था। तो आप वहां एक
00:18:12बेमेल देख सकते थे जिससे इस हमले का पता लगाना थोड़ा आसान हो गया जो कि एक हिस्सा है जहाँ
00:18:19TanStack के रख-रखाव करने वाले और हम सभी भाग्यशाली रहे। फिर भी, जैसा कि आप
00:18:26बहुत से लोग जो नहीं जानते कि वे क्या कर रहे हैं और AI ऐसे हमलों को चलाने में मदद करता है तो हाँ यह वही है जो
00:18:32अभी चल रहा है यदि आपको ज़रूरत नहीं है तो शायद अभी कुछ भी इंस्टॉल न करें अपने सेटअप की दोबारा जाँच करें और
00:18:41यदि आप गहराई से जानना चाहते हैं यदि आप प्रभावित पैकेजों की पूरी सूची देखना चाहते हैं तो आपको सभी लिंक नीचे मिल जाएँगे
00:18:49आदि।
00:18:56प्रभावित होने का खतरा; यह हमला फिर से जल्दी पकड़ लिया गया था और फिर भी यह अभी भी फैल रहा है
00:19:05इसलिए यह अभी खत्म नहीं हुआ है और यह संभव है कि भविष्य में सभी हमले इतनी जल्दी न पकड़े जाएँ
00:19:11जैसा कि बताया गया है कि वे यहाँ थोड़े भाग्यशाली रहे, इस हमले का पता लगाना और भी कठिन हो सकता था
00:19:18तो शायद नुकसान और भी बड़ा होता लेकिन यह यहाँ पहले से ही काफी बड़ा है और
00:19:24यह अभी खत्म नहीं हुआ है और हम ऐसे और भी हमले देखेंगे मुझे यकीन है क्योंकि मैंने बताया कि हमले की सतह
00:19:31बड़ी और अधिक दिलचस्प होती जा रही है; यहाँ और भी लोग कोड लिख रहे हैं, बहुत से लोग ऐसे हैं जो
00:19:36नहीं जानते कि वे क्या कर रहे हैं और AI ऐसे हमलों को चलाने में मदद करता है, तो हाँ यही सब
00:19:42अभी चल रहा है; यदि ज़रूरी न हो तो शायद अभी कुछ भी इंस्टॉल न करें, अपने सेटअप की दोबारा जाँच करें और
00:19:48यदि आप गहराई से जानना चाहते हैं, यदि आप प्रभावित पैकेजों की पूरी सूची देखना चाहते हैं, तो
00:19:51आपको सभी लिंक नीचे मिल जाएँगे।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video