Security Blog

कटाई के लिए कुछ भी नहीं होना चाहिए

#160

October 2, 2026 · By Marketing team

← All posts

एक समझौता किए गए Bitwarden CLI ने 334 डेवलपर मशीनों से SSH कुंजियाँ, क्लाउड क्रेडेंशियल और npm टोकन चुराए। असली समस्या यह नहीं है कि मैलवेयर अंदर कैसे आया। असली समस्या यह है कि हर गुप्त कुंजी सादी फ़ाइल के रूप में वहाँ पड़ी थी, पढ़े जाने की प्रतीक्षा में।

कल, Bitwarden के CLI के एक समझौता किए गए संस्करण ने 334 डेवलपर मशीनों से SSH कुंजियाँ, AWS क्रेडेंशियल, npm टोकन, एनवायरनमेंट वेरिएबल, शेल हिस्ट्री और Git गुप्त कुंजियाँ चुराईं।

आज Bitwarden था। पिछले महीने Axios था। उससे पहले Checkmarx। कल कोई VS Code एक्सटेंशन होगा, या Acrobat, या कोई Homebrew फ़ॉर्मूला, या कोई Docker इमेज। वेक्टर हर हफ़्ते बदलता है। नतीजा हमेशा एक जैसा रहता है।

मैलवेयर उतरता है। वह ~/.ssh/ पढ़ता है। वह ~/.aws/credentials पढ़ता है। वह ~/.npmrc पढ़ता है। वह ~/.git-credentials पढ़ता है। वह शेल हिस्ट्री, एनवायरनमेंट वेरिएबल, ब्राउज़र पासवर्ड स्टोर पढ़ता है। वह सब कुछ पैक करके एक C2 सर्वर पर भेज देता है।

और यह काम करता है। हर बार।

कटाई

Bitwarden का पेलोड — bw1.js नाम की 10 MB की एक अस्पष्ट (obfuscated) फ़ाइल — ने किसी एन्क्रिप्शन को तोड़ने की कोशिश नहीं की। उसे ज़रूरत भी नहीं थी। Socket और Aikido के दस्तावेज़ों के अनुसार, उसने यह सब इकट्ठा किया:

  • SSH कुंजियाँ और होस्ट फ़िंगरप्रिंट
  • AWS, GCP और Azure क्लाउड क्रेडेंशियल
  • npm प्रमाणीकरण टोकन
  • Git क्रेडेंशियल और रिमोट URL
  • एनवायरनमेंट वेरिएबल
  • शेल हिस्ट्री
  • Claude Code प्रमाणीकरण और MCP कॉन्फ़िगरेशन

फिर उसने चुराए गए npm टोकन का उपयोग करके पीड़ित द्वारा बनाए गए अन्य पैकेज दोबारा प्रकाशित किए और खुद को और फैलाया। पीड़ित वाहक बन गए।

इसमें से किसी के लिए भी एन्क्रिप्शन तोड़ने की ज़रूरत नहीं थी। इनमें से हर गुप्त कुंजी फ़ाइल सिस्टम पर एक फ़ाइल थी, जिसे उपयोगकर्ता के रूप में चलने वाला कोई भी प्रोसेस पढ़ सकता था।

यह Bitwarden की कहानी नहीं है

Bitwarden के वॉल्ट एन्क्रिप्शन में सेंध नहीं लगी। उनका ज़ीरो-नॉलेज आर्किटेक्चर कायम रहा। मैलवेयर ने वॉल्ट को छुआ तक नहीं।

उसे छूने की ज़रूरत भी नहीं थी।

वॉल्ट अपने भीतर की चीज़ों की रक्षा करता है। लेकिन SSH कुंजियाँ कभी वॉल्ट में नहीं थीं। AWS क्रेडेंशियल कभी वॉल्ट में नहीं थे। npm टोकन, Git क्रेडेंशियल, .env फ़ाइलों में API कुंजियाँ — इनमें से कोई भी पासवर्ड मैनेजर में नहीं रहता। ये डॉटफ़ाइलों में रहते हैं, सादे पाठ (plaintext) के रूप में, हर डेवलपर की मशीन पर।

हमलावर ने इसे समझा। वॉल्ट एक ऐसे घर में बंद तिजोरी है जहाँ हर दराज़ खुला हुआ है।

असली हमला-सतह

अभी एक टर्मिनल खोलिए। देखिए आपकी मशीन पर क्या पड़ा है।

~/.ssh/id_ed25519 — आपकी निजी कुंजी। सादी पाठ फ़ाइल।

~/.aws/credentials — आपकी क्लाउड पहुँच। सादी पाठ फ़ाइल।

~/.npmrc — आपका प्रकाशन टोकन। सादी पाठ फ़ाइल।

~/.git-credentials — आपकी रिपॉज़िटरी पहुँच। सादी पाठ फ़ाइल।

एक दर्जन प्रोजेक्ट निर्देशिकाओं में ~/.env — API कुंजियाँ, डेटाबेस पासवर्ड, साइनिंग गुप्त कुंजियाँ। सब सादी पाठ फ़ाइलें।

आपके उपयोगकर्ता के रूप में चलने वाला कोई भी प्रोसेस इन सबको पढ़ सकता है। किसी विशेषाधिकार वृद्धि (privilege escalation) की ज़रूरत नहीं। किसी शोषण (exploit) की ज़रूरत नहीं। बस cat।

2026 में यही डेवलपर की डिफ़ॉल्ट स्थिति है। हम अपने पासवर्ड एन्क्रिप्टेड वॉल्ट में रखते हैं और बाकी सब कुछ खुला छोड़ देते हैं।

ग़लत सवाल

हर सप्लाई चेन हमले के बाद उद्योग वही सवाल पूछता है: मैलवेयर को अंदर आने से कैसे रोकें?

बेहतर CI/CD सुरक्षा। कोड साइनिंग। डिपेंडेंसी स्कैनिंग। सैंडबॉक्स्ड रनटाइम। ये सब अच्छे हैं। इनमें से कोई भी पर्याप्त नहीं है। हमला-सतह बहुत व्यापक है। वेक्टर बहुत ज़्यादा हैं — पैकेज मैनेजर, ब्राउज़र एक्सटेंशन, IDE प्लगइन, OAuth ऐप्स, समझौता किए गए बिल्ड टूल। आप हर प्रवेश बिंदु को सील नहीं कर सकते।

सही सवाल यह है: जब मैलवेयर अनिवार्य रूप से किसी डेवलपर की मशीन पर निष्पादन प्राप्त कर लेता है, तो उसे क्या मिलता है?

अगर जवाब है "अनुमानित फ़ाइल सिस्टम स्थानों पर सैकड़ों सादी पाठ क्रेडेंशियल," तो कितनी भी सप्लाई चेन कड़ी कर लीजिए, कोई फ़र्क़ नहीं पड़ता। आप ऐसे मैदान में रक्षा खेल रहे हैं जहाँ आपके पीछे का गोल खुला पड़ा है।

कटाई के लिए कुछ भी नहीं होना चाहिए

समाधान बेहतर मैलवेयर पहचान नहीं है। समाधान npm install को सैंडबॉक्स करना नहीं है। समाधान तेज़ घटना-प्रतिक्रिया समय नहीं है।

समाधान यह है: गुप्त कुंजियाँ डिस्क पर फ़ाइलों के रूप में अस्तित्व में नहीं होनी चाहिए।

प्रमाणीकरण के क्षण पर हार्डवेयर से व्युत्पन्न SSH कुंजियाँ — ~/.ssh/ में संग्रहीत नहीं। हार्डवेयर-बाउंड पहचान से प्रति-सत्र जारी क्लाउड क्रेडेंशियल — ~/.aws/ में लिखे हुए नहीं। सीमित (scoped), क्षणभंगुर (ephemeral) और हार्डवेयर-संरक्षित API टोकन — .env फ़ाइलों में पड़े हुए नहीं।

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

यह सैद्धांतिक नहीं है। हार्डवेयर-बाउंड क्रेडेंशियल आज मौजूद हैं। WebAuthn PRF एक भौतिक प्रमाणक (authenticator) के स्पर्श से क्रिप्टोग्राफ़िक कुंजियाँ व्युत्पन्न कर सकता है — ऐसी कुंजियाँ जो फ़ाइल सिस्टम को कभी नहीं छूतीं। तकनीक यहाँ मौजूद है। उद्योग ने बस इसे डिफ़ॉल्ट के रूप में नहीं अपनाया है।

अभी क्या करें

अगर आप Bitwarden CLI समझौते से प्रभावित हुए हैं:

  • मशीन पर हर क्रेडेंशियल बदलें — SSH कुंजियाँ, क्लाउड टोकन, npm टोकन, API कुंजियाँ, डॉटफ़ाइलों और env वेरिएबल में सब कुछ
  • जाँचें कि आपके बनाए किसी npm पैकेज को दोबारा प्रकाशित तो नहीं किया गया
  • GitHub गतिविधि और CI/CD वर्कफ़्लो में अनधिकृत बदलावों का ऑडिट करें

अगर आप प्रभावित नहीं हुए, तो कार्रवाई वही है। अपनी मशीन देखिए। सादी पाठ गुप्त कुंजियाँ गिनिए। खुद से पूछिए कि क्या होता है जब — अगर नहीं, जब — कोई दुर्भावनापूर्ण चीज़ आपके उपयोगकर्ता के रूप में चलती है।

जवाब होना चाहिए: कुछ नहीं। कटाई के लिए कुछ भी नहीं होना चाहिए।