🍏 👩🏾 🚅 सुरक्षा धोखा शीट्स: वर्चुअल पैचिंग 👦🏾 🥝 🕠

आज के हमारे लेख का विषय है वर्चुअल पैचिंग।

वर्चुअल पैचिंग एक सुरक्षा नीति परत है जिसे ज्ञात कमजोरियों के लिए शोषण का पता लगाने और रोकने के लिए डिज़ाइन किया गया है।

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

तो क्यों आभासी पैच, क्यों न सिर्फ कोड को अपडेट करें?

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

वर्चुअल पैच के लाभ इस प्रकार हैं:

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

आभासी पैच के नुकसान:

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

वर्चुअल पैच की तैयारी को निम्नलिखित चरणों में विभाजित किया जा सकता है:

ट्रेनिंग
पहचान की धमकी
के विश्लेषण
एक आभासी पैच बनाएँ
कार्यान्वयन और परीक्षण
काम की वसूली / निरंतरता

सार्वजनिक भेद्यता

उदाहरण के लिए, SQL इंजेक्शन और ModSecurity WAF (खुले स्रोत से) लें।

WordPress Shopping Cart Plugin  WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php  reqID   SQL Injection.

वर्डप्रेस के लिए वर्डप्रेस शॉपिंग कार्ट प्लगइन में एक दोष है जो एक हमलावर को SQL इंजेक्शन निष्पादित करने की अनुमति दे सकता है। समस्या स्क्रिप्ट /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php में निहित है, जिसमें reqID पैरामीटर सही ढंग से साफ नहीं किया गया है।

यह एक हमलावर को बैकएंड पर SQL प्रश्नों को एम्बेड या हेरफेर करने की अनुमति दे सकता है, जिससे सभी आगामी परिणामों के साथ, डेटा तक अवैध पहुंच प्राप्त करने की संभावना होती है।

तैयारी का चरण

जैसा कि कई प्रक्रियाओं में, आभासी पैच के लिए तैयारी एक महत्वपूर्ण घटक है। एक खोजी भेद्यता (या एक वास्तविक समय के हमले से भी बदतर) से निपटने से पहले, आपको कुछ चीजें करने की आवश्यकता है। तैयारी के बिंदु को हमले के दौरान समझ में नहीं आता है कि वर्चुअल पैच कैसे काम करता है और वर्तमान बुनियादी ढांचे में WAF को कैसे एकीकृत किया जाए अगर यह वहां नहीं है, लेकिन कुछ और अच्छी तरह से सोची-समझी कार्रवाई करने के लिए।

यहां कुछ महत्वपूर्ण बिंदु दिए गए हैं जिन्हें तैयारी में शामिल करने की आवश्यकता है:

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

) अनुरोध URI (QUERY_STRING सहित)
Request सभी अनुरोध हेडर (कुकीज़ सहित)
◦ पूर्ण अनुरोध निकाय (POST लोड सहित)
◦ पूर्ण प्रतिक्रिया हेडर
◦ पूर्ण प्रतिक्रिया शरीर

खतरा डिटेक्शन स्टेज

यह चरण तब शुरू होता है जब संगठन को पता चलता है कि उसके वेब एप्लिकेशन में भेद्यता है। सामान्य तौर पर, कमजोरियों की पहचान करने के लिए दो अलग-अलग दृष्टिकोण हैं - सक्रिय और प्रतिक्रियाशील।

सक्रिय दृष्टिकोण

मामला जब संगठन सुरक्षा कार्य करता है और निम्नलिखित कार्य करता है:

एप्लिकेशन का डायनेमिक मूल्यांकन - कमियों की पहचान करने के लिए एक चल रहे वेब एप्लिकेशन पर पेंटेस्ट और / या स्वचालित मूल्यांकन परीक्षण किया जाता है।
स्रोत कोड की समीक्षा - कमियों का पता लगाने के लिए एक वेब एप्लिकेशन के स्रोत कोड का एक मैनुअल और / या स्वचालित मूल्यांकन किया जाता है।

प्रतिक्रियात्मक दृष्टिकोण

कमजोरियों की पहचान करने के लिए तीन मुख्य प्रतिक्रियाशील तरीके हैं:

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

विश्लेषण चरण

विश्लेषण चरण के लिए अनुशंसित कदम:

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

वर्चुअल पैच बनाने का चरण

एक अच्छा आभासी पैच बनाने की प्रक्रिया दो पहलुओं से जुड़ी है:

कोई झूठी सकारात्मकता नहीं - परिस्थितियों के बावजूद सामान्य यातायात को कभी भी अवरुद्ध न करें
झूठी सकारात्मकता के बिना - कभी भी एक हमले को याद मत करो, तब भी जब हमलावर जानबूझकर पता लगाने से बचने की कोशिश करता है।

इन दोनों नियमों के प्रभाव को कम करने के लिए प्रयास किए जाने चाहिए। यह संभव नहीं हो सकता है (जो सबसे अधिक बार होता है) इन दोनों नियमों का पालन करना, लेकिन यह याद रखना महत्वपूर्ण है कि वर्चुअल पैच जोखिम को कम करने के बारे में है।

एक आभासी पैच का मैनुअल निर्माण
वर्चुअल पैच में पॉजिटिव अप्रोच (व्हाइटलाइनिंग, वाइटेलिस्टिंग)

यह दृष्टिकोण वेब एप्लिकेशन के लिए एक स्वतंत्र इनपुट सत्यापन बनाने के लिए है। दृष्टिकोण वैध डेटा (चरित्र सेट, लंबाई, आदि) की विशेषताओं को निर्धारित करता है और कुछ भी निषिद्ध करता है जो इन स्थितियों में फिट नहीं होता है। वेब एप्लिकेशन के प्रत्येक पृष्ठ पर प्रत्येक पैरामीटर के लिए नियमों को परिभाषित करके, हम एप्लिकेशन को सुरक्षा के एक अतिरिक्त परत में लपेटते हैं, इसके स्रोत कोड से स्वतंत्र।

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

एक उदाहरण है।

इस स्थिति में, reqID पैरामीटर में केवल पूर्णांक होना चाहिए ताकि हम इस वर्चुअल पैच को लागू कर सकें:

 # # ,     1    "reqID" # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'" SecRule &ARGS:/reqID/ "!@eq 1" # # ,   reqID     # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"

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

वर्चुअल पैच में नकारात्मक दृष्टिकोण (ब्लैकलिस्टिंग, ब्लैकलिस्टिंग)

यह दृष्टिकोण नियमों की एक सूची पर आधारित है जो केवल वैध यातायात की अनुमति देने के बजाय कुछ ज्ञात हमलों को परिभाषित करता है।

ModSecurity में ब्लैकलिस्टिंग के आधार पर वर्चुअल पैच बनाने का एक उदाहरण

उदाहरण के लिए, एक सार्वजनिक स्रोत से PoC कोड:

 http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1

लोड का विश्लेषण करने के बाद, हम देख सकते हैं कि हमलावर एक एकल उद्धरण सम्मिलित करता है और अंत में SQL तर्क जोड़ता है। इस डेटा के आधार पर, हम एकल उद्धरणों को मना कर सकते हैं:

 SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "@pm '"

विशिष्ट कारनामों के लिए आभासी पैच बनाने से सावधान रहें

बेशक, यह आकर्षक और समय की बचत है। उदाहरण के लिए, यदि pentest ने आपके पेज पर XSS पाया और निम्नलिखित लोड का उपयोग किया:

 <script> alert('XSS Test') </script>

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

स्वचालित रूप से वर्चुअल पैच बनाएं

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

कार्यान्वयन और परीक्षण का चरण

हमारे नए आभासी पैच का सही ढंग से परीक्षण करने के लिए, हमें निम्नलिखित टूल की आवश्यकता हो सकती है:

वेब ब्राउज़र
टर्मिनलों के लिए वेब उपयोगिताओं (जैसे कर्ल और विग)
स्थानीय प्रॉक्सी
ModSecurity AuditViewer

कदम:

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

वसूली / निरंतरता चरण

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

सुरक्षा धोखा शीट्स: वर्चुअल पैचिंग

More articles: