استغلال ثغرة CVE-2015-0057 على أنظمة 32 بت و64 بت

المؤلف: Aaron Adams

الترجمة: 55-AA

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

المصطلحات:

• البدائية (primitive): تشبه دالة وظيفية، وهي مجموعة من عمليات الإفساد التي تكمل وظيفة قابلة لإعادة الاستخدام بشكل كامل، مثل قراءة الذاكرة، كتابة بيانات عشوائية، إلخ.

مقدمة تمهيدية

في وقت سابق من هذا العام، صادفت ثغرة مثيرة للاهتمام في win32k.sys (CVE-2015-0057)، وتمكنت من تحقيق استغلال مستقر على أنظمة 32 بت و64 بت، والتي تغطي النطاق من XP إلى Windows 8.1 (مع بعض الاستثناءات). تصف هذه المقالة بالتفصيل كيف قمت بالاستغلال على هاتين المنصتين، وتتضمن أيضًا بعض الأمور الإضافية في النهاية. كما تصف كيفية تحقيق الاستغلال تحت صلاحيات منخفضة النزاهة على Windows 8.1 مع تمكين SMEP.

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

مقدمة

في 10 فبراير 2015، أصدرت Microsoft تفاصيل حول MS15-010. تم اكتشاف هذا الخلل لأول مرة بواسطة Udi Yavo من enSilo. قدم Udi تحليلًا ممتازًا على مدونة breaking malware بعنوان "one bit rule-bypassing windows 10 protections using single bit". أوصي بقراءة هذه المقالة بعناية لفهم الخلل بشكل أعمق، على الرغم من أنني سأقدم أكبر قدر ممكن من التفاصيل في هذه المقالة، والتي تغطي بعض العقبات التي يجب التغلب عليها عند تشغيل الثغرة. استغلال هذه الثغرة مثير للاهتمام للغاية، والعديد من التفاصيل مستمدة من مدونة Udi، وإليك تصريحه:

إفشاء معقول: على الرغم من أن هذه المدونة تقنية، إلا أننا لن نكشف عن أي رمز أو تفاصيل كاملة، لمنع أي خبير تقني من إعادة إنتاج استغلال الثغرة.

كمكافأة إضافية لاستغلال هذه الثغرة، حصلنا على تطور البوكيمون: تكنيكيمون. أعتقد أنني يجب أن أعطي Udi بعض التقدير لاكتشافه هذه الثغرة وتقديم المعلومات ذات الصلة والتفاصيل حول استغلالها في مدونته، فقد كانت هذه الأشياء مفيدة للغاية.

في السابق، لم أستغل أي ثغرة في win32k.sys من قبل، ولم أكن على دراية بالاستدعاءات الخلفية لوضع المستخدم والعديد من واجهات برمجة التطبيقات ذات الصلة. لذلك، أشكر أيضًا بعض الباحثين الأمنيين المشهورين الذين قدموا موارد جديدة على الإنترنت، مثل Skywing وTarjei Mandt وAlex Ionescu وj00ru وغيرهم. هؤلاء الأشخاص يقدمون الكثير من المعلومات التقنية بشكل علني، ويستحقون الثناء جميعًا. ما رجعت إليه بكثرة هو مقالة Tarjei Mandt Win32k.sys exploitation paper.

عندما كنت أكتب هذا الاستغلال، قام مهندس عكسي ممتاز بتنفيذ استغلال ثابت لـ CVE-2015-1701، وكانت أمثلة التعليمات البرمجية الخاصة بالاستدعاءات الخلفية لوضع المستخدم مفيدة للغاية، وأشكر هذا المؤلف.

من الجدير بالذكر أن تحليلي أدناه تم على Windows 7، لأنه يبدو الإصدار الوحيد الذي تحتوي فيه جميع الهياكل في win32k.sys على رموز مقابلة. معظم هذه الرموز قابلة للاستخدام في هياكل إصدارات أخرى من Win32k.sys. لسبب غير معروف، أزالت Microsoft هذه الرموز من Windows 8.

أخيرًا، أود أن أقول إن طريقتي في الاستغلال معقدة للغاية. من الممكن تمامًا وجود طريقة أسهل لتحقيق ذلك، لكنني لم أجدها. أود أن أسمع عن استخدام طرق مختلفة من قبل الآخرين. على أي حال، آمل أن يكون كل هذا مفيدًا لدراسة ثغرات win32k.sys.

الخلل

دعونا نلقي نظرة على الخلل في التفكيك الخاص بـ win32k!xxxEnableWndSBArrows، إنه خلل دقيق للغاية:

الحالة غير المصححة:

.text:FFFFF97FFF1B157D mov r8d, r13d 
.text:FFFFF97FFF1B1580 mov rdx, r14 
.text:FFFFF97FFF1B1583 call xxxDrawScrollBar    ; تشغيل استدعاء خلفي لوضع المستخدم 
.text:FFFFF97FFF1B1588 jmp short loc_FFFFF97FFF1B1519
 [...] 
.text:FFFFF97FFF1B1519 mov eax, [rbx]           ; الرجوع إلى مؤشر tagSBINFO بدون التحقق 
.text:FFFFF97FFF1B151B mov ebp, 0FFFFFFFBh 
.text:FFFFF97FFF1B1520 xor eax, esi

في الكود أعلاه، يمكن لـ Win32K!xxxdrawscrollbar استدعاء وضع المستخدم في الظروف المناسبة، وفي كود وضع المستخدم، قد يتم تحرير مؤشر tagSBINFO بواسطة المهاجم. عند العودة إلى الكود أعلاه، سيشير الكود في 0xFFFFF97FFF1B1519 إلى مؤشر غير صالح.

الحالة المصححة:

    .text:FFFFF97FFF1D69C3 xor r8d, r8d 
    .text:FFFFF97FFF1D69C6 mov rdx, rbp 
    .text:FFFFF97FFF1D69C9 call xxxDrawScrollBar        ; تشغيل استدعاء خلفي لوضع المستخدم
    .text:FFFFF97FFF1D69CE cmp rbx, [rdi+0B0h]          ; التحقق من صحة مؤشر tagSBINFO 
 ---.text:FFFFF97FFF1D69D5 jz short loc_FFFFF97FFF1D69E4; إذا كان صحيحًا، استمر في التدفق الأصلي 
 |  .text:FFFFF97FFF1D69D7 mov rcx, rbp 
 |  .text:FFFFF97FFF1D69DA call _ReleaseDC 
 |  .text:FFFFF97FFF1D69DF jmp loc_FFFFF97FFF1D6958     ; القفز إلى خروج الدالة 
 |->.text:FFFFF97FFF1D69E4 mov eax, [rbx]               ; استخدام مؤشر tagSBINFO الصحيح بأمان 
    .text:FFFFF97FFF1D69E6 xor eax, r14d

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

الأساسيات – مرحلة الإفساد 1

عند تنفيذ هذا الاستغلال، قمنا بعدة مراحل من الإفساد. وقمنا بتشغيل الثغرة في إحدى هذه المراحل.

الجذر التقني لهذا الخلل هو UAF (use-after-free) في كومة سطح المكتب (Desktop Heap). في البداية، كان هذا محيرًا بالنسبة لي، لأنني لم أكن على دراية بآلية الاستدعاء الخلفي لوضع المستخدم في win32k.sys، ولم أكن أعرف كيفية عملها. لذلك، اعتقدت أن هذا كان سباقًا (race condition) يؤدي إلى UAF. في الواقع، تم استخدام قفل الهيكل بشكل صحيح، وكان التدفق متوقعًا. باختصار، السبب الحقيقي للمشكلة هو:

1. دالة win32k!xxxEnableWndSBArrows تمتلك مؤشرًا لـ tagSBINFO على كومة سطح المكتب، يتم قراءته من هيكل tagWND المرتبط بالنافذة، ويصف شريط التمرير.
2. دالة win32k!xxxEnableWndSBArrows تستدعي دالة تؤدي إلى استدعاء خلفي لوضع المستخدم (يمكن اعتراض الدالة في وضع المستخدم).
3. بمجرد تنفيذ الكود في مساحة المستخدم، يمكن تعديل الهياكل على كومة سطح المكتب من خلال استدعاءات نظام win32k الأخرى، بما في ذلك تحرير هيكل tagSBINFO من كومة سطح المكتب.
4. عند العودة إلى وضع kernel، لا تستخدم win32k!xxxEnableWndSBArrows مؤشر tagSBINFO من tagWND، ولا تتحقق من صحة المؤشر المشار إليه سابقًا، بل تستخدمه مباشرة (على الرغم من أنه تم تحريره بالفعل).

هذا كل شيء، دون النظر إلى الاستدعاء الخلفي لوضع المستخدم، هذه المرحلة واضحة إلى حد ما.

فهم كيفية التحكم في التدفق

ولكن، كيف نقوم بالإفساد، ولماذا؟ كما ذكر Udi في مدونته، يمكنك تعيين أو مسح بتين في موقع معين، يعتبره النظام كحقل WSBflags في هيكل tagSBINFO. هذه ليست فكرة استغلال UAF التقليدية، لكن المقالة أعطت تلميحًا حول كيفية القيام بذلك، سأشرح ذلك في الأقسام التالية. أولاً، دعونا نفهم كيفية التلاعب بهذه البتات.

هيكل tagSBINFO (متوافق بين 32 بت و64 بت):

kd> dt -b !tagSBINFO 
win32k!tagSBINFO 
    +0x000 WSBflags     : Int4B 
    +0x004 Horz         : tagSBDATA 
        +0x000 posMin   : Int4B 
        +0x004 posMax   : Int4B 
        +0x008 page     : Int4B 
        +0x00c pos      : Int4B 
    +0x014 Vert         : tagSBDATA 
        +0x000 posMin   : Int4B 
        +0x004 posMax   : Int4B 
        +0x008 page     : Int4B 
        +0x00c pos      : Int4B

توجد ثغرة UAF في دالة win32k!xxxEnableWndSBArrows()، والتي تستخدم لتمكين أو تعطيل أسهم عنصر تحكم شريط التمرير (واحد أو اثنين، أفقي أو عمودي). عنصر تحكم شريط التمرير هو نافذة خاصة تستخدم للتلاعب بشريط التمرير. يمكن إنشاؤه بواسطة دالة CreateWindow() باستخدام فئة النافذة المضمنة "SCROLLBAR".

النموذج الأولي لدالة win32k!xxxEnableWndSBArrows():

BOOL xxxEnableWndSBArrows(PWND wnd, UINT WSBflags, UINT wArrows);

معنى معامل WSBflags هو نفسه المحدد في WinUser.h، ويستخدم للإشارة إلى أي أشرطة التمرير سيتم التلاعب بها:

#define SB_HORZ 0 
#define SB_VERT 1 
#define SB_CTL  2 
#define SB_BOTH 3