zyn3rgy/ldaprelayscanالتحقق من حمايات LDAP المتعلقة بترحيل مصادقة NTLM
أداة لفحص وحدات تحكم المجال (Domain Controllers) بحثًا عن حمايات خادم LDAP المتعلقة بترحيل مصادقة NTLM. إذا كنت مهتمًا بتفاصيل التعداد القائم على الأخطاء، راجع بالأسفل. للحصول على تفاصيل حول ما يمكن فعله عند تحديد غياب حمايات LDAP، راجع قسم المراجع.
توجد حمايتان من جهة الخادم عند محاولة ترحيل مصادقة NTLM عبر LDAP على وحدات تحكم المجال. تتضمن حمايات LDAP التي تحاول هذه الأداة تعدادها:
يمكن تحديد فرض ربط القناة لـ LDAP عبر SSL/TLS من منظور غير مصادَق (unauthenticated). وذلك لأن الخطأ المرتبط بعميل LDAP الذي يفتقر إلى القدرة على إجراء ربط القناة بشكل صحيح سيحدث قبل التحقق من بيانات الاعتماد أثناء عملية ربط LDAP.
ومع ذلك، لتحديد ما إذا كانت الحماية من جهة الخادم لـ LDAP القياسي مفروضة (متطلبات سلامة توقيع الخادم)، يجب أولاً التحقق من بيانات اعتماد العميل أثناء ربط LDAP. يتم تحديد الخطأ المحتمل الذي يشير إلى فرض هذه الحماية من منظور مصادَق (authenticated).
يُوصى باستخدام Docker أو بيئة Python افتراضية عند تشغيل هذا المشروع.
git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScandocker build -f docker/Dockerfile -t ldaprelayscan .docker run ldaprelayscan -hgit clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScanvirtualenv envsource venv/bin/activatepython3 -m pip install -r requirements_exact.txtpython3 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
ملاحظة: يتم تمرير إمكانية استخدام 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
على وحدة تحكم المجال التي تم تحديثها منذ CVE-2017-8563، كانت هناك إمكانية فرض ربط قناة LDAPS. تُسمى السياسة المحددة Domain Controller: LDAP server channel binding token requirements ويمكن ضبطها على Never أو When supported أو Always. وهذا غير مطلوب افتراضيًا (وقت كتابة هذا النص).
سمح فك تشفير ومراقبة حركة مرور LDAP عبر SSL/TLS على وحدة تحكم المجال بتحديد الفرق في الأخطاء أثناء محاولات الربط عندما يكون ربط القناة مفروضًا مقابل عندما لا يكون مفروضًا. عند محاولة الربط بـ LDAP عبر SSL/TLS باستخدام بيانات اعتماد غير صالحة، ستتلقى resultCode 49 المتوقع، وسترى في محتويات رسالة الخطأ data 52e. ومع ذلك، عندما يكون ربط القناة مفروضًا ولا يقوم عميل LDAP بحساب وتضمين رمز ربط القناة (CBT)، فسيظل resultCode 49، لكن محتويات رسالة الخطأ ستحتوي على data 80090346 مما يعني SEC_E_BAD_BINDINGS أو أن روابط قناة واجهة مزود الدعم (SSPI) التي قدمها العميل كانت غير صحيحة.
ملاحظة: إشارات إلى خطأ
data 8009034أثناء ربط LDAP عبر SSL/TLS [1] [2] [3] [4] [5]
هذا الخطأ المحدد يجعل من السهل التعامل مع الحالة عندما تكون سياسة Domain Controller: LDAP server channel binding token requirements مضبوطة على Always. ببساطة، حاول إجراء ربط LDAPS قائم على NTLM باستخدام عميل لا يدعم ربط القناة وابحث عن data 80090346 داخل الخطأ في الاستجابة. ولكن ماذا لو لم تكن السياسة مضبوطة على Always، ماذا لو كانت مضبوطة على When supported؟ الإجابة هي: اربط بـ LDAPS باستخدام مصادقة قائمة على NTLM وقم عمدًا بحساب خاطئ لمعلومات ربط القناة.
أولاً، نحتاج إلى عميل LDAP يدعم ربط القناة. سيتم استخدام تنفيذ SkelSec's لهذا في msldap لتنفيذ PoC. يظهر ربط القناة كقيمة AV_PAIR أثناء عملية تحدي/استجابة NTLM، وتحديدًا داخل Type 3 أو AUTHENTICATE_MESSAGE. إليك نظرة أخرى على بعض حركة مرور LDAPS المفككة على وحدة تحكم المجال لمعرفة كيف تبدو محاولة الربط من عميل يدعم ربط القناة:
الحساب الخاطئ المتعمد لهذه القيمة، عندما تكون السياسة المعنية مضبوطة على When supported، سيُنتج نفس خطأ data 80090346. وهذا يمنحنا القدرة على التمييز بين جميع الإعدادات الممكنة لهذه السياسة كما هي موجودة حاليًا، من منظور غير مصادَق. كيفية حساب هذه القيمة بشكل خاطئ عن قصد أمر مهم، لأن مجرد استبدال القيمة يدويًا أثناء تحدي/استجابة سيبطل MIC.
على وحدة تحكم المجال، تكون السياسة المسماة Domain Controller: LDAP server signing requirements مضبوطة على None أو Require signing أو غير معرّفة فقط. عندما تكون غير معرّفة، يكون الافتراضي هو عدم اشتراط التوقيع (وقت كتابة هذا النص). الخطأ الذي يحدد أن هذه الحماية مطلوبة هو عندما تستجيب محاولة ربط Sicily NTLM أو بسيط بـ resultCode بقيمة 8، مما يشير إلى strongerAuthRequired. يحدث هذا فقط إذا تم التحقق من بيانات الاعتماد أثناء ربط LDAP.
بعض الموارد القيّمة للغاية لوضع هذه المادة في سياقها وفهم كيفية توافقها مع سيناريوهات الهجوم الشائعة.