advanced-threat-research/cve-2020-16899CVE-2020-16899 - منطق وقاعدة كشف ثغرة TCP/IP في Microsoft Windows
في الثالث عشر من أكتوبر، أعلنت مايكروسوفت عن ثغرة حرجة في مكدس IPv6 لويندوز، تسمح لمهاجم بإرسال حزم تم إنشاؤها بشكل خبيث تؤدي إلى تعطل فوري (شاشة الموت الزرقاء) على أحدث إصدارات ويندوز 10 وويندوز سيرفر 2019. على الرغم من أن هذه الثغرة لا تسمح للمهاجم بتنفيذ التعليمات البرمجية، إلا أنها يمكن استخدامها لشن هجمات رفض خدمة جماعية على إصدارات ويندوز المعرضة للخطر. يمكن العثور على منطق الكشف عن النسخة الأكثر تأثيراً من هذه الثغرة (RCE) في CVE-2020-16898: "Bad Neighbor".
تم إعداد هذا المستند من قبل فريق أبحاث التهديدات المتقدمة في McAfee. وهو يهدف إلى تقديم رؤى قيمة لمسؤولي الشبكات وأفراد الأمن الذين يتطلعون إلى فهم هذه الثغرة بشكل أعمق والدفاع ضد استغلالها. يجب دراسة التوقيع المُنتَج هنا بعناية واختباره في بيئات الاختبار قبل استخدامه في الإنتاج، وقد يستفيد من ضبط خاص ليناسب النشر المستهدف.
المعلومات الواردة هنا عرضة للتغيير دون إشعار، ويتم تقديمها "كما هي"، مع جميع العيوب، دون ضمان أو كفالة بشأن دقة المعلومات أو قابليتها للتطبيق على أي موقف أو ظرف معين، ويتم استخدامها على مسؤوليتك الخاصة. بالإضافة إلى ذلك، لا يمكننا ضمان أي أداء أو معايير فعالية لأي توقيعات.
الثغرة هي نتيجة لقراءة خارج الحدود يمكن أن تحدث عندما يقوم مكدس IPv6 لويندوز بمعالجة حزم إعلان الموجه ICMPv6 (النوع = 134) التي تحتوي على سجل أو أكثر من سجلات خيار DNSSL (نوع الخيار = 31). الغرض من سجل DNSSL هو توفير قائمة بحث من لواحق أسماء DNS، الموجودة في حقلها الأخير. نظراً لأن قائمة البحث هذه يمكن أن تحتوي على عدة أسماء DNS منتهية بقيمة فارغة متتالية، فإن الحقل (وبالتالي السجل بأكمله) يمكن أن يختلف حجمه بشكل كبير. لاستيعاب ذلك، يحتوي سجل خيار DNSSL على حقل طول خاص به. ومع ذلك، نظراً لأن الطول يُحسب بزيادات قدرها 8 بايت، فقد يكون لواحد على الأقل من أسماء النطاقات في قائمة البحث حشو إضافي بقيم فارغة للحفاظ على محاذاة السجل بمقدار 8 بايت. في معالجة هذه القيم الفارغة يمكن العثور على الثغرة.
لكل اسم نطاق في قائمة البحث، يقوم مكدس IPv6 لويندوز بتخصيص مخزن مؤقت بحجم 256 بايت. نظراً لأن RFC 1035 يحد أسماء النطاقات بـ 255 بايت، فإن هذا سيكون كافياً عادةً لاحتواء اسم نطاق بالإضافة إلى الفاصل الفارغ. ومع ذلك، فإن الكود المسؤول عن استهلاك القيم الفارغة في نهاية كل اسم نطاق لديه حد أعلى يساوي البايتات المتبقية في الخيار، والتي يمكن أن تتجاوز 256 بايت. والنتيجة هي أن الكود المستهلك للقيم الفارغة يمكن أن يستهلك بايتات أكثر مما تم تخصيصه للمخزن المؤقت، مما يؤدي إلى قراءة خارج الحدود. في الحالة التي يقع فيها المخزن المؤقت في نهاية صفحة ذاكرة، يمكن أن تؤدي هذه القراءة خارج الحدود إلى تعطل (شاشة الموت الزرقاء).
يوجد توقيع Suricata لهذه الثغرة في cve-2020-16899.rules ويحتوي على المنطق التالي:
alert icmp any any -> any any (msg:"Potential CVE-2020-16899 Exploit"; lua:cve-2020-16899.lua; sid:202016899; rev:1;)
يمكن العثور على سكريبت Lua المقابل في cve-2020-16899.lua. يحتوي على المنطق اللازم لتحليل طبقة ICMPv6 بشكل صحيح وتحديد الاستغلال المحتمل لـ CVE-2020-16899، على النحو التالي:
بمجرد أن نحدد بداية طبقة ICMPv6، نختبر البايت الأول من الطبقة للتأكد من أنها حزمة إعلان موجه ICMPv6 - إذا لم تكن كذلك، نخرج.
نظراً لأن بدائيات Suricata لم يتم تحديثها لتحليل خيارات ICMPv6، فإننا ببساطة نقفز إلى البايت السابع عشر من طبقة ICMPv6، حيث تبدأ الخيارات إذا كانت موجودة (أول 16 بايت هي حقول بطول ثابت، وفقاً لـ RFC 4443). من هناك، نتنقل عبر كل خيار حتى ننفد البايتات في الحزمة. لكل خيار، نبدأ بفحص البايت الأول، الذي يتوافق مع حقل نوع الخيار. بينما نتجاهل جميع الخيارات التي ليست DNSSL، بالنسبة لنوع الخيار = 31 (DNSSL)، نتحقق مما إذا كان الطول (البايت الثاني في الخيار) أكبر من أو يساوي 35، وهو الحد الأدنى للطول المطلوب لتفعيل الثغرة:
