fortra/cve-2024-6769كتابة تقنية وإثبات مفهوم (PoC) لثغرة CVE-2024-6769، تجمع بين اختطاف DLL وتسميم ذاكرة التخزين المؤقت للتنشيط لتصعيد الصلاحيات من مستوى النزاهة المتوسط إلى العالي على أنظمة ويندوز.
يتعلق هذا المقال بثغريتين مترابطتين: المرحلة الأولى هي ثغرة اختطاف DLL ناتجة عن إعادة تعيين محرك الأقراص الجذر (ROOT drive)، والمرحلة الثانية هي ثغرة تسميم ذاكرة التخزين المؤقت للتفعيل (Activation Cache Poisoning) التي يديرها خادم CSRSS.
تم تقديم المرحلة الأولى بالتفصيل في مؤتمر Ekoparty 2023 في العرض التقديمي المسمى "I'm High" من قبل نيكولاس إيكونومو من BlueFrost Security. شرح كيفية استغلال الثغرة التي لم تكن قد صُححت بعد من قبل مايكروسوفت في ذلك الوقت. سمح ذلك لمستخدم بصلاحية سلامة متوسطة (MEDIUM INTEGRITY) بالارتقاء للحصول على صلاحيات سلامة عالية محدودة (limited HIGH PRIVILEGES)، ولكن دون الوصول الكامل ليكون مسؤولاً كاملاً.
لم تُعرض المرحلة الثانية في ذلك المؤتمر، على الرغم من اقتراح بعض الخطوات لبدء البحث فيها.
للبدء، سنستعرض المرحلة الأولى لتوفير سياق تمهيدي. من هناك، سنتعمق في بحثي حول المرحلة الثانية، ونتناول تفاصيل تحقيق الارتقاء الكامل من سلامة عالية محدودة (limited HIGH INTEGRITY) إلى مسؤول كامل (full Administrator). يتضمن ذلك برهان مفهوم (PoC) عملي كامل للمرحلتين لجميع إصدارات ويندوز، والذي تم اختباره بنجاح في ويندوز 10، ويندوز 11، ويندوز سيرفر 2022، ويندوز سيرفر 2019 مع جميع التحديثات المطبقة.
الشرط الوحيد لهذه المرحلة هو أن تبدأ العملية بمستوى سلامة متوسطة (MEDIUM INTEGRITY LEVEL) وأن ينتمي المستخدم إلى مجموعة المسؤولين.
يمكن تلخيص المرحلة الأولى من الاستغلال في الخطوات التالية:
مثال: إعادة تعيين القرص من
"C:\" إلى "C:\users\public"
سيؤدي هذا أيضاً إلى إعادة تعيين مجلد "system32" من
"C:\windows\system32" إلى "C:\users\public\windows\system32"
أحد البرامج المتأثرة هو CTFMON، والذي يعمل بمستوى سلامة عالية (HIGH INTEGRITY LEVEL) ولكن بدون صلاحيات المسؤول.
عادةً، يحاول تحميل الوحدة المسماة MsCtfMonitor.dll من مجلد system32 الحقيقي، ولكن نظراً لإعادة تعيين محرك الأقراص الجذر، فإنه يبحث عن MsCtfMonitor.dll في مجلد system32 المزيف الذي نتحكم به، حيث يمكننا إنشاء ووضع ملف DLL مصمم بنفس الاسم.
في هذه المرحلة، من خلال وضع نسختنا من MsCtfMonitor.dll في مجلد system32 المزيف، يتم استدعاء دالة DoMsCtfMonitor الخاصة بها وتنفيذ الكود الخاص بنا بمستوى سلامة عالية.
في الوقت نفسه، يمكننا التأكد من أن العملية، على الرغم من كونها بمستوى سلامة عالية، لا تملك صلاحيات المسؤول:
في عرضه التقديمي في Ekoparty، اقترح نيكولاس الخطوات التالية لإكمال الاستغلال:
بينما يبدو هذا بسيطاً، إلا أنه يتطلب الكثير من الوقت للهندسة العكسية والتصحيح.
عند التعمق قليلاً في قصة ناقل الهجوم هذا، أصبح من الواضح أن تسميم ذاكرة التخزين المؤقت لسياق التفعيل (Activation Context Cache) قد استُخدم في بعض الاستغلالات. وبالتالي، من المفيد تعلم كيفية الاستغلال سابقاً لتوفير سياق ورؤى إضافية. التفاصيل حول هذا الاستغلال متاحة من خلال مقال Zero Day Initiative، تسميم ذاكرة التخزين المؤقت لسياق التفعيل: استغلال CSRSS للارتقاء بالصلاحيات.
يحدث استخدام ذاكرة التخزين المؤقت للتفعيل عندما يكون البرنامج على وشك تحميل مكتبة تتطلب إصداراً محدداً.
على سبيل المثال، إذا كان تطبيق سيحمل C:\Windows\System32\comctl32.dll، فلا يوجد ضمان بأن comctl32.dll في ذلك الموقع هو الإصدار الذي يحتاجه التطبيق. هذا هو استخدام أساسي لذاكرة التخزين المؤقت لسياقات التفعيل (Activation Contexts Cache). يمكن للبرنامج إرسال طلب إلى خادم CSRSS لمعالجة إدخال سياق تفعيل جديد ليتم إدخاله في الذاكرة المؤقتة، بحيث يمكن لهذا البرنامج تحميل إصدار المكتبة المحددة التي يحتاجها.
لهذا الغرض، يتم استخدام ما يسمى بملف البيان (manifest)، وهو بتنسيق XML. عادةً ما يكون مضمنًا كمورد في ملف EXE أو DLL. بدلاً من ذلك، سيبحث ويندوز عن ملف بيان في نفس المجلد الذي يوجد فيه الملف التنفيذي للبرنامج.
يحتوي الرابط المذكور أعلاه على بعض الأمثلة لملفات البيان المستخدمة في الاستغلالات القديمة، مثل خداع النظام لتحميل مكتبة advapi32.dll من مجلد يتحكم به المهاجم تم الوصول إليه من خلال تقنية تجول المسار (PATH TRAVERSAL).
بالطبع، تم تصحيح بعض ناقلات الهجوم المستخدمة، وتم اكتشاف بعض التقنيات الجديدة. بالإضافة إلى ذلك، في تصحيح أكتوبر 2022 لويندوز 11 22H2، تمت إضافة فحص جديد.
بعد تطبيق هذا التصحيح، لا يمكن تجاوز الفحص عند تسجيل سياق التفعيل (ACTX) إلا إذا كانت العملية التي تضيف الإدخال الجديد في الذاكرة المؤقتة لها نفس RID أو أعلى من العملية التي ستستخدمه.
في winnt.h يمكننا رؤية قيم RID:
الاقتراح لتجاوز هذا الفحص هو إنشاء طلب باستخدام سياق تفعيل (Activation Context) من عملية CTFMON حيث يعمل ملف DLL المصمم. هذا الملف DLL المصمم له RID=0x3000 وبعد إضافة الإدخال إلى الذاكرة المؤقتة، سيقوم TCMSETUP الذي له RID=0x3000 بتحميل tapi32.dll.
أثناء محاولتي اتباع الخطوات، قمت بعمل جميع التركيبات الممكنة لتسجيل ACTX باستخدام CreateActCtx. أثبت ذلك أنه مستحيل نظراً لوجود فحص دائم يتجنبه.
من المهم ملاحظة أن هذه الدالة موجودة في مساحة المستخدم، ويتم تصديرها بواسطة kernel32.dll. يمكن تجنب الفحوصات عن طريق تصحيح ملف DLL في الذاكرة، وهو أمر غير أنيق، لكنه ممكن ويجب أن يعمل.
