स्क्रिप्ट चलाएँ:

भेद्यता को पुनः उत्पन्न करने का सबसे आसान तरीका लक्ष्य प्रणाली पर bcdedit /set debug on का उपयोग करना और मशीन/VM को पुनरारंभ करना है। यह डिफ़ॉल्ट नेटवर्क एडेप्टर ड्राइवर kdnic.sys बनाता है, जो पैकेट को सम्मिलित करने के लिए बहुत उत्सुक है। यदि आप किसी भिन्न सेटअप पर भेद्यता को पुनः उत्पन्न करने का प्रयास कर रहे हैं, तो आपको सिस्टम को ऐसी स्थिति में लाना होगा जहां वह आपके द्वारा भेजे गए पैकेट को सम्मिलित करेगा। अधिक विवरण के लिए आप नीचे समस्या निवारण अनुभाग पढ़ सकते हैं।

डेमो

cve-2024-38063.webm

मोटा आरसीए

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

• कुछ स्थितियों में, विंडोज़ एक साथ कई IP पैकेटों को सम्मिलित करेगा और उन्हें बैच प्रोसेस करेगा। यह पहले प्रत्येक पैकेट में एक्सटेंशन हेडर को संसाधित करता है, और उसके बाद ही प्रत्येक पैकेट में डेटा को संसाधित करने के लिए आगे बढ़ता है।
• एक्सटेंशन हेडर प्रोसेसिंग के दौरान, इन सम्मिलित पैकेटों के पैकेट ऑब्जेक्ट एक लिंक्ड लिस्ट में एक साथ जुड़े होते हैं। प्रत्येक पैकेट ऑब्जेक्ट में एक NET_BUFFER ऑब्जेक्ट होता है जिसमें बफ़र्ड पैकेट डेटा होता है। ऑफ़सेट 0x30 पर हमारे पास एक current-offset फ़ील्ड भी है जो इंगित करता है कि पैकेट को कितना पार्स किया गया है। इस चरण में, ऑफ़सेट मान आम तौर पर 0x28 होगा, यह दर्शाता है कि IPv6 हेडर पार्स किया गया है लेकिन कुछ और नहीं।
• जब tcpip!Ipv6pReceiveDestinationOptions में "destination options" एक्सटेंशन हेडर को संसाधित किया जाता है, तो एक पार्सिंग त्रुटि के परिणामस्वरूप tcpip!IppSendErrorList को कॉल किया जाएगा। यह फ़ंक्शन लिंक्ड लिस्ट में प्रत्येक पैकेट ऑब्जेक्ट (वर्तमान से शुरू) पर tcpip!IppSendError को कॉल करता है।
• कुछ शर्तों के तहत (जैसे कि यदि पैकेट यूनिकास्ट है), tcpip!IppSendError के दुष्प्रभाव होते हैं। यह बफ़र्ड पैकेट डेटा को वापस शुरुआत में "वापस लाता है" और current-offset फ़ील्ड को शून्य पर रीसेट करता है।
• हालाँकि, घटनाओं की इस पूरी श्रृंखला में, केवल पहले पैकेट को त्रुटि के रूप में चिह्नित किया गया है (ऑफ़सेट 0x8C)। इसका मतलब है कि ड्राइवर लिंक्ड लिस्ट में अन्य पैकेटों के एक्सटेंशन हेडर को पार्स करना जारी रखेगा, भले ही उन्हें IppSendError में "वापस लाया" गया हो।
• जिन पैकेटों को वापस लाया गया है, उनका प्रसंस्करण तब अप्रत्याशित डेटा के साथ किया जाता है: बफ़र्ड पैकेट डेटा एक्सटेंशन हेडर के बजाय पैकेट की शुरुआत (अर्थात IPv6 हेडर) की ओर इशारा कर रहा है, और ऑफ़सेट फ़ील्ड मान 0x28 के बजाय शून्य है।

रणनीति

• भेद्यता का दुरुपयोग करने के लिए, हम Ipv6pReceiveFragment का उपयोग करते हैं। फ़ंक्शन खंड विस्तार हेडर को पार्स करता है और मानता है कि पैकेट में गैर-हेडर डेटा की लंबाई की गणना करते समय पैकेट का ऑफ़सेट फ़ील्ड कम से कम 0x28 होगा, जो वर्तमान ऑफ़सेट मान से 0x30 घटाकर किया जाता है। यह मान तब पुनः जोड़ने वाली वस्तु में संग्रहीत किया जाता है जिसका उद्देश्य खंडित पैकेट को फिर से जोड़ना है।
• हमारे मामले में, फ़ंक्शन को एक पैकेट पर कॉल किया जाएगा जिसे IppSendError द्वारा वापस लाया गया है। ऑफ़सेट मान शून्य होगा और Ipv6pReceiveFragment में पहले कहीं 8 तक बढ़ा दिया जाएगा। गैर-हेडर डेटा के आकार की गणना करते समय, मान अंडरफ़्लो होगा और 0xffd8 के बराबर होगा (घटाव 16 बिट में किया जाता है)।
• लंबाई मान का उपयोग बाद में केवल दो स्थानों पर किया जाता है:
  • Ipv6pReassembleDatagram, जहां इसका उपयोग पुनः जुड़े पैकेट के आउटपुट बफर की लंबाई की गणना करने के लिए किया जाता है। हालाँकि, सभी गणनाएँ 32-बिट में की जाती हैं और एक सैनिटी चेक होता है कि कुल लंबाई 0xFFFF से अधिक नहीं है, जो इस मामले में होता है।
  • Ipv6pReassemblyTimeout, जहां इसी तरह से इसका उपयोग किया जाता है। हालाँकि, यहाँ गणना 16 बिट में की जाती है और एक पूर्णांक ओवरफ़्लो होता है। इससे बाद में बफर में डेटा कॉपी करते समय बफर ओवरफ़्लो होता है।

Ipv6pReassemblyTimeout को ट्रिगर करने के लिए, खंड के भेजने वाले को 1 मिनट तक निष्क्रिय रहना होगा। तब हमारी रणनीति है:

• IppSendError को ट्रिगर करने के लिए दूषित गंतव्य विकल्प भेजें, उसके बाद एक खंड पैकेट भेजें
• उम्मीद करें कि दोनों पैकेट सम्मिलित हो जाएं और दूसरे पैकेट के ऑब्जेक्ट का डेटा और ऑफ़सेट रीसेट हो जाए
• Ipv6pReceiveFragment में अंडरफ़्लो का कारण बनें और उच्च 16-बिट मान के साथ एक नया पुनः जोड़ने वाला ऑब्जेक्ट बनाएं जिसमें खंड डेटा लंबाई हो
• 1 मिनट तक प्रतीक्षा करें बिना कोई और पैकेट भेजे ताकि Ipv6pReassemblyTimeout ट्रिगर हो।
• Ipv6pReassemblyTimeout में बफर आकार गणना में पूर्णांक ओवरफ़्लो का कारण बनें और हीप-आधारित बफर ओवरफ़्लो ट्रिगर करें।

स्क्रिप्ट में पैकेटों को स्पैम किया जाता है ताकि उनके सम्मिलित होने की अधिक संभावना हो। मुख्य पेलोड काफी सरल है:

• एक "destination options" एक्सटेंशन हेडर वाला IPv6 पैकेट जिसमें दूषित विकल्प डेटा हो जो पार्सिंग में त्रुटि उत्पन्न करेगा
• IPv6 खंड #1, जिसे हम उम्मीद करते हैं कि पहले पैकेट से जुड़ जाएगा
• IPv6 खंड #2 (समान आईडी), जो पहले दो से भी जुड़ सकता है, लेकिन इसका मुख्य उद्देश्य दूसरे खंड को पूरा करना है ताकि सामान्य प्रसंस्करण के मामले में त्रुटियाँ न निकलें

हम IPv6 हेडर में hop limit और flow label फ़ील्ड को मैन्युअल रूप से भी सेट करते हैं। याद रखें कि बफ़र्ड पैकेट डेटा भेद्यता के कारण रीसेट हो जाता है। इसका मतलब है कि, खंड पैकेट को संसाधित करते समय, IPv6 हेडर को खंड हेडर डेटा के रूप में व्याख्यायित किया जाएगा। IPv6 हेडर में hop limit फ़ील्ड को खंड हेडर में id फ़ील्ड के एक बिट के रूप में व्याख्यायित किया जाएगा। इसे बदलकर, हम सुनिश्चित करते हैं कि हम कई अलग-अलग खंडों के लिए भेद्यता को ट्रिगर करते हैं और कई अलग-अलग भ्रष्टाचार का कारण बनते हैं, जिससे क्रैश की संभावना बढ़ जाती है (आखिरकार यह एक PoC ही है)। ip हेडर का flow limit फ़ील्ड खंड हेडर के ऑफ़सेट और "more indicator" फ़ील्ड के रूप में व्याख्यायित किया जाएगा। इसे 1 पर सेट करके, हम संकेत देते हैं कि आने वाले और हेडर हैं (इसलिए बाद में Ipv6pReassemblyTimeout को ट्रिगर करने में सक्षम) और ऑफ़सेट शून्य है (क्योंकि यह ऐसी id वाला पहला पैकेट है जो आ रहा है)।

नोट्स

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

समस्या निवारण

यदि यह काम नहीं कर रहा है, तो इसका कारण हो सकता है:

• लक्ष्य प्रणाली तक IPv6 के माध्यम से नहीं पहुंचा जा सकता:
  • विंडोज़ फ़ायरवॉल अक्षम करें
  • होस्ट पीसी से ping -6 {ipv6_address} चलाएँ
  • सुनिश्चित करें कि आपको प्रतिक्रिया मिल रही है
  • फ़ायरवॉल को पुनः सक्षम करें
• लक्ष्य प्रणाली पैकेट प्राप्त नहीं कर रही है:
  • लक्ष्य प्रणाली पर wireshark स्थापित करें और जांचें कि स्क्रिप्ट द्वारा भेजे गए पैकेट आ रहे हैं
• scapy रिपोर्ट कर रहा है "Mac address to reach destination not found. Using broadcast."
  • आपको लक्ष्य मशीन का मैक पता खोजना होगा
  • यह ऊपर दिए गए ping कमांड को चलाकर और wireshark में उत्तर की जांच करके (eth स्रोत पता फ़ील्ड) किया जा सकता है
  • आप scapy का भी उपयोग कर सकते हैं: Ether(raw(sr1(IPv6(dst={your_dest_ip})/ICMPv6EchoRequest()))).src, लेकिन यह कभी-कभी काम नहीं करता
  • एक बार जब आपके पास मैक पता हो, तो इसे स्क्रिप्ट में mac_addr फ़ील्ड में डालें और स्क्रिप्ट चलाएँ
• लक्ष्य प्रणाली पर पैकेट सम्मिलित नहीं हो रहे हैं:
  • आपके एडेप्टर नेटवर्क एडेप्टर / ड्राइवर के आधार पर, विंडोज़ को पैकेट सम्मिलित करने के लिए प्राप्त करना मुश्किल हो सकता है बिना लक्ष्य को ddos जैसी किसी चीज़ से भरने का सहारा लिए।
  • आप अपनी एडेप्टर सेटिंग्स को संशोधित करने का प्रयास कर सकते हैं, उदाहरण के लिए "Packet Coalescing", "Interrupt Moderation", "Interrupt Moderation Mode", "Recv Segment Coalescing", जो भी उपलब्ध हों। उदाहरण के लिए, मेरे समर्पित सर्वर पर "Interrupt Moderation Mode" को "Extreme" पर सेट करने से भेद्यता पुन: उत्पन्न हो जाती है।
• यदि बाकी सब विफल हो जाता है, तो आप एक कर्नेल डीबगर संलग्न कर सकते हैं और कुछ चीजों की जांच कर सकते हैं:
  • क्या tcpip!Ipv6pReceiveDestinationOptions -> tcpip!Ipv6pProcessOptions -> tcpip!IppSendErrorList हिट हो रहा है?
  • tcpip!Ipv6pProcessOptions पर ब्रेक लगाएं और जांचें कि क्या [rcx] हर समय शून्य है। यदि हाँ, तो पैकेट किसी कारण से सम्मिलित नहीं हो रहे हैं।
  • tcpip!Ipv6pReceiveFragment पर ब्रेक लगाएं और जांचें कि क्या [rcx+0x30] शून्य के बराबर है। यदि नहीं, तो भेद्यता किसी कारण से ट्रिगर होने में विफल रही।