इस हफ्ते एक फर्जी क्लाइंट ने मेरे इनबॉक्स में एक दुर्भावनापूर्ण (malicious) GitHub रिपॉजिटरी भेज दी, और सिर्फ स्टार्टर स्क्रिप्ट चलाने से दो दिनों का काम बर्बाद हो गया और मेरे ब्राउज़र में सेव किए गए सभी पासवर्ड उजागर हो गए।
उस "क्लाइंट" ने एक हाई-पेइंग सीनियर-इंजीनियर रोल पोस्ट किया, तुरंत मैसेज किया और एक बहुत ही प्रोफेशनल दिखने वाली रिपॉजिटरी भेजी। अनुरोध सीधा था: क्लोन करें, npm run dev चलाएं, और यह साबित करने के लिए एक स्क्रीनशॉट भेजें कि डेमो काम कर रहा है—कोई कॉन्ट्रैक्ट नहीं, कोई बैकग्राउंड चेक नहीं। जैसे ही डेव सर्वर शुरू हुआ, एक कॉन्फ़िगरेशन फ़ाइल में छिपे कोड ने कमांड-एंड-कंट्रोल (C2) सर्वर से संपर्क किया, दूसरा-चरण का पेलोड (second-stage payload) प्राप्त किया और लोकल मशीन से क्रेडेंशियल्स (credentials) चुराना शुरू कर दिया।
हमला कैसे हुआ
वह दुर्भावनापूर्ण पेलोड postcss.config.js में था, एक ऐसी फ़ाइल जिसे अधिकांश डेवलपर्स बस एक नज़र देखकर छोड़ देते हैं क्योंकि इसमें आमतौर पर कुछ साधारण CSS प्रोसेसिंग नियम होते हैं। इस मामले में, हमलावर ने एक वैध स्टेटमेंट के काफी दाईं ओर अस्पष्ट (obfuscated) JavaScript की एक लाइन जोड़ दी थी, जिसे घुलने-मिलने के लिए स्पेस (spaces) के साथ छिपाया गया था। जब npm run dev कमांड ने PostCSS पाइपलाइन को चलाया, तो वह छिपी हुई लाइन बिना किसी के ध्यान में आए चल गई।
मैलवेयर ने तेजी से तीन कदम उठाए:
- C2 संपर्क – इसने हमलावर के नियंत्रण वाले सर्वर के साथ एक नेटवर्क कनेक्शन खोला और प्रभावित होस्ट (compromised host) की जानकारी दी।
- सेकंड-स्टेज डाउनलोड – इसने अतिरिक्त कोड डाउनलोड किया जिसमें असली डेटा-एक्सफ़िल्ट्रेशन (data-exfiltration) लॉजिक था।
- ब्राउज़र क्रेडेंशियल चोरी – macOS पर इसने सिस्टम की कीचेन (keychain) में स्टोर की गई Chrome Safe Storage की (key) को क्वेरी किया। यदि उपयोगकर्ता ने कीचेन प्रॉम्प्ट को अनुमति दे दी, तो हमलावर ने Chrome में सेव किए गए हर पासवर्ड को चुरा लिया।
तत्काल चोरी के अलावा, पेलोड ने खुद को कई सामान्य डेवलपर टूल्स—VS Code, npm, Discord—में लिख दिया, ताकि उन एप्लिकेशन को भविष्य में कभी भी चलाने पर वह दुर्भावनापूर्ण कोड फिर से सक्रिय हो जाए। केवल रीबूट करने से संक्रमण (infection) खत्म नहीं हुआ; अगली बार npm install करने या एडिटर खोलने पर वह बैकडोर फिर से जीवित हो गया।
खतरे के संकेत (Red flags) जिन्हें अक्सर अनदेखा कर दिया जाता है
- कोई कॉन्ट्रैक्ट साइन होने से पहले कोड चलाने का अनुरोध करना। वैध भर्ती प्रक्रियाओं में आमतौर पर किसी भी प्रोप्रायटरी (proprietary) काम को साझा करने से पहले एक औपचारिक समझौता शामिल होता है।
- "प्रोजेक्ट ब्रीफ" के रूप में छिपकर भेजी गई कंप्रेस्ड फ़ाइलें। Zip या RAR आर्काइव्स में एक्जीक्यूटेबल स्क्रिप्ट या दुर्भावनापूर्ण बाइनरी छिपी हो सकती हैं।
- "प्लेटफ़ॉर्म फ़िल्टर को बायपास करने" के लिए व्यक्तिगत ईमेल पते मांगना। यह चाल बातचीत को सुरक्षित प्लेटफ़ॉर्म से बाहर ले जाने के लिए होती है ताकि दुरुपयोग की रिपोर्ट न की जा सके।
- ऐसी जॉब डिस्क्रिप्शन जिनमें उम्मीदवार से क्रिप्टो वॉलेट में फंड डालने या टेस्ट टोकन खरीदने के लिए कहा जाए। वास्तविक डेवलपमेंट वर्क के लिए ऐसे दावे असामान्य होते हैं।
सुरक्षित रहने के व्यावहारिक कदम
- बिना जांच किए कभी भी किसी अजनबी का कोड न चलाएं। रिपॉजिटरी को रीड-ओनली व्यू (जैसे GitHub पर raw file view के माध्यम से) में खोलें और हर स्क्रिप्ट, विशेष रूप से कॉन्फ़िगरेशन फ़ाइलों और
package.jsonकेscriptsएंट्रीज़ को स्कैन करें। - सभी अटैचमेंट को प्लेन टेक्स्ट की तरह समझें। यदि कोई zip फ़ाइल भेजी जाती है, तो उसे सैंडबॉक्स्ड (sandboxed) वातावरण में एक्सट्रैक्ट करें और कुछ भी खोलने से पहले उसकी सामग्री की जांच करें।
- ब्राउज़र स्टोरेज के बजाय एक समर्पित पासवर्ड मैनेजर का उपयोग करें। यदि ब्राउज़र की कीचेन से समझौता हो भी जाए, तो भी मैनेजर का वॉल्ट (vault) अलग और सुरक्षित रहता है।
- अविश्वसनीय कोड को बिना नेटवर्क एक्सेस वाले एक आइसोलेटेड वर्चुअल मशीन या कंटेनर में चलाएं। यह हमलावर की C2 सर्वर तक पहुँचने की क्षमता को रोकता है।
- सभी अकाउंट्स पर टू-फैक्टर ऑथेंटिकेशन (2FA) सक्षम करें। यदि पासवर्ड चोरी हो जाता है, तो दूसरा फैक्टर अनधिकृत लॉगिन को रोकता है।
- डेवलपर टूल्स को अपडेट रखें और जहाँ उपलब्ध हो वहाँ ऑटोमैटिक इंटीग्रिटी चेक सक्षम करें। कुछ एडिटर्स अब चेतावनी देते हैं जब कोर फ़ाइलों में अप्रत्याशित रूप से बदलाव किया जाता है।
यदि आपको संदेह है कि आपने कोई दुर्भावनापूर्ण कोड चलाया है, तो मान लें कि सिस्टम से समझौता हो गया है। ज़रूरी डेटा का बैकअप लें, ड्राइव को वाइप (wipe) करें और ऑपरेटिंग सिस्टम को फिर से इंस्टॉल करें। केवल रीबूट करने से उस परसिस्टेंस मैकेनिज्म (persistence mechanism) को खत्म नहीं किया जा सकता जो सामान्य ऐप्स में फ़ाइलों को फिर से लिख देता है।
निष्कर्ष: जावास्क्रिप्ट की एक छिपी हुई लाइन एक सामान्य डेमो को बड़े पैमाने पर क्रेडेंशियल चोरी के ऑपरेशन में बदल सकती है। जब तक आप किसी रिपॉजिटरी को सत्यापित न कर लें, तब तक उसे अविश्वसनीय ही मानें, और आइसोलेशन (isolation) को अपने वर्कफ़्लो का डिफ़ॉल्ट हिस्सा बनाएं। एक पल की जल्दबाजी की कीमत फ़ाइल को दोबारा जांचने में लगने वाले प्रयास से कहीं अधिक हो सकती है।