تحليل الثغرة الأمنية الخطيرة في نظام ويندوز من مايكروسوفت: قد تهدد أمان نظام Web3

في التحديث الأمني الذي أصدرته مايكروسوفت الشهر الماضي، تم إصلاح ثغرة تصعيد الامتياز في Windows كانت تستغلها قراصنة. تؤثر هذه الثغرة بشكل رئيسي على إصدارات Windows القديمة، في حين يبدو أن Windows 11 غير متأثر.

ستحلل هذه المقالة كيف يستمر المهاجمون في استغلال هذه الثغرات في ظل السياق الحالي لتعزيز الأمن. تستند تحليلاتنا إلى Windows Server 2016.

خلفية الثغرات

هذه ثغرة 0day، وهي ثغرة لم يتم الكشف عنها أو إصلاحها بعد. يمكن للقراصنة استغلالها للهجوم دون علم المستخدم، مما يسبب ضررًا كبيرًا.

من خلال هذا الثغرة على مستوى نظام Windows، يمكن للقراصنة الحصول على السيطرة الكاملة على النظام. قد يؤدي ذلك إلى تسرب المعلومات الشخصية، وتعطل النظام، وفقدان البيانات، والخسائر المالية، وغيرها من العواقب الوخيمة. بالنسبة لمستخدمي Web3، قد يتم سرقة المفاتيح الخاصة والأصول الرقمية. من منظور أوسع، قد تؤثر هذه الثغرة حتى على النظام البيئي Web3 بأكمله الذي يعتمد على بنية Web2 التحتية.

تحليل التصحيح

تحليل كود التصحيح، يبدو أن المشكلة تكمن في أن عدد المراجع لكائن ما تمت معالجته بشكل زائد مرة واحدة. من خلال النظر إلى تعليقات المصدر السابقة، نكتشف أن الكود السابق كان يقفل فقط كائن النافذة، ولم يقفل كائن القائمة داخل النافذة، مما قد يؤدي إلى الإشارة الخاطئة لكائن القائمة.

استنساخ الثغرات

من خلال تحليل سياق وظيفة الثغرات، اكتشفنا أن القائمة التي يتم تمرير xxxEnableMenuItem() إليها عادةً ما تكون مؤمنة في الوظائف الأعلى، مما يثير التساؤل حول أي كائن قائمة يجب حمايته.

أظهر التحليل الإضافي أن هناك نوعين محتملين للقائمة التي ترجعها دالة MenuItemState في xxxEnableMenuItem: قائمة القائمة الرئيسية للنوافذ أو قائمة فرعية ( أو حتى قائمة فرعية فرعية ).

لقد أنشأنا هيكل قائمة خاص من أربع طبقات لاستغلال الثغرات، حيث تحتاج هذه القوائم إلى تلبية بعض الشروط المحددة لتجاوز الفحص في الدالة. المفتاح هو أنه عند عودة xxxRedrawTitle إلى طبقة المستخدم، يتم حذف العلاقات المرجعية بين بعض القوائم، مما يؤدي إلى تحرير كائن القائمة المحدد. وبالتالي، عندما تعود دالة xxxEnableMenuItem، يصبح كائن القائمة المرجع غير صالح.

استغلال الثغرات

عند تطوير برنامج استغلال الثغرات (exp)، أخذنا في الاعتبار بشكل رئيسي خيارين:

1. تنفيذ كود shellcode: يشير إلى الثغرات المماثلة السابقة، ولكن قد توجد بعض العقبات في الإصدارات الجديدة من Windows.

2. استخدام العمليات الأساسية للقراءة والكتابة لتعديل عنوان التوكن: لا يزال هناك تجارب عامة متاحة للإشارة إليها مؤخرًا، وتتمتع بتوافق جيد مع تخطيط الذاكرة في سطح المكتب والعمليات الأساسية للقراءة والكتابة.

اخترنا الخيار الثاني، حيث نقسم عملية الاستغلال بالكامل إلى خطوتين: كيفية استغلال ثغرة UAF للتحكم في قيمة cbwndextra، وكيفية تنفيذ عمليات القراءة والكتابة بشكل مستقر.

المفتاح هو العثور على موقع يمكن كتابة البيانات فيه بحرية ضمن هيكل عنوان يمكننا بناؤه. في النهاية اخترنا تنفيذ ذلك من خلال عملية AND على علامة في دالة xxxRedrawWindow.

لتحقيق تخطيط ذاكرة مستقر، قمنا بتصميم ثلاثة كائنات HWND متتالية على الأقل بحجم 0x250 بايت، وإطلاق الكائنات الوسطى، واستخدام كائن HWNDClass. يتم استخدام كائنات HWND الأمامية والخلفية للتحقق من الوظائف وتنفيذ العمليات النهائية للقراءة والكتابة.

نحن أيضًا نقوم بتحديد ما إذا كانت الكائنات مرتبة كما هو متوقع من خلال عنوان مقبض النواة المسرب. في جانب القراءة والكتابة، نستخدم GetMenuBarInfo() لتحقيق القراءة العشوائية، ونستخدم SetClassLongPtr() لتحقيق الكتابة العشوائية.

الاستنتاج

1. مايكروسوفت تحاول إعادة بناء كود win32k باستخدام Rust، وقد يتم القضاء على مثل هذه الثغرات في الأنظمة الجديدة مستقبلاً.

2. عملية استغلال هذا النوع من الثغرات بسيطة نسبيًا، وتعتمد بشكل رئيسي على تسرب عنوان مقبض كومة سطح المكتب. إذا لم يتم حل هذه المشكلة بشكل كامل، ستظل الأنظمة القديمة تواجه مخاطر أمنية.

3. قد يكون اكتشاف هذا الثغرة نتيجة لتقنيات أفضل للكشف عن تغطية الشيفرة.

4. بالنسبة لاكتشاف استغلال الثغرات، بالإضافة إلى مراقبة الدوال الرئيسية، يجب أيضًا الانتباه إلى تخطيط الذاكرة غير الطبيعي وسلوك قراءة وكتابة البيانات.