تخفيف انتحال بروتوكول 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 يمكن أن تتضمن أو لا تتضمن مصدق الرسائل.

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

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

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

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

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

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

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

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

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 الناجح على الأجزاء المعرضة للخطر مثل: واقي مصدر بروتوكول الإنترنت، والفحص الديناميكي ل ARP، وتطفل DHCP. وقد يكون من الممكن أيضا إستخدام طرق مصادقة أخرى استنادا إلى نوع تدفق المصادقة مثل TACACS+ و SAML و LDAPs، وما إلى ذلك...

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

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

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

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

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

ISE كخادم RADIUS

ISE كعميل RADIUS

تحديثات ISE كعميل RADIUS

يتم تضمين تحسينات ISE التي تعمل كعميل RADIUS في الإصدارات: 3.1 تصحيح 10، 3.2 تصحيح 8، 3.3 تصحيح 5، 3.4 تصحيح 2، 3.5 والإصدارات الأحدث من خلال CSCwk67747. قم بترحيل التصحيح أو الترقية، سيقوم أي مورد جديد تم إنشاؤه افتراضيا بالتكوين الجديد الأكثر أمانا. يجب تعديل الموارد الموجودة لاستخدام حزمة نشر التكوين الأكثر أمانا أو الترقية. تمت إضافة خانة إختيار جديدة: "مصدق الرسالة مطلوب عند الاستجابة"، إذا تم تحديده فإنه يخدم غرضا مزدوجا: سيقوم ISE دائما بإرسال مصدق الرسائل، وسيفشل ISE في المصادقة إذا تم تلقي إستجابة دون مصدق رسالة. والسلوك كما يلي:

خادم RADIUS للرمز المميز

خانة إختيار جديدة: تمت إضافة "مصدق الرسائل المطلوب على الاستجابة" أسفل علامة التبويب المصادقة لتكوين خادم RADIUS المميز:

مع تحديد المربع، في حالة تلقي إستجابة RADIUS بدون مصدق الرسالة، يتم تسجيل رسالة فشل في سجل المصادقة التفصيلي الذي يمكن الوصول إليه من خلال السجلات المباشرة أو تقرير مصادقة RADIUS:

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

خادم RADIUS الخارجي

خانة إختيار جديدة: تمت إضافة "مصدق الرسائل المطلوب عند الاستجابة" إلى تكوين خادم RADIUS الخارجي:

مع تحديد المربع، في حالة تلقي إستجابة RADIUS بدون مصدق الرسالة، يتم تسجيل رسالة فشل في سجل المصادقة التفصيلي الذي يمكن الوصول إليه من خلال السجلات المباشرة أو تقرير مصادقة RADIUS:

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

تغيير التفويض (CoA)

تم إجراء تغييرات CoA على ملفات تعريف جهاز الشبكة ضمن درج تغيير التخويل (CoA):

إن الخيار "إرسال مصدق رسالة" هو ميزة سابقة، والخيار الجديد هو "مصدق رسالة مطلوب على الاستجابة. سيقوم ISE بإرسال سمة مصدق الرسالة إذا تم التحقق من مصدق الرسالة المطلوب على الاستجابة بغض النظر عما إذا كان قد تم التحقق من "إرسال مصدق الرسالة" أم لا. يتم الاحتفاظ ب "Send-Message-Authenticator" للتكوينات الموجودة. إذا لم يتضمن NAD "مصدق الرسائل" في "إستجابة CoA"، فسيتم ملاحظة الخطأ التالي في تقرير المصادقة التفصيلي المتاح من خلال "سجلات حية":

 **ملاحظة: قد يكون CoA ناجحا على NAD حتى في حالة تسجيل فشل في ISE لأن NAD قد يكون قد قام بمعالجة CoA ولكنه لم يتضمن مصدق الرسالة في الاستجابة.

لا يمكن تعديل توصيفات جهاز الشبكة "المقدمة من Cisco" الافتراضية لاستخدام الخيار الجديد يمكن مضاعفة توصيف جهاز الشبكة والإعداد الذي يمكن على التوصيف المضاعف. ستحتاج بعد ذلك إلى تعيين ملف تعريف جهاز الشبكة الذي تم إنشاؤه حديثا. وقد تم القيام بذلك لتقليل مخاطر التسبب في انقطاع الشبكة بعد تصحيح أو ترقية من خلال إدخال عدم توافق بين ISE و NADs الموجودة. إذا كان هناك توصيف قائم بتعريف مستخدم قيد الاستخدام فمن المستحسن مضاعفة ذلك التوصيف واختبار واحد على الأقل من كل نوع جهاز على الشبكة باستخدام ذلك التوصيف قبل عمل تغيير على توصيف جهاز الشبكة الموجود.