🎯 🧜🏿 ⚫️ पीवीएस-स्टूडियो स्टेटिक एनालाइज़र, ज़ीरो-डे वल्नरेबिलिटी के खिलाफ सुरक्षा के लिए एक उपकरण के रूप में 🔊 ❤️ ✈️

शून्य-दिन (0-दिन) भेद्यता एक कंप्यूटर-सॉफ्टवेयर भेद्यता है जो विकास प्रक्रिया के दौरान शुरू की गई है और अभी तक डेवलपर्स द्वारा नहीं खोजी गई है। ज़ीरो-डे कमजोरियों का उपयोग हैकर्स द्वारा किया जा सकता है, जिससे कंपनी की प्रतिष्ठा प्रभावित होती है। डेवलपर्स को ऐसी कमजोरियों के कारण दोषों की संख्या को कम करना चाहिए। पीवीएस-स्टूडियो, सी, सी ++, सी # और जावा कोड के लिए एक स्थिर कोड विश्लेषक, सुरक्षा मुद्दों का पता लगाने में सक्षम उपकरणों में से एक है।

शून्य-दिवस भेद्यता

शून्य-दिन की भेद्यता (जिसे 0-दिन की भेद्यता के रूप में भी जाना जाता है) एक कंप्यूटर-सॉफ़्टवेयर भेद्यता है जो अज्ञात है, या इससे प्रभावित नहीं है, जिन्हें भेद्यता को कम करने में रुचि होनी चाहिए (लक्ष्य सॉफ़्टवेयर के विक्रेता सहित)। जब तक भेद्यता को कम नहीं किया जाता है, तब तक हैकर्स कंप्यूटर प्रोग्राम, डेटा, अतिरिक्त कंप्यूटर या नेटवर्क पर प्रतिकूल प्रभाव डाल सकते हैं। शब्द का अर्थ है कि डेवलपर्स के पास दोष को ठीक करने के लिए एक भी दिन नहीं है क्योंकि कोई भी इसके बारे में अभी तक नहीं जानता है। कुछ प्रसिद्ध विक्रेता और सॉफ्टवेयर उत्पाद जैसे कि Adobe , Windows , Tor ब्राउज़र और कई अन्य, अतीत में शून्य-दिन की कमजोरियों से प्रभावित थे।

कुछ लोग खुशकिस्मत थे कि उन लोगों को इसकी जानकारी मिली, जिन्होंने इसका फायदा नहीं उठाया। MacOS का मामला एक ऐसा उदाहरण है। कुछ अन्य मामलों में, डेवलपर्स ने खुद एक पैच का उत्पादन किया, जिसके साथ नई सुविधाओं को जोड़ते हुए, उन्होंने इसे जानने के बिना एक शून्य-दिन की भेद्यता भी तय की।

अन्य हालांकि कम भाग्यशाली थे। उदाहरण के लिए, बहुत पहले नहीं, Google Chrome को एक भेद्यता को तत्काल ठीक करना था जिसका उपयोग मनमाने ढंग से कोड को निष्पादित करने के लिए किया जा सकता था।

समस्या यह है कि आप इन कमजोरियों के खिलाफ 100% सुरक्षा की गारंटी नहीं दे सकते हैं क्योंकि आप प्रभावी रूप से एक ऐसे खतरे से नहीं लड़ सकते हैं जिसका आपको पता भी नहीं है। हालांकि, आपके कार्यक्रम में इस तरह के दोष होने की संभावना कम करने के तरीके हैं - यह इस लेख का विषय होगा, लेकिन हमें पहले कुछ सिद्धांत पर ध्यान देना चाहिए।

स्थैतिक विश्लेषण

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

कोड समीक्षा	स्थैतिक विश्लेषण
न केवल तुच्छ, बल्कि उच्च-स्तरीय बग ढूंढने में मदद करता है	अपरिचित दोष या कमजोरियों को खोजने में मदद करता है
कार्यक्रम की वास्तुकला को बेहतर बनाने में मदद करता है और एक सुसंगत कोडिंग शैली का काम करता है	मानव आंखों को आसानी से ध्यान न देने वाले कीड़े खोजने में मदद करता है (उदाहरण के लिए टाइपो)
महंगा	कोड समीक्षा की तुलना में सस्ता
बहुत सारे प्रोग्रामर्स का समय लेती है। ब्रेक्स आवश्यक हैं क्योंकि समीक्षक का ध्यान जल्दी से कमजोर हो जाता है	झूठी सकारात्मकताएं अपरिहार्य हैं; उपयोगकर्ता को विश्लेषक को अनुकूलित करना होगा

सीवीई और सीडब्ल्यूई

सामान्य कमजोरियाँ और एक्सपोज़र (CVE) सूचना-सुरक्षा भेद्यताओं और जोखिमों का एक डेटाबेस है। इसका प्रारंभिक उद्देश्य सुसंगत सॉफ्टवेयर दोषों को सुसंगत सूची में व्यवस्थित करना था। अतीत में, अधिकांश सूचना-सुरक्षा उपकरण ऐसे दोषों के लिए अपने स्वयं के डेटाबेस और नामों का उपयोग कर रहे थे, और यह उस अराजकता के लिए आदेश लाने और विभिन्न उपकरणों के बीच संगतता स्थापित करने के लिए था जो MITER Corporation ने 1999 में CVE विकसित किया था। हालांकि, CVE निकला कोड सुरक्षा का अनुमान लगाने के लिए अपर्याप्त है। महीन वर्गीकरण और अधिक विस्तृत विवरण के साथ कुछ अन्य प्रणाली की आवश्यकता थी। इसी तरह से कॉमन वीकनेस एन्यूमरेशन (CWE) अस्तित्व में आया। यदि सीडब्ल्यूई में एक दोष सूचीबद्ध है, तो यह एक शोषक भेद्यता का कारण बन सकता है और सीवीई सूची में भी जोड़ा जा सकता है। नीचे यूलर आरेख मानकों के बीच संबंधों को दर्शाता है।

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

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

SAST अभी तक आपकी परियोजना में होने वाली शून्य-दिन की कमजोरियों की संभावना को कम करने के लिए एक और अभ्यास है। CWE मानक का समर्थन करने वाला एक विश्लेषक आपको बता सकता है कि एक संभावित भेद्यता कहाँ छिपी हुई है ताकि आप अपने आवेदन को अधिक विश्वसनीय बनाने के लिए इसे ठीक कर सकें और 0-दिन के खतरे को कम कर सकें।

SAST टूल की एक किस्म है। मैं पीवीएस-स्टूडियो विश्लेषक को उदाहरण के रूप में दिखाऊंगा कि ये उपकरण कमजोरियों से लड़ने में कैसे मदद कर सकते हैं। इस विश्लेषक की चेतावनियों को CWE के रूप में वर्गीकृत किया गया है। कुछ उदाहरण नीचे दिए गए हैं।

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: CWE-561 : डेड कोड ( V3021 )।

public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }

इस कोड में एक टाइपो होता है: यदि दोनों स्टेटमेंट एक ही चर की जाँच करते हैं। अपवाद के साथ संदेश यह बताता है कि दूसरी स्थिति में आउटपुटपथ चर की जाँच करनी चाहिए। इस गलती ने कोड के कुछ हिस्से को अगम्य बना दिया है।

उस तरह के कीड़े हानिरहित लग सकते हैं, लेकिन यह धारणा गलत है। आइए एक और तुच्छ और प्रतीत होने वाले हानिरहित बग पर एक नज़र डालें जो कि डुप्लीकेट गोटो स्टेटमेंट के साथ करना है।

इस बग ने एक बार iOS में भेद्यता पैदा कर दी थी।

CVE-2014-1266 भेद्यता: SSLVerifySignSerServerKeyExchange फ़ंक्शन libsecurity_ssl / lib / sslKeyExchange.c में Apple iOS में डेटा सुरक्षा घटक में सुरक्षित परिवहन सुविधा में 6.1.6 से पहले 6.1x और 7.x पर 7.0.6 से पहले Apple TV 6.0x से पहले 6.x, और 10.9.2 से पहले Apple OS X 10.9.x एक TLS सर्वर कुंजी एक्सचेंज संदेश में हस्ताक्षर की जांच नहीं करता है, जो एक मध्यस्थ का उपयोग करके एसएसएल सर्वर को खराब करने के लिए मध्य-हमलावरों को अनुमति देता है हस्ताक्षर चरण के लिए निजी कुंजी या हस्ताक्षर चरण को छोड़ देना।

 static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }

पहले उदाहरण की तरह, यहाँ भी डुप्लीकेट गोटो अगम्य कोड के कारण होता है: यदि स्टेटमेंट्स की स्थिति चाहे जो भी हो, दूसरे गोटो स्टेटमेंट को वैसे भी निष्पादित किया जाएगा। परिणामस्वरूप, हस्ताक्षर की जाँच नहीं की जाएगी, फ़ंक्शन 0 पर लौटेगा, जिसका अर्थ है कि हस्ताक्षर ठीक था, और कार्यक्रम को सर्वर से एक कुंजी प्राप्त होगी, भले ही हस्ताक्षर की जाँच विफल हो गई हो। इस कुंजी का उपयोग प्रेषित डेटा को एन्क्रिप्ट करने के लिए किया जाता है।

इस तुच्छ बग के काफी निहितार्थ थे। यह घटना बताती है कि इस या उस सीडब्ल्यूई दोष के खतरनाक होने या न होने की कोई अटकलें क्यों नहीं हैं - आपको इसे अपने कोड की सुरक्षा के लिए ठीक करना होगा।

वैसे, पीवीएस-स्टूडियो आसानी से इस बग को ढूंढ सकता था, एक ही बार में दो सीडब्ल्यूई चेतावनियों के साथ इसकी रिपोर्ट करना:

CWE-561 ( V779 ): डेड कोड
CWE-483 ( V640 ): गलत ब्लॉक परिसीमन

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

CVE-2012-2122 भेद्यता: Oracle MySQL में sql / password.c 5.1.x पहले 5.1.63, 5.5.24 से पहले 5.5.x, और 5.6.6 से पहले 5.6.x, और 5.1.62 से पहले MariaDB 5.1.x , 5.2.x से पहले 5.2.12, 5.3.x से पहले 5.3.6, और 5.5.x से पहले 5.5.23, जब कुछ वातावरण में चल रहे हैं, तो memcmp फ़ंक्शन के कुछ कार्यान्वयन के साथ, दूरस्थ हमलावरों को बार-बार प्रमाणित करके प्रमाणीकरण को बायपास करने की अनुमति मिलती है। एक गलत पासवर्ड, जो अंततः एक अनुचित तरीके से चेक किए गए रिटर्न मान के कारण सफल होने के लिए टोकन तुलना का कारण बनता है।

 typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }

Memcmp फ़ंक्शन प्रकार int का मान लौटाता है, जबकि check_scramble फ़ंक्शन प्रकार my_bool का मान लौटाता है , जो वास्तव में char है । सबसे महत्वपूर्ण बिट्स को अलग करने के साथ इंट वैल्यू को स्पष्ट रूप से चार में डाला जाता है। सफल होने के लिए एक ज्ञात उपयोगकर्ता नाम के लिए एक मनमाना पासवर्ड के साथ लॉग इन करने के लिए 256 प्रयासों में से लगभग 1 का कारण बना।

फिर से, इस सीडब्ल्यूई दोष को बेअसर किया जा सकता था और कोडिंग चरण में बहुत पहले सीवीई भेद्यता बनने से रोका जा सकता था। उदाहरण के लिए, पीवीएस-स्टूडियो इसे CWE-197 ( V642 ): न्यूमेरिक ट्रंकेशन त्रुटि के रूप में रिपोर्ट करता है।

विषय पर आगे पढ़ने के लिए " कैसे PVS-Studio मदद कर सकता है? "

निष्कर्ष

आप यह सुनिश्चित नहीं कर सकते कि आपका कार्यक्रम 0-दिन की भेद्यताओं से सुरक्षित है। लेकिन आप अभी भी उन्हें होने की संभावना बहुत कम कर सकते हैं। यह PVS-Studio जैसे विशेष SAST टूल का उपयोग करके किया जाता है। यदि आपकी परियोजना में CWE के मुद्दों के रूप में वर्गीकृत दोष पाए जाते हैं, तो उन्हें ठीक करना सुनिश्चित करें। भले ही सीडब्ल्यूई सूची में सीडब्ल्यूई के कुछ दोष समाप्त हो गए हों, उन्हें ठीक करने से आपके कार्यक्रम को कई संभावित खतरों से सुरक्षित रखने में मदद मिलती है।

पीवीएस-स्टूडियो स्टेटिक एनालाइज़र, ज़ीरो-डे वल्नरेबिलिटी के खिलाफ सुरक्षा के लिए एक उपकरण के रूप में

शून्य-दिवस भेद्यता

स्थैतिक विश्लेषण

सीवीई और सीडब्ल्यूई

निष्कर्ष

संदर्भ

More articles: