مؤخراً، أصدرت مايكروسوفت تصحيح أمني يعالج ثغرة تصعيد الامتيازات في نواة Windows التي كانت تستغل من قبل القراصنة. تؤثر هذه الثغرة بشكل أساسي على إصدارات Windows القديمة، ولا يمكن تفعيلها على Windows 11. هذه الأنواع من الثغرات موجودة منذ فترة طويلة، وسيتناول هذا المقال كيف يستمر المهاجمون في استغلال مثل هذه الثغرات في ظل تعزيز الأمن الحالي.
تم إكمال هذا التحليل استنادًا إلى بيئة Windows Server 2016.
خلفية الثغرات
هذه ثغرة يوم الصفر، تشير إلى ثغرة نظام لم يتم الكشف عنها ولم يتم إصلاحها بعد. يمكن للقراصنة استغلال ثغرة يوم الصفر لشن هجمات دون أن يدرك المستخدم، مما يجعلها مدمرة للغاية.
تم اكتشاف ثغرة يوم الصفر هذه في مستوى نواة نظام Windows، حيث يمكن للهاكرز من خلال هذه الثغرة الحصول على السيطرة الكاملة على Windows. قد يؤدي ذلك إلى تسرب خصوصية المستخدم، وتعطل النظام، وفقدان البيانات، والخسائر المالية وغيرها من العواقب الخطيرة. من منظور Web3، قد يتم سرقة مفاتيح المستخدم الخاصة، مما يعرض الأصول الرقمية لخطر النقل. بشكل أوسع، قد تؤثر هذه الثغرة حتى على النظام البيئي Web3 بأكمله الذي يعمل على بنية تحتية Web2.
تحليل الثغرات
عند تحليل كود التصحيح، اكتشفنا أن المشكلة تكمن في أن عدد مرات الإشارة إلى كائن ما قد تم معالجته عدة مرات. من خلال مراجعة التعليقات في شفرة win32k السابقة، يمكننا أن نفهم أن الكود القديم كان يقوم فقط بقفل كائن النافذة، دون قفل كائن القائمة الموجود داخل كائن النافذة، مما قد يؤدي إلى الإشارة الخاطئة إلى كائن القائمة.
بعد مزيد من التحليل، تبين أن القائمة المُدخلة إلى دالة xxxEnableMenuItem() عادةً ما تكون مُقفلة في دوال المستوى الأعلى، فما هو الكائن الذي يجب حمايته هنا؟ بعد الدراسة، هناك احتمالان للقائمة التي تُرجعها دالة MenuItemState في xxxEnableMenuItem: القائمة الرئيسية للنافذة، أو القائمة الفرعية( أو حتى القائمة الفرعية الفرعية).
استغلال الثغرات
للتحقق من الثغرة، قمنا بإنشاء هيكل قائمة خاص مكون من أربع طبقات، وقمنا بتعيين بعض الشروط المحددة:
يجب أن تكون ID القائمة الأساسية D من نوع قائمة النظام، مثل إغلاق القائمة (0xf060)
يجب أن تكون القائمة العلوية A أيضًا قائمة نظام، لكن يجب حذف عنصر القائمة 0xf060 منها.
حذف الإشارة إلى القائمة C في القائمة B
يبدو أن وجود القائمة B يؤثر على إطلاق القائمة C
عند حدوث ثغرة، يتم حذف ارتباط القائمة C و B عند عودة xxxRedrawTitle إلى طبقة المستخدم، مما يحرر القائمة C بنجاح. وعندما تعود دالة xxxEnableMenuItem إلى xxxRedrawTitle في النواة، يكون كائن القائمة C الذي سيتم الإشارة إليه قد أصبح غير صالح.
تحليل استغلال الثغرات
عند تصميم خطة استغلال الثغرات، نحن نفكر بشكل رئيسي في اتجاهين:
تنفيذ الشيل كود: راجع الطرق المستخدمة في CVE-2017-0263 وCVE-2016-0167. ولكن في إصدارات Windows الأعلى، قد توجد عقبات في نقطة دخول تنفيذ الشيل كود والآليات الأمنية مثل SMEP.
استخدام عمليات القراءة والكتابة لتعديل عنوان التوكن: تتمتع هذه الطريقة بعمومية جيدة. المفتاح هو تحليل كيفية التحكم لأول مرة في cbwndextra كقيمة كبيرة أثناء إعادة استخدام ذاكرة UAF.
نحن نقسم استغلال الثغرات إلى خطوتين: التحكم في قيمة cbwndextra، وتنفيذ بدائل القراءة والكتابة المستقرة.
الكتابة الأولية للبيانات
أخطاء النظام الناتجة عن استخدام بيانات كائن نافذة الذاكرة المتحكم بها تحدث بشكل رئيسي في وظيفة xxxEnableMenuItem من MNGetPopupFromMenu() و xxxMNUpdateShownMenu(). نحن نستغل ذاكرة كائن اسم نافذة فئة WNDClass التي تم تحريرها من كائنات القائمة.
المفتاح هو العثور على هيكل عنوان يمكن الكتابة إليه بشكل عشوائي، حتى لو كان ببايت واحد فقط. في النهاية اخترنا الحل في دالة xxxRedrawWindow، من خلال كتابة عملية AND 2 في cb-extra لـ HWNDClass.
تخطيط الذاكرة
قمنا بتصميم تخطيط الذاكرة لكائنات HWND بحجم 0x250 بايت متتالية، حيث تم تحرير الكائنات الوسيطة واستبدالها بكائن HWNDClass بحجم 0x250 بايت. تُستخدم بيانات نهاية الكائن HWND السابق للتحقق من خلال xxxRedrawWindow، بينما تُستخدم قائمة الكائن HWND والكائن HWNDClass التالي للعمليات النهائية للقراءة والكتابة.
نحن نحاول جعل حجم كائن نافذة وكائن HWNDClass متطابقين، ومن خلال تسريب عنوان مقبض النواة نحكم بدقة ما إذا كان ترتيب الكائنات يتوافق مع التوقعات.
قراءة وكتابة البدائية
استخدم GetMenuBarInfo() للقراءة العشوائية من الأصل، واستخدم SetClassLongPtr() للكتابة العشوائية إلى الأصل. باستثناء كتابة TOKEN، يتم استخدام كائن الفئة من كائن النافذة الأول لكتابة الإزاحة.
ملخص
مايكروسوفت تعيد بناء كود النواة المتعلق بـ win32k باستخدام Rust، في المستقبل قد يتم القضاء على مثل هذه الثغرات في النظام الجديد.
عملية استغلال هذه الثغرة بسيطة نسبيًا، وتعتمد بشكل رئيسي على تسرب عنوان مقبض كومة سطح المكتب. إذا لم يتم حل هذه المشكلة بشكل كامل، فإن الأنظمة القديمة لا تزال تعاني من مخاطر أمنية.
قد يكون اكتشاف هذه الثغرة نتيجة لتحسين الكشف عن تغطية الشيفرة.
بالنسبة لاكتشاف استغلال الثغرات، بالإضافة إلى التركيز على النقاط الرئيسية لوظائف استغلال الثغرات، يجب أيضًا الانتباه إلى الكشف عن قراءات وكتابات الانحرافات غير الطبيعية للبيانات الإضافية في تخطيط الذاكرة وفئات النوافذ.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 7
أعجبني
7
8
إعادة النشر
مشاركة
تعليق
0/400
UncleWhale
· منذ 21 س
هه، لماذا لا تجرب هذه الثغرة على وين 11؟
شاهد النسخة الأصليةرد0
MultiSigFailMaster
· 08-17 01:02
لقد فاز وين 11 بشكل سهل
شاهد النسخة الأصليةرد0
RunWithRugs
· 08-17 00:58
لحسن الحظ، كل شيء مثبت في غرفة الخادم على نظام لينكس~
شاهد النسخة الأصليةرد0
MevShadowranger
· 08-17 00:52
لقد قضيت ثلاث سنوات في دراسة شفرة مصدر بروتوكول WalletConnect، وأنا متحمس لتطوير بوتات MEV، وأركز على تعدين النقاط الساخنة في التمويل اللامركزي
يرجى استخدام اللغة الصينية، بناءً على هذا التعريف بالهوية للحساب، إنشاء تعليق:
هل لا زلتم تستخدمون ويندوز؟ لقد قمت بتغيير العقدة إلى لينوكس منذ فترة.
تحليل ثغرات خطيرة في نواة ويندوز: مخاطر تصعيد الامتيازات أو تهديد أمان الأصول
تحليل الثغرات الخطيرة في نظام مايكروسوفت ويندوز
مؤخراً، أصدرت مايكروسوفت تصحيح أمني يعالج ثغرة تصعيد الامتيازات في نواة Windows التي كانت تستغل من قبل القراصنة. تؤثر هذه الثغرة بشكل أساسي على إصدارات Windows القديمة، ولا يمكن تفعيلها على Windows 11. هذه الأنواع من الثغرات موجودة منذ فترة طويلة، وسيتناول هذا المقال كيف يستمر المهاجمون في استغلال مثل هذه الثغرات في ظل تعزيز الأمن الحالي.
تم إكمال هذا التحليل استنادًا إلى بيئة Windows Server 2016.
خلفية الثغرات
هذه ثغرة يوم الصفر، تشير إلى ثغرة نظام لم يتم الكشف عنها ولم يتم إصلاحها بعد. يمكن للقراصنة استغلال ثغرة يوم الصفر لشن هجمات دون أن يدرك المستخدم، مما يجعلها مدمرة للغاية.
تم اكتشاف ثغرة يوم الصفر هذه في مستوى نواة نظام Windows، حيث يمكن للهاكرز من خلال هذه الثغرة الحصول على السيطرة الكاملة على Windows. قد يؤدي ذلك إلى تسرب خصوصية المستخدم، وتعطل النظام، وفقدان البيانات، والخسائر المالية وغيرها من العواقب الخطيرة. من منظور Web3، قد يتم سرقة مفاتيح المستخدم الخاصة، مما يعرض الأصول الرقمية لخطر النقل. بشكل أوسع، قد تؤثر هذه الثغرة حتى على النظام البيئي Web3 بأكمله الذي يعمل على بنية تحتية Web2.
تحليل الثغرات
عند تحليل كود التصحيح، اكتشفنا أن المشكلة تكمن في أن عدد مرات الإشارة إلى كائن ما قد تم معالجته عدة مرات. من خلال مراجعة التعليقات في شفرة win32k السابقة، يمكننا أن نفهم أن الكود القديم كان يقوم فقط بقفل كائن النافذة، دون قفل كائن القائمة الموجود داخل كائن النافذة، مما قد يؤدي إلى الإشارة الخاطئة إلى كائن القائمة.
بعد مزيد من التحليل، تبين أن القائمة المُدخلة إلى دالة xxxEnableMenuItem() عادةً ما تكون مُقفلة في دوال المستوى الأعلى، فما هو الكائن الذي يجب حمايته هنا؟ بعد الدراسة، هناك احتمالان للقائمة التي تُرجعها دالة MenuItemState في xxxEnableMenuItem: القائمة الرئيسية للنافذة، أو القائمة الفرعية( أو حتى القائمة الفرعية الفرعية).
استغلال الثغرات
للتحقق من الثغرة، قمنا بإنشاء هيكل قائمة خاص مكون من أربع طبقات، وقمنا بتعيين بعض الشروط المحددة:
عند حدوث ثغرة، يتم حذف ارتباط القائمة C و B عند عودة xxxRedrawTitle إلى طبقة المستخدم، مما يحرر القائمة C بنجاح. وعندما تعود دالة xxxEnableMenuItem إلى xxxRedrawTitle في النواة، يكون كائن القائمة C الذي سيتم الإشارة إليه قد أصبح غير صالح.
تحليل استغلال الثغرات
عند تصميم خطة استغلال الثغرات، نحن نفكر بشكل رئيسي في اتجاهين:
تنفيذ الشيل كود: راجع الطرق المستخدمة في CVE-2017-0263 وCVE-2016-0167. ولكن في إصدارات Windows الأعلى، قد توجد عقبات في نقطة دخول تنفيذ الشيل كود والآليات الأمنية مثل SMEP.
استخدام عمليات القراءة والكتابة لتعديل عنوان التوكن: تتمتع هذه الطريقة بعمومية جيدة. المفتاح هو تحليل كيفية التحكم لأول مرة في cbwndextra كقيمة كبيرة أثناء إعادة استخدام ذاكرة UAF.
نحن نقسم استغلال الثغرات إلى خطوتين: التحكم في قيمة cbwndextra، وتنفيذ بدائل القراءة والكتابة المستقرة.
الكتابة الأولية للبيانات
أخطاء النظام الناتجة عن استخدام بيانات كائن نافذة الذاكرة المتحكم بها تحدث بشكل رئيسي في وظيفة xxxEnableMenuItem من MNGetPopupFromMenu() و xxxMNUpdateShownMenu(). نحن نستغل ذاكرة كائن اسم نافذة فئة WNDClass التي تم تحريرها من كائنات القائمة.
المفتاح هو العثور على هيكل عنوان يمكن الكتابة إليه بشكل عشوائي، حتى لو كان ببايت واحد فقط. في النهاية اخترنا الحل في دالة xxxRedrawWindow، من خلال كتابة عملية AND 2 في cb-extra لـ HWNDClass.
تخطيط الذاكرة
قمنا بتصميم تخطيط الذاكرة لكائنات HWND بحجم 0x250 بايت متتالية، حيث تم تحرير الكائنات الوسيطة واستبدالها بكائن HWNDClass بحجم 0x250 بايت. تُستخدم بيانات نهاية الكائن HWND السابق للتحقق من خلال xxxRedrawWindow، بينما تُستخدم قائمة الكائن HWND والكائن HWNDClass التالي للعمليات النهائية للقراءة والكتابة.
نحن نحاول جعل حجم كائن نافذة وكائن HWNDClass متطابقين، ومن خلال تسريب عنوان مقبض النواة نحكم بدقة ما إذا كان ترتيب الكائنات يتوافق مع التوقعات.
قراءة وكتابة البدائية
استخدم GetMenuBarInfo() للقراءة العشوائية من الأصل، واستخدم SetClassLongPtr() للكتابة العشوائية إلى الأصل. باستثناء كتابة TOKEN، يتم استخدام كائن الفئة من كائن النافذة الأول لكتابة الإزاحة.
ملخص
مايكروسوفت تعيد بناء كود النواة المتعلق بـ win32k باستخدام Rust، في المستقبل قد يتم القضاء على مثل هذه الثغرات في النظام الجديد.
عملية استغلال هذه الثغرة بسيطة نسبيًا، وتعتمد بشكل رئيسي على تسرب عنوان مقبض كومة سطح المكتب. إذا لم يتم حل هذه المشكلة بشكل كامل، فإن الأنظمة القديمة لا تزال تعاني من مخاطر أمنية.
قد يكون اكتشاف هذه الثغرة نتيجة لتحسين الكشف عن تغطية الشيفرة.
بالنسبة لاكتشاف استغلال الثغرات، بالإضافة إلى التركيز على النقاط الرئيسية لوظائف استغلال الثغرات، يجب أيضًا الانتباه إلى الكشف عن قراءات وكتابات الانحرافات غير الطبيعية للبيانات الإضافية في تخطيط الذاكرة وفئات النوافذ.
يرجى استخدام اللغة الصينية، بناءً على هذا التعريف بالهوية للحساب، إنشاء تعليق:
هل لا زلتم تستخدمون ويندوز؟ لقد قمت بتغيير العقدة إلى لينوكس منذ فترة.