تشير درجة CVSS البالغة 9.8 إلى مشكلة شبه قصوى الخطورة تتطلب تصحيحًا فوريًا.

2. ما الذي قمنا به

خلال هذا البحث، قمنا بالأعمال التالية:

1. دراسة خلفية CVE
   شرحنا ما هي CVE، وكيف يتم تعيين المعرّفات بواسطة MITRE، وما المعلومات التي يحتويها سجل CVE النموذجي.

2. توصيف الثغرة
   وثّقنا لماذا تُعتبر CVE-2024-38063 ثغرة "الكأس المقدسة": لا تتطلب مصادقة، ولا تفاعلًا من المستخدم، وقابلة للانتشار كدودة، وIPv6 مفعّل افتراضيًا، وتأثيرها على مستوى النواة.

3. أساسيات IPv6
   غطّينا الاختلافات بين IPv4 وIPv6، ودور الترويسات الممتدة (extension headers)، ولماذا يعمل التجزئة (fragmentation) بشكل مختلف في IPv6.

4. تحليل عميق للسبب الجذري
   تتبعنا مسار الحزمة الكامل داخل tcpip.sys:

   • كيفية تفاعل ترويسة خيارات الوجهة (Destination Options) مع ترويسة التجزئة (Fragment)
   • دور تجميع NET_BUFFER_LIST (NBL)
   • سلوك Ipv6pProcessOptions وIppSendErrorList
   • التدفق السفلي الصحيح (integer underflow) في Ipv6pReceiveFragment
   • عدم تطابق تخصيص 16-بت مقابل نسخ 32/64-بت مما يؤدي إلى تجاوز سعة كومة النواة
   • المسار من شاشة الموت الزرقاء (BSOD) إلى تنفيذ التعليمات البرمجية عن بُعد المحتمل

5. تقييم المصطلحات والصعوبة
   أنشأنا جداول واضحة تشرح المصطلحات الأمنية، والمفاهيم الخاصة بنظام Windows، والصعوبة النسبية لكل مرحلة من مراحل الاستغلال.

6. تطوير إثبات المفهوم (PoC)
   بنينا ووثّقنا سكربت Python قائمًا على Scapy يقوم بإنشاء حزم خيارات الوجهة غير الصالحة المتداخلة المطلوبة وقطع IPv6 لتفعيل الثغرة.

7. دليل مختبر معزول كامل
   كتبنا تعليمات خطوة بخطوة من أجل:

   • إعداد جهازي افتراضيين: Kali (المهاجم) وWindows غير مُحدَّث (الهدف)
   • تكوين عناوين IPv6 ثابتة
   • تفعيل تجميع الحزم باستخدام bcdedit /set debug on
   • تعطيل جدار الحماية
   • تشغيل PoC والتحقق من شاشة الموت الزرقاء
   • استكشاف الأخطاء الشائعة وإصلاحها

8. العرض التوضيحي
   سجّلنا فيديو يعرض الإعداد الكامل للمختبر، وتنفيذ السكربت، والانهيار الناجح.

9. مراجعة التصحيح
   وثّقنا التحديثات التراكمية الرسمية لشهر أغسطس 2024 (أرقام KB) وكيف يزيل الإصلاح حالة السباق (race condition).

3. لماذا هذه الثغرة حرجة

تمتلك هذه الثغرة عدة خصائص عالية الخطورة:

• لا تتطلب مصادقة – يحتاج المهاجم فقط إلى القدرة على إرسال حزم الشبكة.
• لا تفاعل من المستخدم – لا يحتاج الضحية إلى النقر على الروابط، أو فتح الملفات، أو حتى أن يكون حاضرًا.
• قابلة للانتشار كدودة – يمكن للاستغلال الناجح نظريًا أن ينتشر تلقائيًا من جهاز إلى آخر (مشابهة في فئتها لـ EternalBlue / WannaCry).
• IPv6 مفعّل افتراضيًا – أنظمة Windows الحديثة لديها IPv6 نشط حتى لو كانت الشبكة تستخدم IPv4 بشكل أساسي.
• تأثير على مستوى النواة – الخلل موجود في tcpip.sys (Ring 0). الاستغلال الناجح يمنح تحكمًا كاملًا في النظام.
• ناقل هجوم معقد لكنه واقعي – إنها حالة سباق تتطلب توقيتًا دقيقًا للحزم وتجميعها، مما يجعل الاستغلال الموثوق غير تافه لكنه قابل للتحقيق من قبل مهاجمين مهرة.

4. السبب الجذري التقني (ملخص)

مكونات التفعيل

يتم تفعيل الثغرة من خلال مزيج من ترويستي IPv6 ممتدتين:

1. ترويسة خيارات الوجهة (nh=60)
   تحتوي على نوع خيار غير صالح (otype > 0x80). وهذا يجبر Windows على توليد خطأ ICMPv6 Parameter Problem.

2. ترويسة التجزئة (nh=44)
   تُبقي الحزم في قائمة انتظار إعادة التجميع الخاصة بـ IPv6 حتى بعد تلفها.

سلسلة الهجوم

1. يرسل المهاجم تدفقًا سريعًا من حزم خيارات الوجهة غير الصالحة المتداخلة وقطع IPv6.
2. يتم تجميع الحزم بواسطة NDIS في NET_BUFFER_LIST (NBL) واحد.
3. يكتشف Ipv6pProcessOptions الخيار السيئ ويسلّم NBL إلى IppSendErrorList.
4. يضبط IppSendErrorList علامة داخلية بشكل غير صحيح ويفسد الحزم اللاحقة في نفس NBL، مما يجبر DataLength الخاص بها على الصفر.
5. بسبب ترويسة التجزئة، لا تزال الحزم ذات الطول الصفري تُوضع في قائمة انتظار إعادة التجميع بدلًا من إسقاطها.
6. يحسب Ipv6pReceiveFragment حجم الحمولة كـ 0 − HeaderSize، مما يسبب تدفقًا سفليًا صحيحًا (يصبح طول الحمولة ~4 جيجابايت).
7. يتم تخصيص مخزن صغير (حساب الحجم 16-بت يُقتطع)، لكن RtlCopyMemory ينسخ الطول الهائل الناتج عن التدفق السفلي → تجاوز سعة كومة النواة.
8. النتيجة: شاشة الموت الزرقاء (BSOD) أو، مع تحكم دقيق في التجاوز، تنفيذ التعليمات البرمجية عن بُعد.

يتوفر مخطط تفصيلي لتدفق البيانات وتحليل على مستوى الدوال في التقرير الكامل.

5. محتويات المستودع

ضع الملفات الداعمة الثلاثة في جذر المستودع (أو حدّث المسارات) بحيث تبقى مرتبطة.

6. متطلبات السلامة في المختبر

• قم بإجراء كل الاختبارات داخل أجهزة افتراضية معزولة تمامًا (شبكة Host-Only أو Internal فقط).
• لا تستخدم أبدًا جهاز إنتاج أو أي نظام متصل بالإنترنت أو بشبكة الشركة.
• يجب أن يبقى نظام Windows الهدف غير مُحدَّث (قبل التحديث التراكمي لشهر أغسطس 2024).
• فعّل تصحيح أخطاء النواة على الهدف (bcdedit /set debug on + إعادة تشغيل) لتحسين موثوقية تجميع الحزم.
• عطّل جدار حماية Windows لشبكة المختبر.
• استخدم عناوين IPv6 ثابتة متطابقة على كل من المهاجم والهدف (قيم أمثلة مستخدمة في السكربت: 2001:db8::20 → المهاجم، 2001:db8::10 → الهدف).

خطوات التكوين الكاملة، ومصفوفة استكشاف الأخطاء وإصلاحها، وتعليمات التنظيف موثقة في التقرير.

7. التصحيح الرسمي

أصدرت Microsoft الإصلاح كجزء من التحديثات التراكمية لشهر أغسطس 2024:

يُدخل التصحيح قفلًا مناسبًا حول مسارات التعليمات البرمجية المتأثرة، مما يزيل حالة السباق التي أدت إلى التدفق السفلي الصحيح والكتابة خارج الحدود.

8. إخلاء المسؤولية

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

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

10. المراجع

فريق البحث

• Mayank
• Surya Prakash
• Hiba