CVE-2020-16898: "الجار السيئ"

درجة CVSS: 8.8

متجه CVSS: CVSS3.0/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C

نظرة عامة

في 13 أكتوبر، أعلنت مايكروسوفت عن ثغرة أمنية بالغة الخطورة في مكدس IPv6 في نظام ويندوز، والتي تسمح للمهاجم بإرسال حزم مصممة بشكل خبيث لتنفيذ تعليمات برمجية عشوائية على نظام بعيد. إثبات المفهوم الذي تم مشاركته مع أعضاء MAPP بسيط للغاية وموثوق تمامًا. يؤدي إلى ظهور شاشة الموت الزرقاء (BSOD) فورًا، ولكن الأهم من ذلك، يشير إلى احتمالية استغلال الثغرة لأولئك الذين يمكنهم تجاوز تدابير الحماية في ويندوز 10 وويندوز سيرفر 2019. ستكون آثار الاستغلال الذي قد يسمح بتنفيذ التعليمات البرمجية عن بُعد واسعة النطاق ومؤثرة للغاية، حيث أن هذا النوع من الأخطاء يمكن أن يصبح قابلاً للانتشار (wormable). لسهولة الإشارة، أسمينا الثغرة "الجار السيئ" لأنها تقع ضمن بروتوكول اكتشاف الجوار ICMPv6 (Neighbor Discovery "Protocol")، باستخدام نوع إعلان الموجه (Router Advertisement).

تم إعداد هذا المستند بواسطة فريق McAfee Advanced Threat Research. وهو يهدف إلى تقديم رؤى قيمة لمسؤولي الشبكات وأفراد الأمن الذين يسعون إلى فهم هذه الثغرة بشكل أفضل والدفاع ضد استغلالها. يجب دراسة التوقيع الذي تم إنتاجه هنا بدقة واختباره في بيئات الاختبار قبل استخدامه في الإنتاج، وقد يستفيد من ضبط خاص للنشر المستهدف.

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

التوقيع

يوجد توقيع Suricata لهذه الثغرة في cve-2020-16898.rules ويحتوي على المنطق التالي:

alert icmp any any -> any any (msg:"Potential CVE-2020-16898 Exploit"; lua:cve-2020-16898.lua; sid:202016898; rev:1;)

يمكن العثور على البرنامج النصي Lua المقابل في cve-2020-16898.lua. يحتوي على المنطق اللازم لتحليل طبقة ICMPv6 بشكل صحيح وتحديد الاستغلال المحتمل لـ "الجار السيئ"، كما يلي:

بمجرد تحديد موقع بداية طبقة ICMPv6، نختبر أول بايت من الطبقة للتأكد من أنها حزمة ICMPv6 من نوع إعلان الموجه (Router Advertisement) (النوع = 134) - إذا لم تكن كذلك، نخرج.

نظرًا لأن أساسيات Suricata لم يتم تحديثها لتحليل خيارات ICMPv6، فإننا نقوم ببساطة بالقفز إلى البايت رقم 17 من طبقة ICMPv6، لأن الخيارات يجب أن تبدأ من هناك، إذا كانت موجودة (أول 16 بايت هي حقول ذات طول ثابت، وفقًا لـ RFC 4443). من هناك، نتنقل عبر كل خيار حتى ننفد البايتات في الحزمة. لكل خيار، نحن مهتمون فقط بالبايتين الأوليين: حقلي نوع الخيار (Option Type) وطوله (Length) على التوالي. بينما نتجاهل جميع الخيارات التي ليست RDNSS، بالنسبة لنوع الخيار = 25 (RDNSS)، نتحقق مما إذا كان الطول (الثاني بايت في الخيار) رقمًا زوجيًا. إذا كان كذلك، نضع علامة عليه. إذا لم يكن كذلك، نستمر. نظرًا لأن الطول يُحسب بزيادات مقدارها 8 بايت، فإننا نضرب الطول في 8 ونقفز للأمام بذلك العدد من البايتات للوصول إلى بداية الخيار التالي (نطرح 1 لمراعاة بايت الطول الذي استهلكناه بالفعل).

مع هذه القاعدة، نتحقق أيضًا من أن الطول لا يقل عن 3، نظرًا لأن RFC 8106 يتطلب ذلك، ولكن في النهاية قد يكون هذا الفحص غير ضروري، لأننا نهتم فقط بما إذا كان الطول زوجيًا أم لا.