تحليل ثغرة 0day من مايكروسوفت: قد تهدد أمان بنية Web3 التحتية
في تصحيح الأمان الذي أصدرته مايكروسوفت الشهر الماضي، وُجدت ثغرة تصعيد الامتيازات في win32k تم استغلالها في البرية. يبدو أن هذه الثغرة موجودة فقط في الإصدارات القديمة من النظام، ولا يمكن تفعيلها على Windows 11. لقد كانت استغلال هذه الأنواع من الثغرات موجودة منذ فترة طويلة، وستحلل هذه المقالة كيف يمكن للمهاجمين الاستمرار في استغلال هذه الثغرة في ظل تحسين تدابير التخفيف الحالية. أكملنا عملية التحليل كاملة في بيئة Windows Server 2016.
ثغرات 0day تشير إلى الثغرات التي لم يتم الكشف عنها أو إصلاحها، ويمكن للهاكرز استغلالها بشكل ضار دون أن يتم اكتشافها، وغالبًا ما تكون لها تأثيرات مدمرة كبيرة. الثغرة 0day المكتشفة هذه المرة تقع على مستوى نظام Windows، ويمكن للهاكرز من خلالها الحصول على السيطرة الكاملة على Windows. بعد السيطرة، قد يؤدي ذلك إلى سرقة المعلومات الشخصية، انهيار النظام وفقدان البيانات، خسائر مالية، وزرع برامج ضارة. على نطاق ضيق، قد يؤدي ذلك إلى سرقة المفاتيح الخاصة، ونقل الأصول الرقمية؛ وعلى نطاق واسع، قد يهدد النظام البيئي Web3 بأكمله الذي يعمل على بنية تحتية Web2.
تشير تحليل التصحيحات إلى أن هذه تبدو مجرد مشكلة تم فيها معالجة عدد الإشارات إلى الكائن أكثر من مرة. ولكن عند النظر إلى تعليقات الشيفرة المصدرية السابقة، نجد أن الشيفرة السابقة قيدت فقط كائن النافذة، ولم تقيد كائن القائمة داخل كائن النافذة، مما قد يؤدي إلى الإشارة الخاطئة إلى كائن القائمة.
من تحليل سياق دالة الثغرات، نكتشف أن القائمة المرسلة إلى xxxEnableMenuItem() عادة ما تكون قد تم قفلها في الدالة العليا، فما هو كائن القائمة الذي يجب حمايته هنا؟ من خلال مزيد من التحليل، نجد أن القائمة التي تعاد من xxxEnableMenuItem قد تكون من نوعين: القائمة الرئيسية للنافذة أو القائمة الفرعية للقائمة ( أو حتى القائمة الفرعية للقائمة الفرعية ).
لبناء POC، قمنا بتصميم هيكل قائمة خاص من أربع طبقات، وقمنا بإجراء إعدادات خاصة لكل قائمة للكشف من خلال الدوال. عند عودة xxxRedrawTitle إلى طبقة المستخدم، قمنا بإزالة علاقة الإشارة بين القائمة C والقائمة B، مما أدي إلى تحرير القائمة C بنجاح. وهكذا، عند نقطة عودة دالة xxxEnableMenuItem، يكون كائن القائمة C المشار إليه غير صالح بالفعل.
فيما يتعلق بتنفيذ EXP، نظرنا بشكل أساسي في اتجاهين: تنفيذ كود shellcode واستخدام العمليات الأساسية للقراءة والكتابة لتعديل عنوان الرمز المميز. نظرًا لآلية الأمان في إصدارات Windows الأحدث، اخترنا الخيار الثاني. يمكن تقسيم عملية الاستغلال بأكملها إلى قسمين: كيفية استغلال ثغرة UAF للتحكم في قيمة cbwndextra، وكيفية إنشاء عمليات قراءة وكتابة مستقرة.
نحن من خلال تصميم تخطيط الذاكرة بعناية، نستخدم كائن اسم نافذة من فئة النافذة المحتلة لإطلاق كائنات القائمة، ووجدنا وقت كتابة البيانات في دالة xxxRedrawWindow. لتحقيق تخطيط ذاكرة مستقر، صممنا هيكلًا يتكون من ثلاثة كائنات HWND متتالية، وقمنا بتحديد ترتيب كائنات الترتيب بدقة من خلال عنوان مقبض النواة المتسرب في ذاكرة الكومة.
في قراءة وكتابة الأصلي، نستخدم GetMenuBarInfo() لتحقيق القراءة العشوائية، و SetClassLongPtr() لتحقيق الكتابة العشوائية. باستثناء استبدال عملية كتابة TOKEN التي تعتمد على كائن الفئة للنافذة الثانية، فإن باقي عمليات الكتابة تستخدم كائن الفئة للنافذة الأولى من خلال الإزاحة.
بشكل عام، على الرغم من أن ثغرة win32k لها تاريخ طويل، إلا أن مايكروسوفت حاولت إعادة بناء جزء من كود النواة باستخدام Rust في النسخة التجريبية من Windows 11، وقد يتم القضاء على مثل هذه الثغرات في المستقبل. كانت عملية استغلال هذه الثغرة بسيطة نسبيًا، وكانت الصعوبة الرئيسية تكمن في كيفية التحكم في الكتابة الأولى. قد يعتمد اكتشاف هذه الثغرة على تحسينات في كشف تغطية الكود. بالنسبة لاكتشاف الثغرات، بالإضافة إلى التركيز على النقاط الرئيسية في دوال التشغيل، فإن الكشف عن تخطيط الذاكرة غير الطبيعي وقراءة وكتابة الانحرافات في البيانات يمكن أن يكون أيضًا طريقًا لاكتشاف ثغرات مشابهة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
5
مشاركة
تعليق
0/400
TopBuyerBottomSeller
· 07-21 07:25
سبب آخر لترقية Windows 11 ~
شاهد النسخة الأصليةرد0
FlatTax
· 07-20 03:35
فضيحة لا تلعب بالألعاب القديمة يا مايكروسوفت
شاهد النسخة الأصليةرد0
SurvivorshipBias
· 07-20 03:34
من الذي لا يزال يستخدم win32k في نظامه؟
شاهد النسخة الأصليةرد0
just_another_wallet
· 07-20 03:33
كادت أن تنفجر عملتي القديمة، أشعر بالخدر في فروة رأسي
شاهد النسخة الأصليةرد0
MrRightClick
· 07-20 03:14
النظام الوحيد الذي لا تهتم به حتى الكلاب هو ويندوز 11
تم الكشف عن ثغرة 0day في مايكروسوفت وقد تتعرض أمان بنية Web3 التحتية للتهديد
تحليل ثغرة 0day من مايكروسوفت: قد تهدد أمان بنية Web3 التحتية
في تصحيح الأمان الذي أصدرته مايكروسوفت الشهر الماضي، وُجدت ثغرة تصعيد الامتيازات في win32k تم استغلالها في البرية. يبدو أن هذه الثغرة موجودة فقط في الإصدارات القديمة من النظام، ولا يمكن تفعيلها على Windows 11. لقد كانت استغلال هذه الأنواع من الثغرات موجودة منذ فترة طويلة، وستحلل هذه المقالة كيف يمكن للمهاجمين الاستمرار في استغلال هذه الثغرة في ظل تحسين تدابير التخفيف الحالية. أكملنا عملية التحليل كاملة في بيئة Windows Server 2016.
ثغرات 0day تشير إلى الثغرات التي لم يتم الكشف عنها أو إصلاحها، ويمكن للهاكرز استغلالها بشكل ضار دون أن يتم اكتشافها، وغالبًا ما تكون لها تأثيرات مدمرة كبيرة. الثغرة 0day المكتشفة هذه المرة تقع على مستوى نظام Windows، ويمكن للهاكرز من خلالها الحصول على السيطرة الكاملة على Windows. بعد السيطرة، قد يؤدي ذلك إلى سرقة المعلومات الشخصية، انهيار النظام وفقدان البيانات، خسائر مالية، وزرع برامج ضارة. على نطاق ضيق، قد يؤدي ذلك إلى سرقة المفاتيح الخاصة، ونقل الأصول الرقمية؛ وعلى نطاق واسع، قد يهدد النظام البيئي Web3 بأكمله الذي يعمل على بنية تحتية Web2.
تشير تحليل التصحيحات إلى أن هذه تبدو مجرد مشكلة تم فيها معالجة عدد الإشارات إلى الكائن أكثر من مرة. ولكن عند النظر إلى تعليقات الشيفرة المصدرية السابقة، نجد أن الشيفرة السابقة قيدت فقط كائن النافذة، ولم تقيد كائن القائمة داخل كائن النافذة، مما قد يؤدي إلى الإشارة الخاطئة إلى كائن القائمة.
من تحليل سياق دالة الثغرات، نكتشف أن القائمة المرسلة إلى xxxEnableMenuItem() عادة ما تكون قد تم قفلها في الدالة العليا، فما هو كائن القائمة الذي يجب حمايته هنا؟ من خلال مزيد من التحليل، نجد أن القائمة التي تعاد من xxxEnableMenuItem قد تكون من نوعين: القائمة الرئيسية للنافذة أو القائمة الفرعية للقائمة ( أو حتى القائمة الفرعية للقائمة الفرعية ).
لبناء POC، قمنا بتصميم هيكل قائمة خاص من أربع طبقات، وقمنا بإجراء إعدادات خاصة لكل قائمة للكشف من خلال الدوال. عند عودة xxxRedrawTitle إلى طبقة المستخدم، قمنا بإزالة علاقة الإشارة بين القائمة C والقائمة B، مما أدي إلى تحرير القائمة C بنجاح. وهكذا، عند نقطة عودة دالة xxxEnableMenuItem، يكون كائن القائمة C المشار إليه غير صالح بالفعل.
فيما يتعلق بتنفيذ EXP، نظرنا بشكل أساسي في اتجاهين: تنفيذ كود shellcode واستخدام العمليات الأساسية للقراءة والكتابة لتعديل عنوان الرمز المميز. نظرًا لآلية الأمان في إصدارات Windows الأحدث، اخترنا الخيار الثاني. يمكن تقسيم عملية الاستغلال بأكملها إلى قسمين: كيفية استغلال ثغرة UAF للتحكم في قيمة cbwndextra، وكيفية إنشاء عمليات قراءة وكتابة مستقرة.
نحن من خلال تصميم تخطيط الذاكرة بعناية، نستخدم كائن اسم نافذة من فئة النافذة المحتلة لإطلاق كائنات القائمة، ووجدنا وقت كتابة البيانات في دالة xxxRedrawWindow. لتحقيق تخطيط ذاكرة مستقر، صممنا هيكلًا يتكون من ثلاثة كائنات HWND متتالية، وقمنا بتحديد ترتيب كائنات الترتيب بدقة من خلال عنوان مقبض النواة المتسرب في ذاكرة الكومة.
في قراءة وكتابة الأصلي، نستخدم GetMenuBarInfo() لتحقيق القراءة العشوائية، و SetClassLongPtr() لتحقيق الكتابة العشوائية. باستثناء استبدال عملية كتابة TOKEN التي تعتمد على كائن الفئة للنافذة الثانية، فإن باقي عمليات الكتابة تستخدم كائن الفئة للنافذة الأولى من خلال الإزاحة.
بشكل عام، على الرغم من أن ثغرة win32k لها تاريخ طويل، إلا أن مايكروسوفت حاولت إعادة بناء جزء من كود النواة باستخدام Rust في النسخة التجريبية من Windows 11، وقد يتم القضاء على مثل هذه الثغرات في المستقبل. كانت عملية استغلال هذه الثغرة بسيطة نسبيًا، وكانت الصعوبة الرئيسية تكمن في كيفية التحكم في الكتابة الأولى. قد يعتمد اكتشاف هذه الثغرة على تحسينات في كشف تغطية الكود. بالنسبة لاكتشاف الثغرات، بالإضافة إلى التركيز على النقاط الرئيسية في دوال التشغيل، فإن الكشف عن تخطيط الذاكرة غير الطبيعي وقراءة وكتابة الانحرافات في البيانات يمكن أن يكون أيضًا طريقًا لاكتشاف ثغرات مشابهة.