تحليل واستغلال ثغرات 0day على مستوى النظام من مايكروسوفت
المقدمة
أصلحت تحديثات الأمان الأخيرة من مايكروسوفت ثغرة تصعيد صلاحيات win32k التي كانت تستغلها قراصنة الإنترنت. تؤثر هذه الثغرة بشكل أساسي على إصدارات أنظمة ويندوز القديمة، ويبدو أنها غير فعالة على ويندوز 11. ستتناول هذه المقالة تحليلًا عميقًا لكيفية استمرار المهاجمين في استغلال هذه الثغرات في ظل تحسين تدابير الحماية الجديدة الحالية. بيئة التحليل لدينا هي ويندوز سيرفر 2016.
خلفية الثغرة
ثغرات 0day تشير إلى الثغرات الأمنية التي لم يتم نشرها أو إصلاحها بعد، وهي مشابهة لمفهوم تداول T+0 في الأسواق المالية. بمجرد استغلال هذه الثغرات بشكل خبيث، يمكن أن تسبب أضرارًا كبيرة. الثغرة التي تم اكتشافها مؤخرًا في نظام تشغيل Windows يمكن أن تمنح المهاجمين سيطرة كاملة على النظام.
تكون العواقب شديدة بعد أن يتم السيطرة على النظام من قبل المهاجمين، بما في ذلك تسرب المعلومات الشخصية، انهيار النظام وفقدان البيانات، خسائر مالية، وزرع برامج ضارة. بالنسبة لمستخدمي العملات المشفرة، قد يتم سرقة المفاتيح الخاصة، ونقل الأصول الرقمية. من منظور أوسع، قد تؤثر هذه الثغرة حتى على النظام البيئي Web3 بأكمله القائم على بنية Web2 التحتية.
تحليل التصحيح
تحليل شفرة التصحيح، يبدو أن المشكلة تكمن في أن عدد المراجع لكائن ما قد تمت معالجته عدة مرات. من خلال النظر في تعليقات الشفرة السابقة، وجدنا أن الشفرة السابقة قامت فقط بقفل كائن النافذة، دون قفل كائن القائمة في النافذة، مما قد يؤدي إلى الإشارة الخاطئة إلى كائن القائمة.
تحقق من الثغرات
عند تحليل سياق وظيفة الثغرات، نجد أن القائمة المرسلة إلى xxxEnableMenuItem() عادة ما تكون مقفلة في دالة المستوى الأعلى، فما هو كائن القائمة المحدد الذي يجب حمايته؟ من خلال التحليل الإضافي لمعالجة كائن القائمة في xxxEnableMenuItem، نجد أن الدالة MenuItemState تعيد قائمتين محتملتين: القائمة الرئيسية لنافذة أو قائمة فرعية( تشمل القوائم الفرعية).
للتحقق من الثغرة، قمنا بإنشاء هيكل قائمة خاص من أربع طبقات، وقمنا بتعيين بعض الشروط المحددة لتجاوز الكشف في دالة xxxEnableMenuItem. عند عودة xxxRedrawTitle إلى طبقة المستخدم، قمنا بإزالة علاقة الإشارة بين القائمتين C و B، مما أدى إلى تحرير القائمة C بنجاح. أخيراً، عندما تعود دالة xxxEnableMenuItem في النواة إلى دالة xxxRedrawTitle، تكون كائن القائمة C المشار إليه قد أصبح غير صالح.
استغلال الثغرات
الفكرة العامة
قبل تحديد خطة الاستغلال، عادة ما نقوم ببعض التحليلات النظرية لتجنب إضاعة الوقت في خطط غير قابلة للتطبيق. تتناول هذه الاستغلالات ثغرات بشكل أساسي اتجاهين:
تنفيذ shellcode: الإشارة إلى ثغرات مماثلة سابقة، ولكن قد تواجه بعض المشكلات الصعبة الحل في إصدارات Windows العالية.
استخدام العمليات الأصلية لقراءة وكتابة لتعديل الرمز المميز: حتى في العامين الماضيين، لا تزال هناك حالات مرجعية عامة. نحتاج إلى التركيز على كيفية التحكم في cbwndextra كقيمة كبيرة لأول مرة عند إعادة استخدام ذاكرة UAF.
لذلك ، نقسم عملية الاستغلال بأكملها إلى جزئين: كيفية استغلال ثغرة UAF للتحكم في قيمة cbwndextra ، وكيفية تحقيق عمليات القراءة والكتابة المستقرة بعد التحكم في هذه القيمة.
 كتابة البيانات للمرة الأولى
بعد استغلال الثغرة، قد لا ينهار النظام على الفور. يحدث الاستخدام غير الصحيح لبيانات كائنات النوافذ في الذاكرة المتحكم بها بشكل رئيسي في دالة xxxEnableMenuItem MNGetPopupFromMenu###( و xxxMNUpdateShownMenu)(.
نستخدم كائن اسم النافذة في فئة WNDClass لاستغلال ذاكرة كائن القائمة المحررة. المفتاح هو العثور على موقع يمكننا كتابة البيانات فيه بشكل عشوائي في هيكل العنوان الذي نبنيه، حتى لو كان بايتًا واحدًا فقط.
في النهاية، وجدنا حلين قابلين للتطبيق في دالة xxxRedrawWindow. نظرًا لبعض عوامل القيود، اخترنا الحل الذي يعتمد على عملية علامة AND 2، وقررنا الكتابة في cb-extra لـ HWNDClass بدلاً من cb-extra لكائن النافذة.
![Numen حصرية: ثغرة 0day من مايكروسوفت يمكن أن تكشف نظام + المستوى الفيزيائي عن لعبة Web3])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) تخطيط الذاكرة الثابتة
لقد صممنا تخطيط ذاكرة يحتوي على ثلاثة كائنات HWND بحجم 0x250 بايت على الأقل بشكل مت连续. تحرير الكائنات المتوسطة، واستخدام كائن HWNDClass بحجم 0x250 بايت. تُستخدم بيانات نهاية الكائن HWND السابق للتحقق من خلال علامة xxxRedrawWindow، بينما تُستخدم كائنات القائمة الخاصة بكائن HWND وكائن HWNDClass كوسيط لعمليات القراءة والكتابة النهائية.
نحن نحاول التحكم في توافق حجم كائن نافذة وحجم كائن HWNDClass، ونتأكد من أن بيانات كائن النافذة الموسعة كبيرة بما يكفي. من خلال عنوان مقبض النواة المتسرب في ذاكرة الكومة، يمكننا تحديد بدقة ما إذا كان كائن النافذة المطلوب مرتبا كما هو متوقع.
![Numen حصرية: ثغرة 0day من مايكروسوفت يمكن أن تكشف عن نظام + المستوى الفيزيائي لمشهد Web3]###https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
) تنفيذ القراءة والكتابة للغة الأصلية
تستخدم أي قراءة للغة الأصلية GetMenuBarInfo###(. بينما تستخدم أي كتابة للغة الأصلية SetClassLongPtr)(. باستثناء عمليات الكتابة التي تعتمد على كائن الفئة النافذة الثانية لاستبدال TOKEN، فإن جميع عمليات الكتابة الأخرى تستخدم كائن الفئة للنافذة الأولى باستخدام الإزاحة لتحقيق ذلك.
![Numen حصرية: ثغرة 0day من مايكروسوفت يمكن أن تكشف عن نظام + المستوى الفيزيائي في لعبة Web3])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
ملخص
ثغرة win32k موجودة منذ فترة طويلة، لكن مايكروسوفت تعمل على إعادة بناء كود النواة المتعلق بها باستخدام Rust، ومن الممكن أن تمنع الأنظمة الجديدة مثل هذه الثغرات في المستقبل.
إن عملية استغلال الثغرة هذه ليست صعبة للغاية، والصعوبة الرئيسية تكمن في كيفية التحكم في الكتابة الأولى. لا تزال الثغرة تعتمد بشكل كبير على تسرب عنوان مقبض كومة سطح المكتب، وهذا يمثل خطرًا أمنيًا على الأنظمة القديمة.
قد يكون اكتشاف الثغرة نتيجة لتحسينات في الكشف عن تغطية الكود. بمجرد أن تتمكن واجهة برمجة التطبيقات (API) للنظام من الوصول إلى أعمق نقطة ثغرة في مسار تنفيذ الدالة المستهدفة، وأن يكون كائن النافذة في حالة استدعاء متداخلة متعددة، قد تتمكن اختبارات الفحص (fuzz testing) من اكتشاف هذه الثغرة.
في ما يتعلق باكتشاف استغلال الثغرات، بالإضافة إلى التركيز على النقاط الرئيسية لوظائف تفعيل الثغرات، ينبغي أيضًا التركيز على تخطيط الذاكرة غير الطبيعي وقراءة وكتابة الإزاحة غير التقليدية للبيانات الإضافية للنوافذ أو فئات النوافذ، مما قد يساعد في اكتشاف ثغرات من نفس النوع.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 23
أعجبني
23
3
مشاركة
تعليق
0/400
OnChainDetective
· 08-01 09:21
أه، وين 32k الكلاسيكية... النمط يتطابق مع استغلالات APT السابقة بصراحة
تحليل عميق واستغلال تقنيات ثغرات 0day على مستوى نظام Windows
تحليل واستغلال ثغرات 0day على مستوى النظام من مايكروسوفت
المقدمة
أصلحت تحديثات الأمان الأخيرة من مايكروسوفت ثغرة تصعيد صلاحيات win32k التي كانت تستغلها قراصنة الإنترنت. تؤثر هذه الثغرة بشكل أساسي على إصدارات أنظمة ويندوز القديمة، ويبدو أنها غير فعالة على ويندوز 11. ستتناول هذه المقالة تحليلًا عميقًا لكيفية استمرار المهاجمين في استغلال هذه الثغرات في ظل تحسين تدابير الحماية الجديدة الحالية. بيئة التحليل لدينا هي ويندوز سيرفر 2016.
خلفية الثغرة
ثغرات 0day تشير إلى الثغرات الأمنية التي لم يتم نشرها أو إصلاحها بعد، وهي مشابهة لمفهوم تداول T+0 في الأسواق المالية. بمجرد استغلال هذه الثغرات بشكل خبيث، يمكن أن تسبب أضرارًا كبيرة. الثغرة التي تم اكتشافها مؤخرًا في نظام تشغيل Windows يمكن أن تمنح المهاجمين سيطرة كاملة على النظام.
تكون العواقب شديدة بعد أن يتم السيطرة على النظام من قبل المهاجمين، بما في ذلك تسرب المعلومات الشخصية، انهيار النظام وفقدان البيانات، خسائر مالية، وزرع برامج ضارة. بالنسبة لمستخدمي العملات المشفرة، قد يتم سرقة المفاتيح الخاصة، ونقل الأصول الرقمية. من منظور أوسع، قد تؤثر هذه الثغرة حتى على النظام البيئي Web3 بأكمله القائم على بنية Web2 التحتية.
تحليل التصحيح
تحليل شفرة التصحيح، يبدو أن المشكلة تكمن في أن عدد المراجع لكائن ما قد تمت معالجته عدة مرات. من خلال النظر في تعليقات الشفرة السابقة، وجدنا أن الشفرة السابقة قامت فقط بقفل كائن النافذة، دون قفل كائن القائمة في النافذة، مما قد يؤدي إلى الإشارة الخاطئة إلى كائن القائمة.
تحقق من الثغرات
عند تحليل سياق وظيفة الثغرات، نجد أن القائمة المرسلة إلى xxxEnableMenuItem() عادة ما تكون مقفلة في دالة المستوى الأعلى، فما هو كائن القائمة المحدد الذي يجب حمايته؟ من خلال التحليل الإضافي لمعالجة كائن القائمة في xxxEnableMenuItem، نجد أن الدالة MenuItemState تعيد قائمتين محتملتين: القائمة الرئيسية لنافذة أو قائمة فرعية( تشمل القوائم الفرعية).
للتحقق من الثغرة، قمنا بإنشاء هيكل قائمة خاص من أربع طبقات، وقمنا بتعيين بعض الشروط المحددة لتجاوز الكشف في دالة xxxEnableMenuItem. عند عودة xxxRedrawTitle إلى طبقة المستخدم، قمنا بإزالة علاقة الإشارة بين القائمتين C و B، مما أدى إلى تحرير القائمة C بنجاح. أخيراً، عندما تعود دالة xxxEnableMenuItem في النواة إلى دالة xxxRedrawTitle، تكون كائن القائمة C المشار إليه قد أصبح غير صالح.
استغلال الثغرات
الفكرة العامة
قبل تحديد خطة الاستغلال، عادة ما نقوم ببعض التحليلات النظرية لتجنب إضاعة الوقت في خطط غير قابلة للتطبيق. تتناول هذه الاستغلالات ثغرات بشكل أساسي اتجاهين:
تنفيذ shellcode: الإشارة إلى ثغرات مماثلة سابقة، ولكن قد تواجه بعض المشكلات الصعبة الحل في إصدارات Windows العالية.
استخدام العمليات الأصلية لقراءة وكتابة لتعديل الرمز المميز: حتى في العامين الماضيين، لا تزال هناك حالات مرجعية عامة. نحتاج إلى التركيز على كيفية التحكم في cbwndextra كقيمة كبيرة لأول مرة عند إعادة استخدام ذاكرة UAF.
لذلك ، نقسم عملية الاستغلال بأكملها إلى جزئين: كيفية استغلال ثغرة UAF للتحكم في قيمة cbwndextra ، وكيفية تحقيق عمليات القراءة والكتابة المستقرة بعد التحكم في هذه القيمة.
 كتابة البيانات للمرة الأولى
بعد استغلال الثغرة، قد لا ينهار النظام على الفور. يحدث الاستخدام غير الصحيح لبيانات كائنات النوافذ في الذاكرة المتحكم بها بشكل رئيسي في دالة xxxEnableMenuItem MNGetPopupFromMenu###( و xxxMNUpdateShownMenu)(.
نستخدم كائن اسم النافذة في فئة WNDClass لاستغلال ذاكرة كائن القائمة المحررة. المفتاح هو العثور على موقع يمكننا كتابة البيانات فيه بشكل عشوائي في هيكل العنوان الذي نبنيه، حتى لو كان بايتًا واحدًا فقط.
في النهاية، وجدنا حلين قابلين للتطبيق في دالة xxxRedrawWindow. نظرًا لبعض عوامل القيود، اخترنا الحل الذي يعتمد على عملية علامة AND 2، وقررنا الكتابة في cb-extra لـ HWNDClass بدلاً من cb-extra لكائن النافذة.
![Numen حصرية: ثغرة 0day من مايكروسوفت يمكن أن تكشف نظام + المستوى الفيزيائي عن لعبة Web3])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) تخطيط الذاكرة الثابتة
لقد صممنا تخطيط ذاكرة يحتوي على ثلاثة كائنات HWND بحجم 0x250 بايت على الأقل بشكل مت连续. تحرير الكائنات المتوسطة، واستخدام كائن HWNDClass بحجم 0x250 بايت. تُستخدم بيانات نهاية الكائن HWND السابق للتحقق من خلال علامة xxxRedrawWindow، بينما تُستخدم كائنات القائمة الخاصة بكائن HWND وكائن HWNDClass كوسيط لعمليات القراءة والكتابة النهائية.
نحن نحاول التحكم في توافق حجم كائن نافذة وحجم كائن HWNDClass، ونتأكد من أن بيانات كائن النافذة الموسعة كبيرة بما يكفي. من خلال عنوان مقبض النواة المتسرب في ذاكرة الكومة، يمكننا تحديد بدقة ما إذا كان كائن النافذة المطلوب مرتبا كما هو متوقع.
![Numen حصرية: ثغرة 0day من مايكروسوفت يمكن أن تكشف عن نظام + المستوى الفيزيائي لمشهد Web3]###https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
) تنفيذ القراءة والكتابة للغة الأصلية
تستخدم أي قراءة للغة الأصلية GetMenuBarInfo###(. بينما تستخدم أي كتابة للغة الأصلية SetClassLongPtr)(. باستثناء عمليات الكتابة التي تعتمد على كائن الفئة النافذة الثانية لاستبدال TOKEN، فإن جميع عمليات الكتابة الأخرى تستخدم كائن الفئة للنافذة الأولى باستخدام الإزاحة لتحقيق ذلك.
![Numen حصرية: ثغرة 0day من مايكروسوفت يمكن أن تكشف عن نظام + المستوى الفيزيائي في لعبة Web3])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
ملخص
ثغرة win32k موجودة منذ فترة طويلة، لكن مايكروسوفت تعمل على إعادة بناء كود النواة المتعلق بها باستخدام Rust، ومن الممكن أن تمنع الأنظمة الجديدة مثل هذه الثغرات في المستقبل.
إن عملية استغلال الثغرة هذه ليست صعبة للغاية، والصعوبة الرئيسية تكمن في كيفية التحكم في الكتابة الأولى. لا تزال الثغرة تعتمد بشكل كبير على تسرب عنوان مقبض كومة سطح المكتب، وهذا يمثل خطرًا أمنيًا على الأنظمة القديمة.
قد يكون اكتشاف الثغرة نتيجة لتحسينات في الكشف عن تغطية الكود. بمجرد أن تتمكن واجهة برمجة التطبيقات (API) للنظام من الوصول إلى أعمق نقطة ثغرة في مسار تنفيذ الدالة المستهدفة، وأن يكون كائن النافذة في حالة استدعاء متداخلة متعددة، قد تتمكن اختبارات الفحص (fuzz testing) من اكتشاف هذه الثغرة.
في ما يتعلق باكتشاف استغلال الثغرات، بالإضافة إلى التركيز على النقاط الرئيسية لوظائف تفعيل الثغرات، ينبغي أيضًا التركيز على تخطيط الذاكرة غير الطبيعي وقراءة وكتابة الإزاحة غير التقليدية للبيانات الإضافية للنوافذ أو فئات النوافذ، مما قد يساعد في اكتشاف ثغرات من نفس النوع.