ओपनएसएसएल कंप्यूटर नेटवर्क पर सुरक्षित संचार लागू करने के लिए व्यापक रूप से उपयोग की जाने वाली ओपन-सोर्स सॉफ़्टवेयर लाइब्रेरी है। कितना व्यापक रूप से उपयोग किया जाता है? खैर, संभावना यह है कि यदि आपने कभी HTTPS वेब पेज एक्सेस किया है तो आपने ऐसा ओपनएसएसएल एन्क्रिप्शन के माध्यम से किया है। लाइब्रेरी डेटा एन्क्रिप्शन, डिक्रिप्शन, प्रमाणीकरण और डिजिटल हस्ताक्षर सत्यापन के लिए क्रिप्टोग्राफ़िक फ़ंक्शन और प्रोटोकॉल प्रदान करती है। ओपनएसएसएल लगभग हर जगह पाया जा सकता है जहां वेब सर्वर, ईमेल सर्वर, वर्चुअल प्राइवेट नेटवर्क (वीपीएन), और अन्य प्रकार के नेटवर्क संचार को सुरक्षित करने की आवश्यकता होती है।
उपरोक्त पैराग्राफ को देखने से यह स्पष्ट हो जाना चाहिए कि इंटरनेट के समुचित कार्य के लिए ओपनएसएसएल कितना महत्वपूर्ण है। यह कई कंप्यूटर सिस्टम और अनुप्रयोगों के लिए सुरक्षा बुनियादी ढांचे का एक महत्वपूर्ण घटक है। यह संवेदनशील डेटा को अनधिकृत पहुंच से बचाने में मदद करता है और नेटवर्क संचार की अखंडता और प्रामाणिकता सुनिश्चित करने में मदद करता है। इसीलिए पुस्तकालय के अनुरक्षक कमजोरियों को बहुत गंभीरता से लेते हैं और उन्हें यथाशीघ्र ठीक करने का प्रयास करते हैं। हमलावरों को वर्ल्ड वाइड वेब इंफ्रास्ट्रक्चर की सुरक्षित संचार लाइनों तक पहुंच प्राप्त करने की कल्पना करना लगभग अकल्पनीय है।
इस लेख में, हम उन कमजोरियों की जांच करेंगे जिन्होंने अक्टूबर 3.0.7 में ओपनएसएसएल पैच 2022 को प्रेरित किया, और देखेंगे कि ओपनएसएसएल अनुरक्षकों ने जिस तरह से समस्या का ध्यान रखा उससे हम क्या सीख सकते हैं।
कमजोरियां
25 अक्टूबर, 2022 को ओपनएसएसएल प्रोजेक्ट ने एक प्रकाशित किया सलाहकार चेतावनी है कि कुछ से निपटने के लिए एक नया पैच जल्द ही आने वाला है महत्वपूर्ण कमजोरियाँ। 'क्रिटिकल' टैग का तात्पर्य है कि कमजोरियाँ शोषण योग्य होने की संभावना है और प्रभावित सर्वर पर निजी कुंजी और/या आरसीई की चोरी होने की संभावना है।
एक सप्ताह बाद, 1 नवंबर, 2022 को, ओपनएसएसएल प्रोजेक्ट ने नया पैच, 3.0.7 और दोनों जारी किए। विशिष्ट कमजोरियाँ वे ठीक करने का लक्ष्य रख रहे थे। बीच के समय में, कमजोरियों की रेटिंग को गंभीर से घटाकर 'उच्च गंभीरता' कर दिया गया है।
तो, ये कमजोरियाँ क्या हैं?
CVE-2022-3602 - X.509 ईमेल पता 4-बाइट बफ़र ओवरफ़्लो - X.509 प्रमाणपत्र सत्यापन में, विशेष रूप से नाम बाधा जाँच में, चार बाइट्स का बफ़र ओवररन हो सकता है। स्टैक पर चार हमलावर-नियंत्रित बाइट्स को एक हमलावर द्वारा दुर्भावनापूर्ण ईमेल पते का उपयोग करके ओवरफ्लो किया जा सकता है। इस बफ़र ओवरफ़्लो के कारण क्रैश (परिणामस्वरूप सेवा से इनकार) या संभावित रूप से दूरस्थ कोड निष्पादन हो सकता है। प्रारंभ में, इसे महत्वपूर्ण के रूप में वर्गीकृत किया गया था लेकिन अतिरिक्त परीक्षण से पता चला कि कई प्लेटफ़ॉर्म रिमोट कोड निष्पादन के जोखिम को कम करने के लिए स्टैक ओवरफ़्लो सुरक्षा उपायों का उपयोग करते हैं।
CVE-2022-3786 - X.509 ईमेल पता परिवर्तनीय लंबाई बफ़र ओवरफ़्लो - X.509 प्रमाणपत्र सत्यापन में, विशेष रूप से नाम बाधा जाँच में, एक बफ़र ओवररन हो सकता है। एक हमलावर किसी भी संख्या में बाइट्स के साथ स्टैक को भरने के लिए प्रमाणपत्र में एक दुर्भावनापूर्ण ईमेल पता बना सकता है जिसमें वर्ण "." होता है, जो कि दशमलव संख्या 46 है। इस बफर ओवरफ़्लो के परिणामस्वरूप एक दुर्घटना हो सकती है (जिसके कारण a) सेवा की मनाई)।
बस यह दोहराने के लिए कि ये कमज़ोरियाँ कितनी गंभीर हैंये हैं, सीआईएसए, यूएस साइबर सिक्योरिटी और इंफ्रास्ट्रक्चर सिक्योरिटी एजेंसी, ने एक जारी किया सलाहकार ओपनएसएसएल के समान ही दिन, प्रोत्साहित करेंउपयोगकर्ताओं और प्रशासकों को इसकी समीक्षा करने के लिए प्रेरित करना ओपनएसएसएल दस्तावेज़ीकरण और जहां लागू हो, नए पैच 3.0.7 में अपग्रेड करें।
जैसा कि पहले चर्चा की गई है, ओपनएसएसएल चलाने वाले ऑपरेटिंग सिस्टम या मेल सर्वर पर आरसीई (रिमोट कोड निष्पादन) बहुत खराब होगा, इसलिए केवल इसका खुलासा करना ही समझदारी है एक बार उचित पैच मिल जाने और पेश किए जाने के बाद कमजोरियाँ।
आगे क्या होगा
जैसे ही शुरुआती एडवाइजरी प्रकाशित हुई लोगों ने हाथापाई शुरू कर दी। 'घबराओ मत' एक आम मुहावरा था उस समय पर यह दर्शाता है कि लोगों ने ओपनएसएसएल की आलोचनात्मक खबरों को कितनी गंभीरता से लिया कमजोरियों।
जैसे ही एडवाइजरी प्रकाशित हुई, सभी संबंधित हितधारक यह पता लगाने में जुट गए कि उनके सर्वर, ओएस, एप्लिकेशन, पैकेज आदि में ओपनएसएसएल का कौन सा संस्करण इस्तेमाल किया गया था। केवल आंतरिक ओपनएसएसएल उपयोग के अलावा, लोगों को यह भी पता लगाने की जरूरत थी कि क्या उनका कोई तीसरा संस्करण है पार्टी विक्रेता या सेवा प्रदाता एक असुरक्षित ओपनएसएसएल संस्करण का उपयोग कर रहे थे। उस समय, यदि आप निश्चित नहीं थे कि आप कौन सा संस्करण उपयोग कर रहे थे या आप निश्चित नहीं थे कि आपके विक्रेता और सेवा प्रदाता कौन सा संस्करण उपयोग कर रहे थे, तो जोखिम संभावित आरसीई के बजाय किसी एप्लिकेशन को ऑफ़लाइन लेना अधिक सुरक्षित माना जाता था।
चूंकि एडवाइजरी में पैच के लिए पहले से ही समयसीमा दी गई थी, जिससे लोगों को अपने स्वयं के बुनियादी ढांचे और अपने विक्रेताओं और सेवा प्रदाताओं के बारे में पता लगाने का समय मिल गया। विचार यह था कि इसमें शामिल बुनियादी ढांचे के संदर्भ में सभी आवश्यक चीजों की योजना बनाई जाए ताकि जैसे ही पैच जारी किया जाए, यदि आवश्यक हो तो अपग्रेड किया जा सके।
आप इसे कैसे संभालेंगे?
अब मान लीजिए कि आप एक ऐसी कंपनी में इंजीनियर हैं जो, जहां तक आप जानते हैं, अपने सर्वर में ओपनएसएसएल का उपयोग करती है। जैसे ही सलाह समाप्त हो जाती है, आपको यह पता लगाने की आवश्यकता है कि लाइब्रेरी का कौन सा संस्करण कहां उपयोग में है (किसी भी विरासत कोड सहित यदि यह अभी भी चलाया जा रहा है) और फिर अपने किसी भी विक्रेता या सेवा प्रदाता के लिए भी यही बात समझनी होगी।
यह वह जगह है जहां ए एसबीएम वास्तव में काम आ सकता है. एसबीओएम सामग्री के सॉफ्टवेयर बिल के लिए खड़ा है और यह उन सभी घटकों और सॉफ्टवेयर निर्भरताओं की एक सूची है जो एक विशेष सॉफ्टवेयर उत्पाद बनाते हैं। एक एसबीओएम में आमतौर पर सभी सॉफ्टवेयर घटकों के नाम और संस्करण (देखें कि मैं इसके साथ कहां जा रहा हूं), उनके स्रोत और लाइसेंस, और प्रत्येक घटक से जुड़ी किसी भी ज्ञात कमजोरियां या सुरक्षा समस्या जैसी जानकारी शामिल होती है।
यदि आप, एक जिम्मेदार इंजीनियर के रूप में, अपने प्रत्येक उत्पाद के लिए एक अद्यतन एसबीओएम सुनिश्चित करते हैं तो यह पता लगाना कि आप ओपनएसएसएल का उपयोग कहां कर रहे थे और कौन सा संस्करण उपयोग में था, एसबीओएम फ़ाइल पर खोज चलाने का एक सरल मामला होता। . यदि आपने किसी विक्रेता या सेवा प्रदाता से अद्यतन एसबीओएम के बारे में पूछना सुनिश्चित किया है जिसके साथ आपकी कंपनी काम कर रही है तो आप वहां भी वही खोज कर सकते थे।
चूँकि आपको बताया गया था कि कमजोरियाँ केवल 3.0.0 और 3.0.6 के बीच के संस्करणों को प्रभावित कर रही थीं, आपको बस यह जांचना होगा कि आप कौन से संस्करण चला रहे थे, यह जानने के लिए कि कौन से एप्लिकेशन को हटाने या नए पैच - 3.0.7 के साथ अपडेट करने की आवश्यकता है। XNUMX.
केवल यह दिखाने के लिए कि ओपनएसएसएल का उपयोग करने वाले प्रसिद्ध ऑपरेटिंग सिस्टम और एंटरप्राइज़ अनुप्रयोगों की सूची कितनी व्यापक है, इसे देखें सूची एक सार्वजनिक सेवा के रूप में प्रकाशित किया गया ताकि लोगों को पता चले कि उन्हें कितना चिंतित होना चाहिए।
साक्ष्य-आधारित सुरक्षा हब कैसे मदद कर सकता है?
विकसित हो रहे साइबर सुरक्षा परिदृश्य के हिस्से के रूप में, जिसमें ऐसे दूरगामी प्रभाव भी शामिल हैं कमजोरियों, हम वर्तमान में देख रहे हैं सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा के लिए एप्लिकेशन सुरक्षा का विकास. इन समस्याओं को हल करने के लिए उपकरणों और प्रौद्योगिकियों की एक नई पीढ़ी विकसित की गई है। एक साक्ष्य-आधारित निरंतर कोड सुरक्षा आश्वासन मंच की पेशकश करके जो सॉफ्टवेयर विकास जीवन चक्र और सॉफ्टवेयर घटकों की निर्भरता की पुष्टि कर सकता है, स्वचालित उपकरण और समाधान संगठनों को सुरक्षा के एक नए स्तर को प्राप्त करने में सहायता करते हैं। निर्भरताओं और कमजोरियों को लगातार मैप करने से पैच उपलब्ध होने पर उन्हें ठीक करना या लागू करना आसान हो जाता है।
मुंशी एक सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा केंद्र है। यह सबूत इकट्ठा करता है और इसे आपके सीआई/सीडी पाइपलाइन से गुजरने वाले प्रत्येक निर्माण के लिए प्रस्तुत करता है। स्क्राइब के समाधान का लक्ष्य सॉफ्टवेयर पारदर्शिता बढ़ाने और सॉफ्टवेयर डेवलपर्स और उपयोगकर्ताओं के बीच विश्वास को बढ़ावा देने के लिए यूरोपीय संघ और अमेरिकी नियमों और सर्वोत्तम प्रथाओं का पालन करना आसान बनाना था। प्लेटफ़ॉर्म व्यापक एसबीओएम के साथ-साथ अन्य सुरक्षा अंतर्दृष्टि बनाना और साझा करना संभव बनाता है। इसके अतिरिक्त, प्लेटफ़ॉर्म यह पुष्टि कर सकता है कि जो बिल्ड आप देख रहे हैं वह एनआईएसटी के एसएसडीएफ फ्रेमवर्क और एसएलएसए स्तर 3 आवश्यकताओं दोनों का अनुपालन करता है। अब आपको यह पता लगाने की कोशिश में उलझने की ज़रूरत नहीं है कि आप किस लाइब्रेरी के किस संस्करण का उपयोग कहां कर रहे हैं क्योंकि आपके पास आपके प्रत्येक निर्माण के लिए एसबीओएम के साथ एक साक्ष्य भंडार है। अब, इसका पता लगाना उतना ही सरल है जितना किसी टेक्स्ट दस्तावेज़ में किसी विशेष वाक्य को ढूंढना।
एक अंतिम शब्द: अगली बड़ी भेद्यता प्रकटीकरण के लिए तैयार रहें
पैच 3.0.7 की ओपनएसएसएल प्रोजेक्ट कहानी हमें संभावित महत्वपूर्ण कमजोरियों से निपटने के तरीके के बारे में दो समान रूप से महत्वपूर्ण दृष्टिकोण प्रदान करती है।
प्रभावित पक्ष से - वह कंपनी या परियोजना जो संभावित रूप से इन कमजोरियों से समझौता कर रही थी, हमने पारदर्शिता को सूचित किया है। वे तुरंत उस जानकारी का खुलासा नहीं करते हैं जिससे नुकसान हो सकता है, लेकिन जैसे ही उन्हें किसी समस्या के बारे में पता चलता है तो वे जो कुछ भी कर सकते हैं उसका खुलासा करते हैं। इतना ही नहीं वे समस्या के बारे में यथासंभव अधिक जानकारी के अलावा समाधान के लिए एक समयसीमा भी प्रदान करते हैं। एक बार जब कोई पैच या सुधार मौजूद हो जाता है तो वे यह खुलासा करने में संकोच नहीं करते कि वास्तव में क्या गलत था और इसका संभावित रूप से कैसे फायदा उठाया जा सकता है। इस प्रकार की पारदर्शिता विश्वास को प्रोत्साहित करती है। उपयोगकर्ता और ग्राहक यह जानना और महसूस करना चाहते हैं कि कंपनी उनकी अधिक या कम से कम उतनी ही परवाह करती है, जितनी वह निचली पंक्ति या अपने निदेशक मंडल की करती है।
2014 में ओपनएसएसएल प्रोजेक्ट ' नामक गंभीर बग का शिकार हो गया।दिल का खून' - ओपनएसएसएल के टीएलएस/डीटीएलएस कार्यान्वयन में एक गंभीर दोष जिसने एक हमलावर के लिए प्रभावित सर्वर से एन्क्रिप्शन कुंजी सामग्री, पासवर्ड और अन्य संवेदनशील जानकारी जैसे रहस्य प्राप्त करना संभव बना दिया। हार्टब्लीड ने दिखाया कि ओपनएसएसएल में एक गंभीर भेद्यता क्या कर सकती है क्योंकि यह विभिन्न प्रकार के कार्यक्रमों और लिनक्स वितरणों को प्रभावित करती है। हर कमजोर प्रणाली की पहचान करने और उसे ठीक करने की कोशिश में सुरक्षा टीमों को महीनों का सिरदर्द झेलना पड़ा। एसबीओएम जैसा एक उपकरण लागू करना, जो आपके सॉफ़्टवेयर को अपडेट और पैच करना तेज़ और सरल बना सके, किसी भी कंपनी की साइबर सुरक्षा टीम के लिए एक वरदान होगा।
उपचारात्मक पक्ष से - यह जानना कि वास्तव में आपको किसके साथ काम करना है - आप किस पैकेज का कौन सा संस्करण उपयोग कर रहे हैं, ऐसी किसी भी संभावित आपात स्थिति से निपटने में सक्षम होने के लिए आवश्यक है। उदाहरण के तौर पर Log4J को लेते हुए - कुछ कंपनियाँ अभी भी यह पता लगाने की कोशिश कर रही हैं कि खोजे जाने के एक साल से अधिक समय बाद भी वे इस भेद्यता से प्रभावित हैं या नहीं।
तथ्य यह है कि आपको केवल अपने सॉफ़्टवेयर और सर्वर के बारे में चिंता करने की ज़रूरत नहीं है, यह उन तीसरे पक्ष के विक्रेताओं के बारे में भी है जिनका आप उपयोग कर रहे हैं, या किसी भी सेवा प्रदाता के साथ आप काम कर रहे हैं, यहां तक कि एपीआई कनेक्शन का उपयोग करते हुए भी, इसका मतलब है कि हम, सभी हममें से, वास्तव में हमारे बीच विश्वास का एक जाल बनाने की जरूरत है। इस तरह के भरोसे को यथासंभव पुख्ता सबूतों पर निर्भर रहना चाहिए। अपने स्वयं के एसबीओएम और जिस भी कंपनी के साथ आप व्यवसाय में हैं, बनाएं और ट्रैक करें, उन एसबीओएम को साझा करें, और जिस भी शोषणकारी भेद्यता के बारे में आप जानते हैं, उसकी घोषणा करने और उसे ठीक करने में अच्छा विश्वास दिखाएं।
ऐसी दुनिया में पहुंचने के लिए हम सभी को मिलकर काम करना होगा जहां ऐसे सबूत साझा करना उतना ही आम बात है जितना कि कंपनी के नवीनतम पीआर को सोशल मीडिया पर साझा करना। इस भरोसे के बिना, हम बस अगली बड़ी गंभीर भेद्यता के लिए मंच तैयार कर रहे हैं, जो उस परस्पर जुड़े बुनियादी ढांचे को तोड़ देगी, जिसे बनाए रखने के लिए हम सभी कड़ी मेहनत करते हैं।
यह सामग्री आपके लिए स्क्राइब सिक्योरिटी द्वारा लाई गई है, जो एक अग्रणी एंड-टू-एंड सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा समाधान प्रदाता है - जो संपूर्ण सॉफ्टवेयर आपूर्ति श्रृंखलाओं में कोड कलाकृतियों और कोड विकास और वितरण प्रक्रियाओं के लिए अत्याधुनिक सुरक्षा प्रदान करता है। और अधिक जानें.
संबंधित पोस्ट
