CVE-2024-38063-

استغلال النواة عن بُعد عبر IPv6

CVE-2024-38063 - استغلال النواة عن بُعد عبر IPv6 ماركوس هوتشنز

منذ أن تم إصدار آخر تصحيح لويندوز في 13 أغسطس، كنت منغمسًا بعمق في tcpip.sys (برنامج تشغيل النواة المسؤول عن معالجة حزم TCP/IP). ثغرة بتقييم CVSS 9.8 في الجزء الأكثر سهولة في الوصول إليه من نواة ويندوز كانت شيئًا لم أستطع ببساطة تفويته. لم أنظر أبدًا إلى IPv6 من قبل (أو برامج التشغيل المسؤولة عن تحليله)، لذلك عرفت أن محاولة هندسة هذه الثغرة عكسيًا ستكون صعبة للغاية، لكنها ستكون تجربة تعليمية جيدة.

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

لاحقًا، أثناء البحث في جوجل عن أسماء بعض الدوال، صادفت تحليلًا آخر لنفس الثغرة من عام 2021، كتبه أكسل سوشيه (المعروف بـ 0vercl0k)، والذي تعمق أكثر في التفاصيل الداخلية لـ tcpip.sys وأعطاني معلومات كافية لتعريف العديد من الهياكل غير الموثقة. أسهل تحليل تصحيح على الإطلاق

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

كان هناك تغيير واحد بالضبط تم إجراؤه في ملف برنامج التشغيل بأكمله، والذي اتضح أنه بالفعل كان الثغرة.

نظرة عامة من Bindiff على tcpip.sys قبل وبعد تثبيت التصحيح.

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

Ipv6pProcessOptions() قبل التصحيح.

Ipv6pProcessOptions() بعد التصحيح.

لم يكن التغيير مجرد دالة واحدة، بل سطر واحد من الكود.

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

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

مع أخذ هذا في الاعتبار، من الواضح أن كل ما يفعله هذا التصحيح هو استبدال استدعاء IppSendErrorList() بـ IppSendError()، مما يعطينا فكرة أن المشكلة تتعلق بنوع من القائمة. أسهل مقارنة تصحيح على الإطلاق (أو هكذا اعتقدت). الثغرات اختيارية، الاستغلال إلزامي

هندسة التصحيح عكسيًا للعثور على الكود المعدل ليست سوى نصف التحدي (أو في هذه الحالة أقل من 0.1%). باقي العملية يتكون من هندسة جزء كافٍ من قاعدة الكود عكسيًا لفهم ما يحدث، ومعرفة نوع الثغرة التي تم إصلاحها، وكيفية صياغة طلب للوصول إلى الكود المستهدف، وأي حالة تؤدي إلى حالة قابلة للاستغلال.

الجزء الأول سهل بما يكفي. التغيير موجود في Ipv6pProcessOptions()، مما يخبرنا أنه IPv6 ويتضمن معالجة الخيارات. لذا، استدعاء سريع لـ RFC يخبرنا بالضبط ما هو خيار IPv6 وأين يمكننا العثور عليه.

تخطيط رأس خيارات الوجهة من ويكيبيديا.

حسنًا، رائع. ما نبحث عنه يبدو أنه رأس خيارات الوجهة، والذي يقع مباشرة بعد رأس IPv6 الرئيسي. دعنا نستخدم مكتبة بايثون 'scapy' لصياغة حزمة IPv6 اختبارية.

ملاحظة: للتخفيف من هجمات رفض الخدمة (DDoS) باستخدام عناوين IP مزيفة، يقيد ويندوز القدرة على بناء حزم IP خام. لهذا السبب، اخترت استخدام لينكس لتطوير إثبات المفهوم الخاص بي. بينما يسمح لينكس للمستخدمين ببناء وإرسال حزم الطبقة الثانية والثالثة الخام، فإنه يتطلب تشغيل سكريبت بايثون كجذر.

import sys
import struct
from scapy.all import *


def send_ipv6_option_packet(dest_ip):
	ethernet_header = Ether()
	ip_header = IPv6(dst=dest_ip)
	options_header = IPv6ExtHdrDestOpt()
	sendp(ethernet_header / ip_header / options_header)
	
	
if len(sys.argv) < 2:
	print('Use: python3 script.py <target_ipv6_address>')
	exit(-1)

send_ipv6_option_packet(sys.argv[1])

بعد تعيين نقطة توقف على tcpip!Ipv6pProcessOptions، ثم تشغيل السكريبت، كان واضحًا أن كل ما هو مطلوب للوصول إلى الدالة المعرضة للثغرة هو إرسال حزمة IPv6 بهيكل خيارات فارغ. ثم حاولت إضافة بعض الخيارات غير الصالحة إلى الهيكل لمعرفة ما إذا كان بإمكاني الوصول إلى استدعاء IppSendErrorList().

أشارت مراجعة سريعة للكود إلى أن أي تنسيق خيار غير صالح تقريبًا يمكن أن يؤدي إلى استدعاء IppSendErrorList. لذا، قررت استخدام خيار Jumbo Packet بطول غير صالح (أقل من 65535 بايت).

options_header = IPv6ExtHdrDestOpt(options=[Jumbo(jumboplen=0x1337)])

إذن، ما الذي يفعله IppSendErrorList() بالفعل؟ حسنًا، الكود بسيط جدًا.

دالة IppSendErrorList بأكملها.

يقوم الكود بالتكرار عبر قائمة مرتبطة ويستدعي IppSendError() على كل عنصر في القائمة. مرة أخرى، اصطفت النجوم وكانت الأمور سهلة حتى الآن. إذا كان IppSendErrorList يستدعي فقط IppSendError لكل عنصر في قائمة، والتصحيح يستبدل استدعاء IppSendErrorList بـ IppSendError، فإن المشكلة تحدث عندما يتم استدعاء IppSendError على عنصر قائمة غير العنصر الأول.

إذن، ما هي هذه القائمة؟ وكيف نصنع واحدة؟ إنه يقوم بعمل قائمة، إنه يتحقق منها… 52,567 مرة

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

من خلال النظر إلى الدوال والهيكل الذي هندسه أكسل عكسيًا، وأي الدوال الأخرى يتم تمريرها إليها، من الواضح أن الوسيطة الوحيدة التي يتم تمريرها إلى Ipv6pProcessOptions() هي نفس هيكل packet_t المحدد في المقالة. بشكل أساسي، المؤشر الذي يتم تمريره إلى Ipv6pProcessOptions، والذي يتم التكرار عليه بواسطة IppSendErrorList، هو قائمة مرتبطة من الحزم.

لذلك، قمت بتعيين نقطة توقف على Ipv6pProcessOptions() وفحصت القائمة.

الإدخال list->Next هو NULL.

في كل مرة يتم فيها الوصول إلى نقطة التوقف الخاصة بي، كانت القائمة تحتوي على حزمة واحدة فقط. قضيت وقتًا أطول مما أعترف به في محاولة معرفة السبب وكيفية جعل قائمتي قائمة فعلية. كان أول فكرة لي هي تجزئة IPv6: يسمح IPv6 للمرسلين بتقسيم الحزم الكبيرة إلى حزم منفصلة أصغر، والتي سيكون من المنطقي الاحتفاظ بها معًا في قائمة.

بعد هندسة عكسية مكثفة، أكدت افتراضاتي كانت صحيحة، على الرغم من أن قائمة التجزئة لا تتعلق بالقائمة التي نتعامل معها هنا.

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

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

الآن بعد أن علمنا أن الحزم يتم تجميعها في قوائم أثناء الإنتاجية العالية، من الواضح ما هو الخيار الأسهل. المفارقة هي أن إثبات المفهوم الخاص بهجوم رفض الخدمة (DoS) سيضطر إلى استخدام هجوم DoS لتحفيز حالة DoS. إذا قمنا بإغراق النظام بدفعات من حزم IPv6، يجب أن نتمكن من الحصول على قائمة كبيرة وجميلة تمر إلى IppSendErrorList().