OpenJS और OpenSSF: ओपन सोर्स परियोजनाओं में social engineering takeover के जोखिम पर चेतावनी जारी
- हालिया XZ Utils बैकडोर प्रयास (CVE-2024-3094) शायद अलग-थलग घटना नहीं है।
- OpenJS Foundation द्वारा समान विश्वसनीय दिखने वाले takeover प्रयासों को रोके जाने से लगता है कि यह सिर्फ एक अकेली घटना नहीं हो सकती।
- OpenSSF और OpenJS Foundation सभी ओपन सोर्स मेंटेनरों से कहते हैं कि वे social engineering takeover प्रयासों के प्रति सतर्क रहें, शुरुआती threat pattern पहचानें और ओपन सोर्स परियोजनाओं की रक्षा के लिए तुरंत कार्रवाई करें।
विफल takeover प्रयास
- OpenJS Foundation Cross Project Council को समान संदेशों वाली संदिग्ध ईमेल श्रृंखला मिली।
- ईमेल भेजने वाले ने लिखा कि "महत्वपूर्ण vulnerabilities को fix करने के लिए" किसी लोकप्रिय JavaScript परियोजना का अपडेट करने हेतु OpenJS को action लेना चाहिए, लेकिन कोई ठोस तकनीकी विवरण नहीं दिया।
- भेजने वाले ने यह भी चाहा कि उसे प्रोजेक्ट का नया maintainer बना दिया जाए, जबकि उसने पहले शायद ही कोई code योगदान किया था।
- यह तरीका XZ/liblzma बैकडोर में "Jia Tan" द्वारा अपनाई गई भूमिका से काफी मिलता-जुलता था।
- OpenJS-hosted परियोजनाओं में इन लोगों को किसी प्रकार का access नहीं दिया गया।
- परियोजनाओं में foundation security working group में उल्लिखित सुरक्षा नीतियाँ पहले से मौजूद हैं।
- OpenJS टीम ने ऐसे ही संदिग्ध pattern दो अन्य लोकप्रिय JavaScript परियोजनाओं (जो OpenJS-hosted नहीं हैं) में भी पहचान लिए और इन्हें संबंधित OpenJS लीडर तथा अमेरिकी DHS की Cybersecurity and Infrastructure Security Agency (CISA) को तुरंत रिपोर्ट किया।
social engineering takeover के संदिग्ध पैटर्न
- पैटर्न
- अपेक्षाकृत अज्ञात community member द्वारा किसी admin या hosting संस्था (foundation या कंपनी) से दोस्ताना लेकिन आक्रामक और लगातार अनुरोध करना
- नए व्यक्ति या अज्ञात व्यक्ति को maintainer की स्थिति में promote करने का आग्रह
- किसी अन्य अज्ञात community member का समर्थन, जो नकली पहचान/फेक identity इस्तेमाल कर सकता हो (जिसे "sock puppets" कहा जाता है)
- PR में artifact के रूप में Blob शामिल करना
- जानबूझकर obfuscated या मुश्किल से समझ आने वाला source code
- धीरे-धीरे बढ़ती हुई security समस्या
- सामान्य project compile/build/deploy प्रथाओं से हटकर Blob, Zip या अन्य binary artifacts में बाहरी malicious payload जोड़ने की कोशिश
- खासकर जब maintainer को urgency के कारण review की कठोरता घटाने या control bypass करने के लिए मजबूर किया जाता है
- ये social engineering attacks परियोजना और community के प्रति maintainer की duty भावना का इस्तेमाल करके इन्हें manipulate करते हैं।
- देखें कि interaction का एहसास कैसा बनता है।
- self-doubt, अपनी क्षमता पर शक, या पर्याप्त योगदान न दे पाने की भावना पैदा करने वाली interaction social engineering attack का हिस्सा हो सकती है।
- XZ/liblzma में देखी गई तरह का social engineering attack OpenJS community द्वारा सफलतापूर्वक रोक लिया गया।
- ऐसी attacks trust-violation के जरिए social engineering पर आधारित होती हैं, इसलिए इन्हें programmatically detect या defend करना कठिन है।
- अल्पकाल में, ऊपर बताए गए संदिग्ध activity को स्पष्ट और पारदर्शी तरीके से share करने से अन्य communities जागरूक रहने में मदद मिलेगी।
- मेंटेनरों को बेहतर तरीके से support करना ऐसे social engineering attacks के खिलाफ मुख्य deterrent है।
ओपन सोर्स परियोजना सुरक्षा के लिए चरण
- OpenSSF गाइड जैसे industry-standard security best practices को follow करने पर विचार करें।
- मजबूत authentication अपनाएँ: 2FA, password manager, recovery codes को सुरक्षित जगह पर रखें, और पासवर्ड/क्रेडेंशियल को अलग-अलग services में reuse न करें।
- सुरक्षा नीति में "Coordinated disclosure" प्रक्रिया शामिल करें।
- नए कोड को merge करते समय best practices लागू करें
- Branch protection और signed commits को सक्रिय करें
- संभव हो तो PR अगर maintainer से आया हो तब भी merge से पहले दूसरा developer कोड review करे
- readability requirements लागू करें ताकि नए PR obfuscate न हों और opaque binaries का उपयोग न्यूनतम रहे
- npm publish अधिकार रखने वालों की संख्या सीमित करें
- committers और maintainers की पहचान रखें और नियमित समीक्षा करें। उदाहरण: working group meetings में मिले हैं, या किसी event में मिले-जुले हैं?
- अगर आप open source package repository run करते हैं तो Package Repository Security के लिए principles अपनाने पर विचार करें।
- CISA का "social engineering और phishing attacks से बचाव" और/या ENISA का "social engineering क्या है" देखें।
प्रमुख ओपन सोर्स इंफ्रास्ट्रक्चर सुरक्षा के लिए उद्योग और सरकार की कार्रवाइयाँ
- स्थिर और सुरक्षित ओपन सोर्स परियोजनाएँ बनाए रखना मेंटेनरों पर काफी दबाव डालता है।
- निजी और सार्वजनिक अंतरराष्ट्रीय सहयोग से बड़े संसाधन जुटाना संभव होगा।
- Open Source Foundations, Sovereign Tech Fund जैसी कई संस्थाएँ पहले से ही उत्कृष्ट काम कर रही हैं।
- ओपन सोर्स परियोजनाओं को सुरक्षा जाल देने के लिए Linux Foundation Family जैसा प्रयास अन्य संस्थाओं की तरफ़ से भी जरूरी है।
- जर्मन सरकार के Sovereign Tech Fund पहल के जरिए महत्वपूर्ण ओपन सोर्स इंफ्रास्ट्रक्चर में निवेश किया जाना उत्साहजनक है।
- वैश्विक सार्वजनिक निवेश बढ़ाने के लिए जर्मनी के Sovereign Tech Fund जैसी पहल को और अधिक global सार्वजनिक निवेश का समर्थन मिलना चाहिए।
GN⁺ की राय
- attackers मेंटेनरों की duty sense का चतुराई से इस्तेमाल करके developers को भ्रमित कर रहे हैं; इसलिए परियोजनाओं में मेंटेनरों की भावनात्मक बदलावों पर भी ध्यान देना जरूरी है।
- सुरक्षा में निवेश बढ़ाने की जरूरत से सहमत हूँ, लेकिन मूल रूप से विकास संस्कृति को security-first दिशा में बदलना होगा। हर development चरण में security स्वाभाविक रूप से घुलनी चाहिए।
- attackers समुदाय के trust का उपयोग करते हैं, इसलिए ओपन सोर्स परियोजनाओं में सदस्यों के बीच trust लगातार build करने और मजबूत करने के प्रयास भी साथ-साथ होने चाहिए। सीधे आमने-सामने बातचीत शायद इसकी शुरुआत हो सकती है।
- Alpha-Omega परियोजना की तरह वास्तविक vulnerability सुधार में निवेश करने वाले अधिक प्रोजेक्ट बनने और सहयोग मिलने चाहिए ताकि ओपन सोर्स परियोजनाओं की वास्तविक सुरक्षा स्तर सच में बढ़ सके।
1 टिप्पणियां
Hacker News टिप्पणी
सारांश: