LDAP Relay Scan

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

सारांश

डोमेन कंट्रोलर्स पर NTLM प्रमाणीकरण LDAP को रिले करने का प्रयास करते समय कुछ सर्वर-साइड सुरक्षाएँ होती हैं। यह टूल जिन LDAP सुरक्षाओं की गणना करने का प्रयास करता है उनमें शामिल हैं:

• LDAPS - channel binding
• LDAP - server signing requirements

LDAP over SSL/TLS के लिए channel binding का प्रवर्तन एक अप्रमाणित (unauthenticated) दृष्टिकोण से निर्धारित किया जा सकता है। ऐसा इसलिए है क्योंकि channel binding को ठीक से करने में असमर्थ LDAP क्लाइंट से जुड़ी त्रुटि, LDAP बाइंड प्रक्रिया के दौरान क्रेडेंशियल्स के सत्यापित होने से पहले ही उत्पन्न हो जाती है।

हालाँकि, यह निर्धारित करने के लिए कि मानक LDAP की सर्वर-साइड सुरक्षा लागू है या नहीं (server signing integrity requirements), क्लाइंट के क्रेडेंशियल्स को पहले LDAP बाइंड के दौरान सत्यापित किया जाना चाहिए। इस सुरक्षा के प्रवर्तन की पहचान करने वाली संभावित त्रुटि को प्रमाणित (authenticated) दृष्टिकोण से पहचाना जाता है।

TL;DR - LDAPS को बिना प्रमाणीकरण के जांचा जा सकता है, लेकिन LDAP की जांच के लिए प्रमाणीकरण आवश्यक है।

स्थापना

इस प्रोजेक्ट को चलाते समय Docker या Python वर्चुअल वातावरण का उपयोग करने की अनुशंसा की जाती है।

Docker

1. सुनिश्चित करें कि आपकी मशीन पर docker स्थापित है
2. रिपॉजिटरी को क्लोन करें और डायरेक्टरी बदलें
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Docker कंटेनर बनाएँ
   • docker build -f docker/Dockerfile -t ldaprelayscan .
4. [वैकल्पिक रूप से] सुनिश्चित करें कि स्क्रिप्ट ठीक से चलती है
   • docker run ldaprelayscan -h

Python वर्चुअल वातावरण

1. सुनिश्चित करें कि आपकी मशीन पर python virtualenv स्थापित है
2. रिपॉजिटरी को क्लोन करें और डायरेक्टरी बदलें
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. प्रोजेक्ट के लिए Python वर्चुअल वातावरण बनाएँ
   • virtualenv env
4. Python वर्चुअल वातावरण सक्रिय करें
   • source venv/bin/activate
5. सटीक आवश्यकता संस्करण निर्भरताएँ स्थापित करें
   • python3 -m pip install -r requirements_exact.txt
6. [वैकल्पिक रूप से] सुनिश्चित करें कि स्क्रिप्ट ठीक से चलती है
   • python3 LdapRelayScan.py -h

उपयोग

नोट: DNS को सही ढंग से रिज़ॉल्व होना आवश्यक है। यदि आप SOCKS के माध्यम से रूटिंग कर रहे हैं या किसी गैर-डोमेन-जुड़े होस्ट पर चला रहे हैं, तो सुनिश्चित करें कि यह काम कर रहा है।

इस टूल में दो विधियाँ हैं, LDAPS (डिफ़ॉल्ट), और BOTH। LDAPS के लिए केवल डोमेन कंट्रोलर का IP पता चाहिए, क्योंकि यह जांच बिना प्रमाणीकरण के की जा सकती है। BOTH विधि के लिए उपयोगकर्ता नाम और पासवर्ड या NT हैश की आवश्यकता होगी। Active Directory डोमेन की आवश्यकता नहीं है, यह अनाम LDAP बाइंड के माध्यम से निर्धारित किया जाएगा।

arguments:
  -h, --help        show this help message and exit
  -method method    LDAPS or BOTH - LDAPS checks for channel binding, BOTH checks for LDAP signing and LDAP channel binding [authentication required]
  -dc-ip DC_IP      DNS Nameserver on network. Any DC's IPv4 address should work.
  -u username       Domain username value.
  -timeout timeout  The timeout for MSLDAP client connection.
  -p password       Domain username value.
  -nthash nthash    NT hash of password

उदाहरण

बुनियादी / वर्चुअल वातावरण उपयोग उदाहरण

python3 LdapRelayScan.py -method LDAPS -dc-ip 10.0.0.20
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -p badpassword2
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -nthash e6ee750a1feb2c7ee50d46819a6e4d25

Docker उपयोग उदाहरण

नोट: SOCKS का उपयोग करने की क्षमता PROXY_CONFIG पर्यावरण चर के माध्यम से पारित की जाती है। यदि SOCKS आवश्यक है, तो ट्रैफ़िक को सही ढंग से रूट करने के लिए --network=host फ्लैग का भी उपयोग करना होगा। नीचे दिए गए उदाहरण देखें।

docker run ldaprelayscan -h
docker run ldaprelayscan -dc-ip 10.0.0.20
docker run ldaprelayscan -dc-ip 10.0.0.20 -method BOTH -u domainuser1 -p secretpass
docker run -e PROXY_CONFIG='socks5 127.0.0.1 9050' --network=host ldaprelayscan -dc-ip 10.0.0.20 -method BOTH -u domainuser1 -p secretpass

त्रुटि-आधारित गणना की विशिष्टताएँ

[LDAPS] Channel Binding Token आवश्यकताएँ

एक डोमेन कंट्रोलर पर जिसे CVE-2017-8563 के बाद पैच किया गया है, LDAPS channel binding को लागू करने की क्षमता मौजूद है। विशिष्ट पॉलिसी को Domain Controller: LDAP server channel binding token requirements कहा जाता है और इसे Never, When supported, या Always पर सेट किया जा सकता है। यह डिफ़ॉल्ट रूप से आवश्यक नहीं है (इस लेखन के समय)।

डोमेन कंट्रोलर पर LDAP over SSL/TLS ट्रैफ़िक को डिक्रिप्ट और मॉनिटर करने से बाइंड प्रयासों के दौरान त्रुटियों में अंतर की पहचान करने में मदद मिली, जब channel binding लागू होती है बनाम जब नहीं होती। अमान्य क्रेडेंशियल्स का उपयोग करके LDAP over SSL/TLS पर बाइंड करने का प्रयास करते समय, आपको अपेक्षित resultCode 49 प्राप्त होगा, और त्रुटि संदेश सामग्री में आपको data 52e दिखाई देगा। हालाँकि, जब channel binding लागू होती है और LDAP क्लाइंट Channel Binding Token (CBT) की गणना और समावेश नहीं करता है, तो resultCode अभी भी 49 होगा, लेकिन त्रुटि संदेश सामग्री में data 80090346 होगा जिसका अर्थ है SEC_E_BAD_BINDINGS या क्लाइंट का Supplied Support Provider Interface (SSPI) channel bindings गलत था।

नोट: LDAP over SSL/TLS बाइंडिंग के दौरान data 8009034 त्रुटि का उल्लेख [1] [2] [3] [4] [5]

"Never" बनाम "When supported" बनाम "Always"

यह विशिष्ट त्रुटि तब सरलता से समझ में आती है जब Domain Controller: LDAP server channel binding token requirements पॉलिसी को Always पर सेट किया जाता है। बस एक ऐसे क्लाइंट का उपयोग करके NTLM-आधारित LDAPS बाइंड का प्रयास करें जो channel binding का समर्थन नहीं करता है, और प्रतिक्रिया में त्रुटि के भीतर data 80090346 देखें। लेकिन जब पॉलिसी Always पर सेट नहीं है, जब यह When supported पर सेट है तो क्या होगा? उत्तर यह है: NTLM-आधारित प्रमाणीकरण के साथ LDAPS पर बाइंड करें और जानबूझकर channel binding जानकारी की गलत गणना करें।

सबसे पहले, हमें एक LDAP क्लाइंट चाहिए जो channel binding का समर्थन करता हो। msldap में SkelSec का यह कार्यान्वयन एक PoC लागू करने के लिए उपयोग किया जाएगा। Channel binding NTLM चुनौती/प्रतिक्रिया प्रक्रिया के दौरान एक AV_PAIR मान के रूप में दिखाई देती है, विशेष रूप से Type 3 या AUTHENTICATE_MESSAGE के भीतर। यहाँ डोमेन कंट्रोलर पर कुछ डिक्रिप्टेड LDAPS ट्रैफ़िक पर एक और नज़र है, यह देखने के लिए कि channel binding का समर्थन करने वाले क्लाइंट से बाइंड प्रयास कैसा दिखेगा:

प्रश्न में पॉलिसी को When supported पर सेट होने पर, इस मान की जानबूझकर गलत गणना करने से वही data 80090346 त्रुटि उत्पन्न होगी। यह हमें इस पॉलिसी के वर्तमान में मौजूद सभी संभावित सेटिंग्स के बीच अंतर करने की क्षमता देता है, बिना प्रमाणीकरण के दृष्टिकोण से। यह मान जानबूझकर कैसे गलत गणना किया जाता है, यह महत्वपूर्ण है, क्योंकि चुनौती/प्रतिक्रिया के दौरान मान को केवल मैन्युअल रूप से बदलने से MIC अमान्य हो जाएगा।

[LDAP] सर्वर साइनिंग आवश्यकताएँ

एक डोमेन कंट्रोलर पर, Domain Controller: LDAP server signing requirements नामक पॉलिसी None, Require signing पर सेट होती है, या इसे परिभाषित ही नहीं किया जाता है। जब परिभाषित नहीं होता है, तो यह डिफ़ॉल्ट रूप से साइनिंग की आवश्यकता नहीं रखता है (इस लेखन के समय)। यह पहचानने वाली त्रुटि कि यह सुरक्षा आवश्यक है, तब होती है जब sicily NTLM या simple बाइंड प्रयास resultCode 8 के साथ प्रतिक्रिया करता है, जो strongerAuthRequired दर्शाता है। यह केवल तभी होगा जब LDAP बाइंड के दौरान क्रेडेंशियल्स सत्यापित हों।

संदर्भ

इस सामग्री को संदर्भित करने और यह सामान्य हमले के परिदृश्यों में कैसे फिट होती है, इसके लिए कुछ अमूल्य संसाधन।

• @HackAndDo - NTLM रिले
• @_nwodtuhs - NTLM रिले माइंडमैप
• @_dirkjan - PrivExchange, ADCS ESC8 लेख, RBCD के लिए NTLM रिले लेख, और अधिक
• @domchell - Farmer का कार्यान्वयन और व्याख्या
• @elad_shamir - कई परिदृश्यों में RBCD के दुरुपयोग की गहन व्याख्या, और shadow credentials
• @tifkin_ & @topotam77 - NTLM प्रमाणीकरण मजबूरी विधियाँ
• @skelsec - msldap चैनल बाइंडिंग के समर्थन के साथ