हमने सचमुच एक बड़े खतरे से बचाव किया

 (xeiaso.net)
1 पॉइंट द्वारा GN⁺ 2025-09-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल ही में NPM package ecosystem में हुआ supply chain attack वास्तव में कहीं बड़ा नुकसान पहुंचा सकता था
  • हमलावरों ने लोकप्रिय libraries का दुरुपयोग किया, लेकिन malware का इस्तेमाल केवल cryptocurrency wallet address बदलने तक सीमित रखा
  • यह हमला बेहद परिष्कृत phishing emails के जरिए developers की 2FA credentials चुराने के तरीके से किया गया
  • अगर इसका इस्तेमाल अधिक घातक रूप में होता, जैसे API keys की चोरी के लिए, तो भारी नुकसान संभव था
  • यह इस बात पर जोर देता है कि हर dependency संभावित रूप से जोखिमभरी है, और पूरे dependency tree को समझना कितना महत्वपूर्ण है

हमले का सार और चिंता

  • हाल ही में सबसे बड़े package ecosystems में से एक, NPM में लोकप्रिय packages हमले की चपेट में आए
    • उदाहरण के तौर पर: terminal color handling, color name-RGB mapping, function debugging decorators, array-जैसी values की पहचान करने वाली utilities आदि
  • ऐसी सामान्य dependencies बहुत व्यापक रूप से इस्तेमाल होती हैं, और जैसे ही code अंदर आता है, उसके सीधे production environment में deploy होने की संभावना काफी अधिक होती है
  • अगर इसमें malicious proxy, API key theft, या अन्य गंभीर हमले शामिल होते, तो नतीजे कहीं ज्यादा गंभीर हो सकते थे
  • लेकिन वास्तविकता में यह malware केवल online wallets (जैसे MetaMask) में cryptocurrency payment addresses को बदलने का काम कर रहा था

phishing हमले की परिष्कृतता

  • हमले की शुरुआत बहुत अच्छी तरह तैयार किए गए phishing email से हुई
    • NPM username का उपयोग करके उसे व्यक्तिगत संदेश जैसा दिखाया गया
    • "सुरक्षा के लिए password और 2FA credentials बदलें" जैसे संदेश से भरोसा पैदा किया गया
    • NPM के कुछ असामान्य operational patterns के कारण, सामान्य उपयोगकर्ता के लिए इसमें फंसना आसान था
    • एक निश्चित deadline देकर urgency पैदा की गई, ताकि व्यस्त स्थिति में लापरवाही से phishing link पर क्लिक कराया जा सके
    • NPM के आधिकारिक domain जैसा दिखने वाला .help domain इस्तेमाल किया गया
  • सबसे अलग दिखने वाली बात बस इतनी थी कि आधिकारिक domain की जगह "npmjs.help" इस्तेमाल किया गया
    • आजकल कई नए gTLD (Generic Top Level Domain) blogs और documentation में व्यापक रूप से उपयोग हो रहे हैं, इसलिए यह भी स्वाभाविक लग सकता है

हमले से होने वाला संभावित नुकसान

  • phishing email के जरिए उपयोगकर्ता की 2FA जानकारी चुराने के बाद, हमलावर attack code डालकर नए package versions publish कर सकते थे
  • is-arrayish, color-string, color-name जैसी बेहद व्यापक रूप से इस्तेमाल होने वाली libraries इसका लक्ष्य थीं
    • अगर malware केवल crypto hijacking तक सीमित न रहकर API key theft तक बढ़ गया होता, तो परिणाम विनाशकारी हो सकते थे
    • उदाहरण के लिए OpenAI, AWS API keys का बड़े पैमाने पर exposure, जिससे लंबी अवधि और बड़े स्तर का नुकसान हो सकता था
  • वास्तव में, संक्रमित अधिकतर libraries मुख्यतः command-line tools में उपयोग होती हैं, इसलिए cryptocurrency theft का उद्देश्य उतना ही सीमित रहा

Web3 ecosystem को निशाना बनाना और हमलावरों की रणनीति

  • यह हमला संभवतः Web3 users को मुख्य target बनाकर किया गया था
    • Web3 से असंबंधित सामान्य-purpose libraries को target बनाकर, हमलावरों ने Web3 ecosystem में तेज पहचान और block होने की संभावना से बचाव किया
    • उदाहरण: भले ही MetaMask से जुड़ी libraries की सावधानी से जांच की जाए, text color utilities में हमला होगा यह अनुमान लगाना मुश्किल है

developer ecosystem के लिए सबक

  • यह घटना इस बात को रेखांकित करती है कि हर dependency package वास्तव में malicious हो सकता है
    • dependency tree को हमेशा पूरी तरह control या monitor करना व्यावहारिक रूप से कठिन है
    • तेज production deployment flow और समय के दबाव में security review पीछे छूट सकती है
  • आगे चलकर project की पूरी dependency संरचना को समझना और उसका सावधानी से प्रबंधन करना और भी महत्वपूर्ण होगा

समापन और सूचना

  • यह सामग्री किसी विशेष व्यक्ति को दोष देने या जिम्मेदार ठहराने के लिए नहीं है; महत्वपूर्ण बात यह समझना है कि कोई भी phishing attack का शिकार हो सकता है
  • इस पोस्ट के प्रकाशित होने के बाद स्थिति बदल सकती है, इसलिए यदि किसी तथ्य पर संदेह हो या गलती दिखे तो सीधे सत्यापन करना चाहिए

Tags:

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-10
Hacker News की राय

  • nx npm सप्लाई चेन हमला ऐसी गोली थी जिससे कई कंपनियाँ बच नहीं पातीं; सिर्फ VS Code nx प्लगइन इंस्टॉल होने पर भी वह npm से अपने-आप latest nx version चेक करता था, और अगर Github session (जैसे GH CLI से company account login) या .env file में महत्वपूर्ण credentials हों तो सब लीक हो सकते थे। यह ऐसी चीज़ थी जिसे dependency pinning या security updates को अच्छी तरह manage करने पर भी टाला नहीं जा सकता था। इस ecosystem में बुनियादी स्तर पर और गहरे बदलाव की ज़रूरत है। अधिक जानकारी के लिए official security advisory देखें

    • मैं NPM से जुड़ी लगभग हर चीज़ से बचता हूँ; सिर्फ typescript compiler अपवाद के रूप में इस्तेमाल करता हूँ, लेकिन अगर वह Go में rewrite हो जाए तो उसे भी हटाने की योजना है। Go में minimum version specify करने की सुविधा है, और downloaded चीज़ों को compile process के दौरान कभी execute नहीं किया जाता, यह इसकी बड़ी खासियत है। NPM में अक्सर source github वाले source से अलग होता है, इसलिए मैं उसे भरोसेमंद नहीं मानता
    • editor extensions high-risk development environments में auto-update और install हो जाती हैं, इसलिए वे बहुत आकर्षक attack target हैं। हैरानी होती है कि browser extensions की तरह अभी तक इनका बड़े पैमाने पर hostile takeover क्यों नहीं हुआ। सुना है VsCode team malicious software detection पर काफी मेहनत करती है, लेकिन सोचता हूँ कि क्या Sublime जैसे सभी editors में भी ऐसा verification process होता है
    • मैं सभी packages और databases local रखता हूँ, और development machine पर airplane mode में काम करता हूँ; सिर्फ git push करते समय ही internet connection चालू करता हूँ

  • हम सचमुच बाल-बाल बचे। यकीन नहीं होता कि ऐसे package तक पहुँच रखने वाले attacker ने सिर्फ एक cryptocurrency-stealing tool ही डाला। अगर यह इतना बड़ा मौका था, तो एक हफ्ता और लगाकर कुछ ज्यादा sophisticated exploit डालना ज़्यादा फायदेमंद लगता—API keys, SSH public key जोड़ना, server IP leak करना, developer devices के browser profiles या session tokens, यहाँ तक कि मेरे desktop में सेव Amazon card details तक, चोरी करने के लिए बहुत कुछ है। भले वे खुद इसका इस्तेमाल न करें, dark web forums पर यह सब आसानी से बेचा जा सकता है। कभी-कभी सोचता हूँ, क्या skilled cybercriminals पहले से ही stable, high-paying tech companies में काम कर रहे हैं, इसलिए सिर्फ ऐसे साधारण हमले ही बचे हैं?

    • क्योंकि यह attack method जल्दी पकड़ में आना तय था, इसलिए लगता है stealthy approach की बजाय पूरा account takeover, यानी तेज़ "hit and run" strategy चुनी गई। कुछ घंटों के भीतर automation से सबसे ज़्यादा पैसा जल्दी निकालने का तरीका चाहिए था, और cryptocurrency इसका साफ जवाब है। अगर backdoor इतना मजबूत न हो कि आधी दुनिया code खंगालने पर भी उसे न पकड़ सके, तो ज्यादा लंबी तैयारी का कोई मतलब नहीं था
    • चोरी की गई cryptocurrency ऐसी asset है जिसे transaction reversal, refund, या recovery के जरिए वापस नहीं लिया जा सकता, इसलिए व्यावहारिक रूप से यह पक्का हासिल होने वाला पैसा है। दूसरी तरफ developer की API या SSH keys की लगभग कोई कीमत नहीं होती, और अगर कभी उनसे कुछ कमाई हो भी जाए, तो आखिरकार उसे cash out करने के लिए cryptocurrency में ही बदलना पड़ेगा
    • जल्दी घुसो, लाखों डॉलर चुराओ, निकल जाओ, और कुछ महीनों बाद वही काम दोबारा करो—अगर इस तरह police से बचते रहो तो जिंदगी भर बेफिक्र जिया जा सकता है। AWS keys जैसी चीज़ें चुराने से उतना बड़ा फायदा नहीं होता। कुछ अपराधी cryptocurrency के अलावा passwords या password manager databases को भी निशाना बनाते हैं, लेकिन अंत में वे भी अक्सर cryptocurrency-related sites को target करते हैं। अभी भी ऐसे अपराधी होंगे जो किसी company में सावधानी से घुसपैठ करने के सही समय का इंतजार कर रहे होंगे, और वे सफल होने तक छिपे रहेंगे
    • यह कोई जीवन में एक बार मिलने वाला मौका नहीं है। आगे अपराधी यह समझ जाएँगे कि सिर्फ कुछ "developers" को निशाना बनाकर ही वे आसानी से millions of dollars तक पहुँच सकते हैं, और फिर और भी साहसी तरीके सामने आएँगे। अगर आप open source code maintainer हैं, तो आपको गंभीरता से सोचना चाहिए कि आप online अपनी physical identity को कितना अच्छी तरह छिपा रहे हैं

  • मेरे लिए टालमटोल एक survival skill है। मैं तब तक इंतजार करता हूँ जब तक दूसरे लोग beta testing कर लें; पहले मैं company में 12 साल तक सिर्फ Microsoft Office 2000 ही इस्तेमाल करता रहा, और upgrade से जुड़ी समस्याओं या retraining के बिना 10 साल शांति से गुज़ारे। और मेरी एक आदत है कि मैं email में आए links पर कभी click नहीं करता

    • मेरी Honda और Kubernetes के साथ भी यही रवैया है। मैंने 2006 model की car लंबे समय तक रखी, इसलिए car-phone integration की कई पीढ़ियों की छोटी-बड़ी समस्याएँ टल गईं; अभी हाल में ही 2023 model car में iPhone connection बहुत smooth हुआ है। Kubernetes के साथ भी यही हुआ—boss के कहने पर लंबे समय तक टालते रहने की वजह से अब, जब EKS, GKE वगैरह काफी mature हो चुके हैं, migration में झेलने वाली मुश्किलें बहुत कम हो गई हैं। अगर 6–7 साल पहले ही मान लिया होता, तो शायद बहुत बेकार की मेहनत करनी पड़ती
    • npm ecosystem में अगर आप हर 54 सेकंड में update नहीं करते, तो आप पहले ही बहुत पीछे छूट चुके होते हैं
    • यह नए malicious packages के खिलाफ तो असरदार है, लेकिन अगर पहले से infected software पर worm भी लग जाए, तो यह काम नहीं आता
    • मैं कल जवाब दूँगा
    • "नया version आने पर default रूप से 2 हफ्ते तक उसे इस्तेमाल न करना" सप्लाई चेन attacks के खिलाफ बहुत प्रभावी बचाव है

  • छोटी startups के लिए यह मुश्किल होगा, लेकिन npm जैसे बड़े players को "npm.io", "npm.sh", "npm.help" जैसी npm domain की सभी TLD versions पहले से register कर लेनी चाहिए। Attacker द्वारा "npm.help" domain पर कब्ज़ा कर लेने से यह हमला और प्रभावी हो गया

    • AWS जैसी कंपनियाँ ग्राहकों से phishing से सावधान रहने को कहती हैं, लेकिन खुद official billing email address को no-reply-aws@amazon.com से बदलकर no-reply@tax-and-invoicing.us-east-1.amazonaws.com जैसा कर देती हैं। पहली बार देखने पर यह लगभग phishing mail जैसा लगता है, लेकिन official कहा जाता है, इसलिए भ्रम पैदा होता है। यहाँ तक कि पहले भेजा गया notice email भी phishing जैसा दिखता है, इसलिए असली invoice मिलने तक PDF attachment खोलने में भी संदेह होता है। कंपनियाँ ग्राहकों को phishing से सावधान रहने को कहती हैं, लेकिन खुद बेवजह confusion पैदा करती हैं
    • 1,500 से ज़्यादा TLD हैं, और भले कुछ restricted हों या country-code type के हों, फिर भी सोचता हूँ कि इन सबको register करने की वास्तविक annual cost कितनी होगी। शायद इसे SaaS के रूप में manage करने वाली services भी होंगी
    • TLD list देखकर लगता है कि domains बहुत ज़्यादा हैं, और बड़े vendors भी चाहे phishing रोकने के लिए समान TLDs को पहले से लेने की कोशिश करें, फिर भी इसे पूरी तरह block नहीं किया जा सकता
    • सबसे पहले यह verify करना चाहिए कि domain सचमुच official है या नहीं। हाल में register हुआ cheap domain (registrar) हो, या जिसका expiry बहुत नज़दीक हो, तो मैं उसे तुरंत suspicious मानता हूँ। खासकर अगर link में deadline जैसी बातों पर जोर देकर "समय नहीं है" वाला दबाव बनाया जा रहा हो, तो मैं और गहराई से जाँच करता हूँ। मेरा मानना है कि official communication सिर्फ well-known primary domain (या उसके subdomain) से ही होनी चाहिए
    • npm और उससे मिलते-जुलते domain naming patterns के variants का कोई अंत नहीं है, इसलिए सबको पहले से register करके इसे व्यवहारिक रूप से रोका नहीं जा सकता। सिर्फ domain name देखकर phishing का शक हो जाना चाहिए, लेकिन npmjs.help जैसे domains भी गलती से click हो ही जाते हैं

  • अगर कोई बहुत ही धैर्यपूर्ण योजना (Jia Tan style) को हमारी ढीली security (editor plugins, shell userland वगैरह) के साथ जोड़ दे तो? Developer tools superuser privileges के साथ चलते हैं, लेकिन उनकी verification सबसे कम होती है। मैं भी elisp, neovim, vscode, यहाँ तक कि छोटे userland tools तक को एक-एक करके verify नहीं कर सकता; best case में बस nixpkgs से ले लेता हूँ। किसी दिन कोई और बेहतर VSCode plugin बना दे और 1–2 साल इंतजार करे, फिर खेल खत्म। GG

    • उम्मीद है कि किसी दिन कोई xkcd 1200 वाली समस्या को सचमुच हल करेगा

  • MetaMask जैसे wallets target थे, लेकिन सुना है कि MetaMask LavaMoat नाम के isolation module की वजह से इस तरह के attacks से काफी हद तक सुरक्षित है। इसकी वास्तविक protection level पर कोई detailed analysis हो तो सच में पढ़ना चाहूँगा। मेरा MetaMask से व्यक्तिगत रूप से कोई संबंध नहीं है, लेकिन ऐसे security countermeasures (जो real attacks की तुलना में धीरे लागू होते हैं) कितने असरदार हैं, यह जानने में दिलचस्पी है। संदर्भ के लिए related article जोड़ रहा हूँ

  • "सच्चाई यह है कि ऐसे phishing attacks में आप कभी न कभी फँस ही जाएँगे"—इस बात पर मुझे अपने बारे में ऐसा नहीं लगता। मेरी आदत है कि जिस email को मैंने खुद initiate नहीं किया, उसके link पर मैं कभी credentials नहीं डालता (जैसे password reset वगैरह)। मुझे लगता है कि 2025 तक यह हर किसी के लिए ज़रूरी security skill होनी चाहिए

    • इसे "'ऐसे' phishing attack" कहने से लगता है जैसे कोई sophisticated हमला था, लेकिन असल में यह फिर से एक developer के बहुत साधारण phishing mail में फँसने का मामला था। यह बेहद बुनियादी गलती है, और कभी-कभी तो admin staff भी इसमें नहीं फँसेगा। हाँ, हर कोई गलती कर सकता है, लेकिन मुझे लगता है कि साफ लापरवाही और amateur-level mistakes ऐसी घटनाओं को बार-बार होने देती हैं

  • लेख में कहा गया है कि "सारे malware ने सिर्फ cryptocurrency wallet addresses को replace किया", लेकिन MetaMask प्रभावित क्यों नहीं हुआ, इसके कारण थे:

  1. attack के समय package तुरंत update नहीं हुआ था
  2. MetaMask install और runtime, दोनों stages पर LavaMoat से protected था। दूसरी तरफ यह malicious payload उन web pages को target करना चाहता था जो MetaMask के साथ interact करने वाले दूसरे wallets इस्तेमाल करते हैं। संदर्भ के लिए, मैंने LavaMoat development में हिस्सा लिया है। अधिक जानकारी के लिए LavaMoat GitHub देखें

  • बड़े open package repositories को कहीं ज़्यादा मजबूत security solutions चाहिए, या कम से कम highly trusted, reviewed core packages का कोई set होना चाहिए। Python, Rust ecosystems वगैरह भी इसी तरह trust पर चल रहे हैं

    • npm की बुनियादी समस्या है namespace enforcement का न होना। Java के Maven में beginners अक्सर शिकायत करते हैं कि "यह npm जितना आसान क्यों नहीं है", लेकिन समय के साथ Maven के namespace system जैसी quality control के प्रति उसकी obsession और ज़्यादा सराहनीय लगती है। POM xml असुविधाजनक ज़रूर है, लेकिन conservative change management भरोसा देता है। संबंधित लेख: public open source repositories में namespacing क्यों महत्वपूर्ण है
    • इस मामले की तरह अगर package maintainer का account ही compromise हो जाए, तो namespace जैसी structural protections भी बेअसर हो जाती हैं। एकमात्र समाधान यही है कि नए releases तुरंत apply न हों, बल्कि delay किए जाएँ
    • Linux distributions भी trust-based हैं, लेकिन package publish करने का अधिकार पाने से पहले trust को "prove" करना पड़ता है, और पूरा trust verification system मौजूद होता है। NPM तो मानो ऐसा खुला सिस्टम है जहाँ कोई भी कुछ भी publish कर सकता है

  • "इसे रोकने का कोई तरीका नहीं" जैसी बात सिर्फ उसी ecosystem से आती है जहाँ सबसे ज़्यादा breaches होते हैं

    • बिल्कुल यही असली समस्या है; यह बहुत आलसी निष्कर्ष है