تخفيف انتحال بروتوكول CVE-2024-3596 لنصف قطر الانفجار

المقدمة

في 7 يوليو/تموز 2024، كشف باحثو الأمن عن نقاط الضعف التالية في بروتوكول RADIUS: CVE-2024-3596: بروتوكول RADIUS بموجب RFC 2865 قابل لهجمات تزييف من قبل مهاجم في المسار يمكنه تعديل أي إستجابة صالحة (قبول الوصول أو رفض الوصول أو تحدي الوصول) لأي إستجابة أخرى باستخدام هجوم تصادم البادئة المختارة ضد توقيع مصدق إستجابة MD5. وقد نشرت ورقة تفصل النتائج التي توصلت إليها على الموقع https://www.blastradius.fail/pdf/radius.pdf، وهي تبين أن هناك عملية تزوير ناجحة في الاستجابة للتدفقات التي لا تستخدم سمة مصدق الرسائل.

للحصول على قائمة محدثة بمنتجات Cisco التي تأثرت بنقاط الضعف هذه والإصدارات التي تحتوي على إصلاحات، يرجى زيارة: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-radius-spoofing-july-2024-87cCDwZ3. تغطي هذه المقالة تقنيات التخفيف العامة بالإضافة إلى كيفية تطبيقها على بعض منتجات Cisco، ولكن ليس جميع منتجات Cisco، يجب الرجوع إلى وثائق المنتجات الفردية للحصول على تفاصيل. كخادم رائد ل Cisco RADIUS، ستتم تغطية محرك خدمة الهوية بمزيد من التفاصيل.

الخلفية

يستغل هذا الهجوم هجوم بادئة MD5 المختارة باستخدام التصادمات في MD5، والتي تسمح للمهاجم بإضافة بيانات إضافية إلى حزمة إستجابة RADIUS أثناء تعديل السمات الموجودة لحزمة الاستجابة. وقد تمثل المثال الذي تم توضيحه في القدرة على تغيير رفض الوصول إلى RADIUS إلى قبول وصول RADIUS. وهذا ممكن لأن RADIUS لا يتضمن بشكل افتراضي تجزئه لكل السمات في الحزمة. لا يقوم RFC 2869 بإضافة سمة مصدق الرسائل ولكنها حاليا مطلوبة للتضمين عند إستخدام بروتوكولات EAP، مما يعني أن وصف الهجوم في CVE-2024-3596 ممكن مقابل أي تبادل غير EAP حيث لا يتضمن عميل RADIUS (NAD) سمة مصدق الرسائل.

تخفيف

مصدق الرسائل

1) يجب أن يتضمن عميل RADIUS سمة مصدق الرسائل.

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

2) يجب أن يفرض خادم RADIUS تلقي سمة مصدق الرسائل.

ولا يكفي مجرد تضمين مصدق الرسائل في طلب الوصول لأن الهجوم يجعل من الممكن أن يجرد مصدق الرسائل من طلب الوصول قبل أن تتم إعادة توجيهه إلى خادم RADIUS. كما يجب أن يتطلب خادم RADIUS أن يتضمن NAD مصدق الرسائل في طلب الوصول. وهذا الأمر ليس افتراضيا على Identity Services Engine (محرك خدمات الهوية) ولكن يمكن تمكينه على مستوى البروتوكولات المسموح بها، والذي يتم تطبيقه على مستوى مجموعة النهج. الخيار ضمن تكوين البروتوكولات المسموح بها هو "طلب مصدق الرسالة" لجميع طلبات RADIUS:

خيار البروتوكولات المسموح بها في محرك خدمات الهوية

عمليات المصادقة التي تطابق مجموعة نهج حيث يتطلب تكوين البروتوكولات المسموح بها مصادقة الرسائل، ولكن في حالة عدم إحتواء طلب الوصول على سمة مصدق الرسائل سيتم إسقاطها من قبل ISE:

من المهم التحقق مما إذا كان NAD يرسل مصدقا للرسائل قبل أن يكون مطلوبا بواسطة خادم RADIUS لأن هذه ليست سمة تم التفاوض عليها، فمن حق NAD إرسالها إما بشكل افتراضي أو أن يتم تكوينه لإرسالها. لا يعد مصدق الرسائل إحدى السمات التي تم الإبلاغ عنها بواسطة ISE، ويعد التقاط الحزمة أفضل طريقة لتحديد ما إذا كانت حالة NAD/Use تتضمن مصدق الرسائل. قام ISE بإنشاء وظيفة التقاط الحزم ضمن Operations -> أستكشاف الأخطاء وإصلاحها -> Diagnostic Tools -> General Tools -> TCP Dump. تذكر أن حالات الاستخدام المختلفة من نفس NAD يمكن أن تتضمن أو لا تتضمن مصدق الرسائل.

فيما يلي التقاط مثال ل Access-Request يتضمن سمة مصدق الرسائل:

سمة مصدق الرسائل في طلب وصول Radius

فيما يلي مثال على التقاط طلب وصول لا يتضمن سمة مصدق الرسائل:

التشفير باستخدام TLS/IPSec

أكثر الحلول فعالية على المدى البعيد لتأمين RADIUS هو تشفير حركة مرور البيانات بين خادم RADIUS و NAD. وهذا يضيف كلا من الخصوصية وسلامة التشفير الأقوى بمجرد الاعتماد على مصدق الرسائل المشتق من MD5-HMAC. والذي، إذا كان أي من هذه يمكن إستخدامه بين خادم RADIUS و NAD يعتمد على كلا الجانبين اللذين يدعمان طريقة التشفير.

المصطلحات الواسعة المستخدمة عبر الصناعة لتشفير TLS ل RADIUS هي:

•  "RadSec" - يشير إلى RFC 6614
• "RadSec TLS" - يشير إلى RFC 6614
• "DTLS ل RadSec" - يشير إلى RFC 7360

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

RADIUS عبر DTLS

يتم تحديد أمان طبقة نقل البيانات (DTLS) كطبقة نقل ل RADIUS بواسطة RFC 7360 الذي يستخدم الشهادات للمصادقة بشكل متبادل على خادم RADIUS ثم يقوم NAD بتشفير حزمة RADIUS بالكامل باستخدام نفق TLS. يبقى أسلوب النقل UDP ويتطلب نشر الشهادات على كل من خادم RADIUS و NAD. تذكر أنه عند نشر RADIUS عبر DTLS، من الضروري أن تتم إدارة انتهاء صلاحية الشهادة واستبدالها بشكل وثيق لمنع الشهادات منتهية الصلاحية من قطع اتصال RADIUS. يدعم ISE DTLS من أجل ISE إلى الاتصال، كما أن ISE 3.4 Radius over DTLS غير مدعوم لخوادم RADIUS-proxy أو RADIUS Token. كما يتم دعم RADIUS عبر DTLS بواسطة العديد من أجهزة Cisco التي تعمل كقوائم التحكم في الشبكة (NAD) مثل المحولات ووحدات التحكم اللاسلكية التي تعمل بنظام التشغيل IOS-XE®.

RADIUS عبر TLS

يتم تحديد تشفير أمان طبقة النقل (TLS) ل RADIUS بواسطة RFC 6614، ويغير النقل إلى TCP ويستخدم TLS لتشفير حزم RADIUS بالكامل. وتستخدم خدمة التعليم هذا عادة كمثال. اعتبارا من ISE 3.4، لا يتم دعم RADIUS عبر TLS، ولكنه مدعوم من قبل العديد من أجهزة Cisco التي تعمل كقوائم التحكم في الشبكة (NADs) مثل المحولات ووحدات التحكم اللاسلكية التي تشغل IOS-XE.

IPsec

يتمتع محرك خدمات الهوية بدعم أصلي لأنفاق IPSec بين ISE و NADs التي تدعم أيضا إنهاء أنفاق IPSec. هذا خيار جيد حيث RADIUS عبر DTLS أو RADIUS عبر TLS غير مدعوم ولكن يجب إستخدامه بشكل محدود حيث يتم دعم 150 نفقا فقط لكل عقدة خدمات نهج ISE. لم يعد معيار ISE 3.3 والإصدارات اللاحقة يتطلب ترخيص IPSec، بل أصبح متوفرا الآن بطبيعته.

تخفيف جزئي

تجزئة RADIUS

حركة مرور المقطع RADIUS إلى شبكات VLAN الإدارية وارتباطات آمنة ومشفرة مثل ما يمكن توفيره عبر SD-WAN أو MACec. هذه الاستراتيجية لا تجعل خطر الهجوم صفرا، لكنها يمكن أن تقلل إلى حد كبير من سطح الهجوم في حالة الضعف. يمكن أن يكون ذلك مقياسا جيدا لتوقف الثغرات أثناء قيام المنتجات بطرح متطلبات مصدق الرسائل أو دعم DTLS/RadSec. ويتطلب الاستغلال أن يتواصل المهاجم بنجاح مع الدخيل (MITM) عبر نصف القطر بحيث لا يتمكن المهاجم من الوصول إلى مقطع الشبكة مع حركة المرور تلك، لا يمكن الهجوم. السبب في أن هذا تخفيف جزئي فقط هو أن تكوين الشبكة أو الحل الوسط لجزء من الشبكة يمكن أن يعرض حركة مرور RADIUS.

إذا تعذر تجزئة حركة مرور RADIUS أو تشفيرها، يمكن تنفيذ ميزات إضافية لمنع تشغيل MITM الناجح على الأجزاء المحفوفة بالمخاطر مثل: واقي مصدر بروتوكول الإنترنت (IP)، والفحص الديناميكي ل ARP، وتطفل بروتوكول التكوين الديناميكي للمضيف (DHCP). وقد يكون من الممكن أيضا إستخدام طرق مصادقة أخرى استنادا إلى نوع تدفق المصادقة مثل TACACS+ و SAML و LDAPs، وما إلى ذلك...

حالة الضعف لمحرك خدمات الهوية

الجداول التالية تصف المتوفر اعتبارا من ISE 3.4 لجعل تدفقات المصادقة محمية ضد شعاع الانفجار. للملخص، يجب وضع العناصر الثلاثة التالية في حالة تدفق باستخدام مصدق الرسائل فقط وليس تشفير DTLS/RadSec/IPSec، حتى لا يكون التدفق معرضا للخطر:
1) يجب أن يرسل جهاز الوصول إلى الشبكة سمة مصدق الرسائل في طلب الوصول.

2) يجب أن يتطلب خادم RADIUS سمة مصدق الرسائل في طلب الوصول.

3) يجب أن يستجيب خادم RADIUS بسمة مصدق الرسائل في تحدي الوصول وقبول الوصول ورفض الوصول.

يرجى الرجوع إلى CSCwk67747 الذي يتتبع التغييرات لإغلاق نقاط الضعف عندما يعمل ISE كعميل RADIUS.

ISE كخادم RADIUS

ISE كعميل RADIUS