रिपल 20 क्रिटिकल वल्नरेबिलिटी – डिटेक्शन लॉजिक एंड सिग्नेचर

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

हमने भेद्यता प्रूफ-ऑफ-कॉन्सेप्ट से लिए गए पैकेट कैप्चर भी प्रदान किए हैं, जो कि डिटेक्शन लॉजिक के आधार पर या तो नीचे दिए गए हस्ताक्षरों या अनुकूलित हस्ताक्षरों के परीक्षण और तैनाती के लिए कलाकृतियों के रूप में हैं। हस्ताक्षर और Lua लिपियाँ ATR के गितुब पृष्ठ पर स्थित हैं, क्रमशः इनलाइन और इस दस्तावेज के परिशिष्ट में।

इस सुबह के रूप में (5 अगस्त)वें), जेएसओएफ ने डीएनएस में दो सबसे महत्वपूर्ण कमजोरियों पर ब्लैकहैट 2020 पर अतिरिक्त तकनीकी विवरण और शोषण विश्लेषण प्रस्तुत किया है।

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

इंटेगर ओवरफ्लो में tfDnsExpLabelLength हीप ओवरफ्लो और आरसीई के लिए अग्रणी

CVE: CVE-2020-11901 (वेरिएंट 1)
CVSS: 9
प्रोटोकॉल (ओं): UDP पर DNS (और टीसीपी पर DNS की संभावना)
पोर्ट (ओं): 53

भेद्यता विवरण:
ट्रेक स्टैक में, DNS नामों की गणना फ़ंक्शन के माध्यम से की जाती है tfDnsExpLabelLength। इस फ़ंक्शन में एक बग मौजूद होता है जहां गणना एक अहस्ताक्षरित शॉर्ट का उपयोग करके की जाती है, जिससे एक विशेष रूप से निर्मित डीएनएस प्रतिक्रिया पैकेट के साथ गणना मूल्य को ओवरफ्लो करना संभव हो जाता है। जबसे tfDnsExpLabelLength डीएनएस नाम की पूरी लंबाई की गणना करने के बाद यह विघटित हो जाता है, DNS पैकेट का उपयोग कर एक अतिप्रवाह को प्रेरित करना संभव है, जो 2 से छोटा है16 बाइट्स। कुछ कोड पथों में, tfGetRawBuffer इसके तुरंत बाद कहा जाता है tfDnsExpLabelLength, ढेर पर एक बफर आवंटित करना, जहां DNS नाम द्वारा गणना किए गए आकार का उपयोग करके संग्रहीत किया जाएगा tfDnsExpLabelLength, इस प्रकार एक ढेर अतिप्रवाह और संभावित आरसीई के लिए अग्रणी।

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

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

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

क्योंकि dns_invalid_size.rules में Suricata नियम DNS प्रतिक्रियाओं ‘EDNS UDP लंबाई का उपयोग करता है, जिसे हमलावर द्वारा नियंत्रित किया जा सकता है, 4096 बाइट्स की एक दूसरी ऊपरी सीमा लागू होती है।

अनुशंसित खोज मापदंड:

  • डिवाइस को DNS ट्रैफ़िक को संसाधित करने और उनके संबंधित अनुरोधों से मिलान करने में सक्षम होना चाहिए।
  • डिवाइस को अलग-अलग DNS पैकेट के भीतर व्यक्तिगत DNS नामों की पहचान करने में सक्षम होना चाहिए।
  • डिवाइस को किसी भी DNS प्रतिक्रियाओं को फ़्लैग करना चाहिए जिसका आकार “अपेक्षित” से अधिक है। भेजे गए DNS पैकेट के प्रकार पर अपेक्षित आकार निर्भर करता है:
      • टीसीपी पर डीएनएस के लिए, आकार टीसीपी पेलोड के पहले दो बाइट्स में निर्दिष्ट मूल्य से अधिक नहीं होना चाहिए।
      • UDP पर DNS के लिए साथ में EDNS (0), आकार अनुरोध में मोल-भाव से अधिक नहीं होना चाहिए, जो वर्तमान में OPT RR के CLASS क्षेत्र में निर्दिष्ट है।
      • UDP पर DNS के लिए के बग़ैर EDNS (0), आकार 512 बाइट्स से अधिक नहीं होना चाहिए।
      • ये सभी dns_invalid_size.rules में जांचे जाते हैं, जो तर्क के लिए dns_size.lua या dns_tcp_size.lua दोनों को आमंत्रित करता है।
  • डिवाइस को DNS नामों को ध्वजांकित करना चाहिए जिसमें 255 बाइट्स (डीकोप्रेशन से पहले) डीएनएस नाम हैं।
      • यह dns_invalid_name.rules में जांचा जाता है, जो तर्क के लिए dns_invalid_name.lua को आमंत्रित करता है।
  • डिवाइस को DNS नामों को फ़्लैग करना चाहिए जिसमें DNS नामों में ए-जेड, ए-जेड, 0-9, “-“, “_” और “*” के अलावा वर्ण शामिल हैं।
      • यह dns_invalid_name.rules में भी जांचा जाता है, जो तर्क के लिए dns_invalid_name.lua को आमंत्रित करता है।
  • डिवाइस को बड़ी संख्या में DNS संपीड़न पॉइंटर्स युक्त DNS प्रतिक्रियाओं को फ़्लैग करना चाहिए, विशेष रूप से एक के बाद एक पॉइंटर्स। विशिष्ट सहिष्णुता नेटवर्क पर निर्भर करेगी।
      • डिवाइस को इस सूचक कुल के खिलाफ 0b10, 0b01, या 0b11 के साथ शुरू होने वाले सभी लेबलों की गणना करनी चाहिए, क्योंकि ट्रेक स्टैक के असुरक्षित संस्करण (गलत तरीके से) उन सभी लेबलों को वर्गीकृत करते हैं, जहां पहले दो बिट्स 0b10 संपीड़न बिंदुओं के साथ नहीं होते हैं। लुआ लिपि में, हम 63 (0x3F) से ऊपर के किसी भी मान को इस कारण से सूचक मानते हैं, क्योंकि उस श्रेणी के किसी भी मान में कम से कम एक बिट सेट होगा।
      • इस नियम के हमारे कार्यान्वयन के लिए विशिष्ट थ्रेसहोल्ड एक DNS पैकेट में 40 कुल पॉइंटर्स या 4 लगातार पॉइंटर्स पर सेट किए गए थे। इन मूल्यों को इसलिए चुना गया क्योंकि वे एक बहुत बड़े परीक्षण पीसीएपी में किसी भी गलत सकारात्मकता को ट्रिगर नहीं करते थे, लेकिन उस नियम को लागू किए जाने वाले नेटवर्क के लिए विशिष्ट ट्रैफिक के लिए आवश्यक रूप से बदल दिया जाना चाहिए। लगातार पॉइंटर्स के लिए परीक्षण विशेष रूप से उपयोगी है क्योंकि प्रत्येक डोमेन नाम में केवल एक पॉइंटर (बहुत अंत में) होना चाहिए, जिसका अर्थ है कि हमें सामान्य ट्रैफ़िक में कई पॉइंटर्स को एक पंक्ति में कभी नहीं देखना चाहिए।
      • इसे dns_heap_overflow_variant_1.lua में लागू किया गया है, जिसे dns_heap_overflow.rules द्वारा लागू किया गया है।
  • ऊपर पता लगाने के तर्क का कार्यान्वयन कई सुरिकता नियम फाइलों के बीच विभाजित किया गया है क्योंकि केवल सूचक गिनती तर्क इस भेद्यता के लिए विशिष्ट है। इस भेद्यता का लाभ उठाने वाले कारनामों का पता डीएनएस परत के आकार की जांच, डोमेन नाम संपीड़ित लंबाई की जाँच और अन्य नियमों में लागू डोमेन नाम चरित्र की जाँच के साथ बढ़ाया जाता है, लेकिन इन्हें “सहायक” हस्ताक्षर माना जाता है और इनमें से एक को चिह्नित करना जरूरी नहीं कि यह विशिष्ट भेद्यता के लिए शोषण के प्रयास को दर्शाता है।

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

हमारे परीक्षण में, हम ऐसे डोमेन नामों के साथ झूठी सकारात्मकता में भाग गए जिनमें रिक्त स्थान या “https: //” जैसी चीजें थीं। RFC के अनुसार, “:” और “/” जैसे अक्षर डोमेन नामों में मौजूद नहीं होने चाहिए, लेकिन वास्तविक, गैर-दुर्भावनापूर्ण ट्रैफ़िक में समय-समय पर दिखाई दे सकते हैं। अत्यधिक झूठी सकारात्मकता से बचने के लिए लक्षित नेटवर्क के लिए आवश्यकतानुसार स्वीकार्य वर्णों की सूची का विस्तार किया जाना चाहिए। कहा जा रहा है, स्वीकार्य वर्णों की सूची को यथासंभव छोटा रखना, Ripple20 DNS कमजोरियों में से एक का लाभ उठाने के लिए शेलकोड में चुपके करना अधिक कठिन बना देगा।

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

टीसीपी पर डीएनएस ट्रैफ़िक का विखंडन भी झूठी सकारात्मकता का परिचय दे सकता है। यदि DNS पेलोड पर नियमों को निष्पादित करने के समय धाराओं का ठीक से पुनर्निर्माण नहीं किया जाता है, तो संलग्न लुआ लिपियों में उपयोग किए गए बाइट ऑफ़सेट गलत डेटा का विश्लेषण कर सकते हैं। जब तक MTU मान विशेष रूप से कम सेट नहीं किए गए हैं, तब तक DNS प्रतिक्रिया पैकेट में विखंडन एक मानक नेटवर्क पर आम नहीं है। विशिष्ट नेटवर्क आवश्यकताओं और शर्तों के आधार पर उत्पादन में उपयोग करने से पहले प्रत्येक नियम का स्वतंत्र रूप से मूल्यांकन किया जाना चाहिए।

गलत नकारात्मक स्थिति (निशक्तता / शोषण का पता लगाने में विफल)
झूठी नकारात्मक अधिक संभावना है क्योंकि यह पता लगाने का तर्क असंपीड़ित DNS नाम की लंबाई के कम्प्यूटेशनल रूप से महंगा होने के कारण गणना पर निर्भर करता है। सावधानी से निर्मित दुर्भावनापूर्ण पैकेट सुझाव सूचक सीमाओं को दरकिनार करने में सक्षम हो सकते हैं और फिर भी भेद्यता को ट्रिगर कर सकते हैं।

हस्ताक्षर):
dns_invalid_size.rules:

alert dns any any ‑> any any (msg:"DNS packet too large"; flow:to_client; flowbits:set,flagged; lua:dns_size.lua; sid:2020119014; rev:1;)
लुआ स्क्रिप्ट (dns_size.lua) में पाया जा सकता है परिशिष्ट A

alert tcp any 53 -> any any (msg:"DNS over TCP packet too large"; flow:to_client,no_frag; flowbits:isnotset,flagged; lua:dns_tcp_size.lua; sid:2020119015; rev:1;)
लुआ स्क्रिप्ट (dns_tcp_size.lua) में पाया जा सकता है परिशिष्ट A

dns_invalid_name.rules:

alert dns any any -> any any (flow:to_client; msg:"DNS response contains invalid domain name"; lua:dns_invalid_name.lua; sid:2020119013; rev:1;)
लुआ स्क्रिप्ट (dns_invalid_name.lua) में पाया जा सकता है परिशिष्ट A

dns_heap_overflow.rules:

# Variant 1
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_1.lua; sid:2020119011; rev:1;)
लुआ स्क्रिप्ट (dns_heap_overflow_variant_1.lua) में पाया जा सकता है परिशिष्ट A

DNS CNAME रिकॉर्ड्स में RDATA की लंबाई बेमेल ढेर अतिप्रवाह

CVE: CVE-2020-11901 (वेरिएंट 2)
CVSS: 9
प्रोटोकॉल (ओं): DNS / UDP (और संभवतः DNS / TCP)
पोर्ट (ओं): 53

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

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

अनुशंसित खोज मापदंड:

  • डिवाइस आने वाली DNS प्रतिक्रियाओं को संसाधित करने में सक्षम होना चाहिए।
  • डिवाइस DNS प्रतिक्रियाओं के भीतर CNAME रिकॉर्ड की पहचान करने में सक्षम होना चाहिए
  • डिवाइस को सभी DNS प्रतिक्रियाओं को फ़्लैग करना चाहिए जहां CNAME रिकॉर्ड के लिए RDATA फ़ील्ड का वास्तविक आकार उसी रिकॉर्ड के RDLENGTH फ़ील्ड में निर्दिष्ट मान से अधिक है।
      • इस मामले में, “वास्तविक आकार” से मेल खाता है कि ट्रेक स्टैक के कितने कमजोर संस्करण RDATA लंबाई की गणना करते हैं, जिसमें प्रत्येक लेबल के आकार को या तो शून्य बाइट तक जोड़ा जाता है, एक DNS संपीड़न सूचक, या पेलोड का अंत होता है। । ट्रेक स्टैक उस पॉइंटर को फॉलो और डिकम्पोज करेगा जो डोमेन नाम को समाप्त करता है, यदि मौजूद है, लेकिन स्क्रिप्ट नहीं है क्योंकि यह गणना बस बहुत महंगी है, जैसा कि पहले उल्लेख किया गया है।

गलत सकारात्मक स्थिति (गैर-दुर्भावनापूर्ण ट्रैफ़िक का पता लगाने वाले हस्ताक्षर):
गलत पॉज़िटिव की संभावना नहीं है, लेकिन उन परिदृश्यों में संभव है जहां नेटवर्क डिवाइस गैर-दुर्भावनापूर्ण ट्रैफ़िक भेजते हैं जहां RDLENGTH RDATA के आकार के बराबर नहीं है, जिससे RFC 1035 टूट जाता है।

गलत नकारात्मक स्थिति (निशक्तता / शोषण का पता लगाने में विफल)
चूंकि पता लगाने का तर्क RDATA के “वास्तविक आकार” की गणना करते समय अपघटन नहीं करता है, यह दुर्भावनापूर्ण पैकेटों का पता लगाने में विफल होगा जिनमें डोमेन नाम शामिल हैं जिनकी लंबाई केवल विसंपीड़न के बाद RDLENGTH से अधिक है। दुर्भाग्य से, इस मामले के लिए कवरेज गैर-तुच्छ है क्योंकि ऐसे पैकेट वास्तव में आरएफसी-अनुपालन हैं। RFC 1035 के अनुसार, धारा 4.1.4:

यदि डोमेन नाम लंबाई क्षेत्र (जैसे RRR का RDATA अनुभाग) के रूप में संदेश विषय के एक भाग में समाहित है, और संपीड़न का उपयोग किया जाता है, तो संकुचित नाम की लंबाई लंबाई गणना में उपयोग की जाती है, लंबाई के बजाय विस्तृत नाम।

कम्प्यूटेशनल ओवरहेड के अलावा, इस तरह के चेक को लागू करने से बहुत अधिक झूठी सकारात्मक दरों का परिणाम होगा।

हस्ताक्षर):
dns_heap_overflow.rules:

# Variant 2
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_2.lua; sid:2020119012; rev:1;)
लुआ लिपि (dns_heap_overflow_variant_2.lua) में पाया जा सकता है परिशिष्ट A

रूटिंग हैडर टाइप 0 का उपयोग करके आउट-ऑफ-बाउंड्स लिखें

CVE: CVE-2,020-11,897
CVSS: 10
प्रोटोकॉल (ओं): आईपीवी 6
पोर्ट (ओं): एन / ए

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

एक द्वितीयक साइड इफेक्ट भी है जहां हम डिवाइस से लौटे ICMP पैरामीटर में एक स्रोत IPv6 पते में एक सूचना रिसाव प्राप्त कर सकते हैं।

पता लगाने के लिए सीमाएं या विशेष विचार:
RH0 के लिए RFC लंबाई फ़ील्ड को “हेडर में पतों की संख्या के दो गुना” के बराबर परिभाषित करता है। उदाहरण के लिए, यदि राउडिंग हेडर की लंबाई छह है, तो हेडर में तीन आईपीवी 6 पते अपेक्षित हैं। खंडित पैकेटों के पुनर्निर्माण के बाद, पते की संख्या पता लगाने वाले टुकड़ों से डेटा से भर जाती है। यह हेडर में “अमान्य” IPv6 पते बनाता है और संभावित रूप से पैकेट की अगली परत को विकृत करता है। शोषण के दौरान, पैकेट की अगली परत के विकृत होने की भी संभावना होगी। यद्यपि ICMP का उपयोग सूचना रिसाव करने के लिए किया जा सकता है, लेकिन अगली परत के लिए किसी भी प्रकार का होना संभव है और इसलिए लंबाई में भिन्नता है। इस परत की लंबाई का सत्यापन इसलिए बहुत महंगा और गैर-नियतात्मक हो सकता है।

अनुशंसित खोज मापदंड:

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

टिप्पणियाँ:
रूटिंग हेडर टाइप 0 को दिसंबर 2007 तक RFC 5095 में IPv6 ट्रैफ़िक में पदावनत कर दिया गया था। परिणामस्वरूप, इस मापदंड का उपयोग करके पैकेटों का पता लगाना संभव हो सकता है। विरासत उपकरणों या प्लेटफार्मों के लिए इस परिदृश्य में गलत सकारात्मकता संभव हो सकती है। Suricata इस परिदृश्य के लिए पहले से ही एक डिफ़ॉल्ट नियम प्रदान करता है जिसे नीचे जोड़ा गया है। RFC के अनुसार, राउटर IPv6 पैकेट को टुकड़े करने के लिए नहीं हैं और उन्हें 1280 के MTU का समर्थन करना चाहिए, जिसमें हमेशा RH0 हैडर के सभी शामिल होंगे, जब तक कि हेडर एक्सटेंशन की असामान्य मात्रा या असामान्य रूप से बड़े हेडर का उपयोग नहीं किया जाता है। यदि इसका पालन किया जाता है, तो RH0 हैडर का उपयोग करने वाले एक पैकेट को आरएच 0 एक्सटेंशन हेडर सीमा में कभी भी खंडित नहीं किया जाना चाहिए और इस तरीके से खंडित किसी भी आरएच 0 पैकेट को संभावित रूप से दुर्भावनापूर्ण माना जाना चाहिए। संभावित रूप से दुर्भावनापूर्ण के रूप में किसी भी खंडित RH0 पैकेट का इलाज करना पर्याप्त हो सकता है। इसके अलावा, किसी भी खंडित आरएच 0 पैकेट को थ्रेशोल्ड के नीचे के आकार के साथ-साथ कई एक्सटेंशन हेडर के साथ आईपीवी 6 पैकेट या थ्रेशोल्ड के ऊपर असामान्य रूप से बड़े हेडर के साथ उच्च सटीकता का पता लगाने का इलाज किया जा सकता है।

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

गलत नकारात्मक स्थितियां (जोखिम / शोषण का पता लगाने में विफल):
यदि IPv6 के बाद परत के लिए हस्ताक्षर विशिष्ट रूप से विकसित किए गए हैं, तो गलत निगेटिव हो सकता है, उदाहरण के लिए, ICMP। एक हमलावर संभावित रूप से एक और परत का लाभ उठा सकता है और फिर भी सूचना रिसाव के बिना भेद्यता का फायदा उठा सकता है; हालाँकि, यह अभी भी डिफ़ॉल्ट RH0 नियम को ट्रिगर करेगा। नीचे दिए गए दूसरे नियम में, गलत नकारात्मक होने की संभावना है यदि:

  • एक हमलावर IPv6 परत के बाद एक गैर-आईसीएमपी परत का उपयोग करता है
  • एक मान्य ICMP कोड का उपयोग किया जाता है
  • चेकसम मान्य है, और पेलोड 5 बाइट्स से कम या बराबर है (यह मान हस्ताक्षर में ट्यून किया जा सकता है)

हस्ताक्षर):
Ipv6_rh0.rules:

alert ipv6 any any -> any any (msg:"SURICATA RH Type 0"; decode-event:ipv6.rh_type_0; classtype:protocol-command-decode; sid:2200093; rev:2;)

alert ipv6 any any -> any any (msg:"IPv6 RH0 Treck CVE-2020-11897"; decode-event:ipv6.rh_type_0; decode-event:icmpv6.unknown_code; icmpv6-csum:invalid; dsize:>5; sid:2020118971; rev:1;)

IPv4 / UDP टनलिंग रिमोट कोड निष्पादन

CVE: CVE-2,020-11,896
CVSS: 10.0
प्रोटोकॉल (ओं): आईपीवी 4 / यूडीपी
पोर्ट (ओं): कोई भी

भेद्यता विवरण:
ट्रेक टीसीपी / आईपी स्टैक खंडित पेलोड डेटा के साथ आने वाले आईपीवी 4-इन-आईपीवी 4 पैकेट को ठीक से नहीं संभालता है। जब एक कमजोर मेजबान को कई विशेष रूप से तैयार किए गए सुरंग वाले यूडीपी पैकेट भेजते हैं, तो रिमोट कोड निष्पादन हो सकता है।

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

अनुशंसित खोज मापदंड:
चल रहे हमले का पता लगाने के लिए, निम्नलिखित शर्तों को पूरा किया जाना चाहिए अगर एनकैप्सुलेशन को अनपैक किया जा सकता है:

  • यूडीपी प्राप्त कतार गैर-रिक्त होनी चाहिए
  • आने वाले यूडीपी पैकेट को खंडित किया जाना चाहिए
      • किसी भी ऑफसेट के साथ ध्वज एमएफ = 1, या
      • गैर-शून्य ऑफसेट के साथ एमएफ = 0
  • खंडित पैकेट में IPv4 पैकेट (असेंबली में) होना चाहिए
    प्रोटोकॉल = 0x4 (IPIP)
  • Encapsulated IPv4 पैकेट को 2 पैकेट अंशों में विभाजित किया जाना चाहिए।
  • Reassembled (आंतरिक-सबसे) IPv4 पैकेट में IP हेडर में संग्रहीत डेटा की लंबाई गलत है।

उपरोक्त चौथी स्थिति कोड-पथ को सक्रिय करने के लिए आवश्यक है, जो कमजोर है, क्योंकि यह कई-इन-मेमोरी बफ़र्स में कॉपी किए जाने वाले डेटा को फैलाता है। अंतिम पता लगाने का चरण बफर अतिप्रवाह का स्रोत है, जैसे कि, इस पर ट्रिगर पर्याप्त हो सकता है।

प्रश्न में नेटवर्क निरीक्षण उपकरण की सीमाओं के आधार पर, एक शिथिल स्थिति का उपयोग किया जा सकता है, हालांकि यह गलत सकारात्मक के लिए अधिक प्रवण हो सकता है।

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

  • यूडीपी प्राप्त कतार गैर-रिक्त होनी चाहिए
  • आने वाले यूडीपी पैकेट को खंडित किया जाना चाहिए
      • ऑफसेट फ़ील्ड में किसी भी मूल्य के साथ ध्वज एमएफ = 1, या
      • ऑफ़सेट क्षेत्र में किसी भी गैर-शून्य मान के साथ ध्वज एमएफ = 0
  • अंतिम विखंडन में ऑफ़सेट फ़ील्ड की तुलना में कुल विखंडन की लंबाई होती है।

ऊपर दिखाई गई अंतिम स्थिति कुछ ऐसी नहीं है जिसे एक सामान्य नेटवर्क में देखा जाना चाहिए।

जब यह होता है, तो विखंडन, किसी दिए गए पैकेट प्रकार के MTU को ओवरफ्लो करने वाले डेटा का परिणाम होता है। यह इंगित करता है कि अंतिम टुकड़ा किसी भी अन्य टुकड़े से बड़ा नहीं होना चाहिए – और व्यवहार में संभवतः छोटा होगा। व्युत्क्रम, जहां अंतिम टुकड़ा पिछले टुकड़े से किसी तरह बड़ा होता है, यह दर्शाता है कि विखंडन MTU अतिप्रवाह का परिणाम नहीं है, बल्कि इसके बजाय कुछ और है। इस मामले में, दुर्भावनापूर्ण इरादे।

जैसा कि सामान्य उपयोग में नेटवर्क मॉनिटर के पास इनकैप्सुलेशन को अनपैक करने की क्षमता होने की संभावना है, केवल उस नियम को प्रदान किया जाता है।

पता लगाने के लिए सीमाएं या विशेष विचार:
ट्रेक स्टैक सुरंग के दो स्तरों (कम से कम) का समर्थन करता है। प्रत्येक सुरंग स्तर IPv4-in-IPv4, IPv6-in-IPv4 या IPv4-in-IPv6 हो सकता है। उपरोक्त तर्क IPv4-in-IPv4 के लिए विशिष्ट है, सुरंग के मामले का एकल स्तर। गहरी घोंसले के शिकार के मामलों में, या तो एक पुनरावर्ती जांच या सभी सुरंगों की परतों की पूरी अल्ट्रापिंग आवश्यक होगी।

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

गलत नकारात्मक स्थितियां (भेद्यता / शोषण का पता लगाने में विफल)
झूठी निगिंग IPv6 के घोंसले के शिकार या घोंसले के गहरे स्तर के साथ हो सकती है।

हस्ताक्षर):
ipv4_tunneling.rules:

alert ip any any -> any any (msg:"IPv4 TUNNELING EXPLOIT (CVE‑2020‑11896)"; ip_proto:4; lua:tunnel_length_check.lua; sid:2020118961; rev:1;)
लुआ स्क्रिप्ट (टनल_लिफ्ट_चेक.लुआ) में पाया जा सकता है परिशिष्ट A

परिशिष्ट A

परिशिष्ट A में Lua स्क्रिप्ट हैं जो कि संबंधित सुरिकटा हस्ताक्षर के उपयोग के लिए आवश्यक हैं। ये स्क्रिप्ट McAfee ATR के GitHub पर भी स्थित हैं

dns_tcp_sizeएलua:

dns_size।एलua:

dns_invalid_name.lua:

dns_heap_overflow_variant_1.lua:

dns_heap_overflow_variant_2.lua:

tunnel_length_check.lua: