F5 BIG-IP جعلت من مستويات الإدارة المكشوفة اختبارًا للمساءلة في سيطرة العميل

الملخص

• كشفت F5 عن CVE-2022-1388 في مايو 2022 كثغرة حرجة في iControl REST تؤثر على أنظمة BIG-IP. سرعان ما وصفتها التحليلات العامة بأنها تجاوز للمصادقة يؤدي إلى تنفيذ التعليمات البرمجية عن بعد بصلاحيات عالية.
• أضافت CISA الثغرة CVE-2022-1388 إلى كتالوج الثغرات المستغلة المعروفة وحثت المؤسسات المتضررة على تطبيق التحديثات أو التخفيفات؛ تبع ذلك نشاط استغلال علني وكود إثبات المفهوم بسرعة.
• كانت قضية المساءلة المركزية هي تعرض مستوى الإدارة. غالبًا ما تقع أجهزة BIG-IP بالقرب من حركة مرور التطبيقات المهمة، ولكن المسار القابل للاستغلال شمل وظائف إدارية لا ينبغي أن تكون قابلة للوصول على نطاق واسع من الإنترنت.
• سيطرت F5 على أمن المنتج، ووضوح النشرات، والإصدارات المُصلحة، وإرشادات الحلول البديلة، ووثائق التعزيز. سيطر العملاء على جرد الأصول، والتعرض، وسرعة التصحيح، وقيود الشبكة، ومراجعة ما بعد الاستغلال، وتدوير كلمات المرور والمفاتيح، وما إذا تم إعادة بناء الأجهزة المخترقة.
• يدعم السجل العام نتيجة عالية الثقة بأن مستويات إدارة الأجهزة الطرفية تتطلب معالجة الحوادث بعد الاستغلال. لا يُظهر أن كل BIG-IP ضعيف تم استغلاله أو أن جميع الأنظمة المكشوفة كان لها نفس التأثير التجاري.

ثغرة حرجة في الجهاز تحولت إلى سباق تشغيلي

نشرة F5 لـ K23605346: ثغرة BIG-IP iControl REST CVE-2022-1388 هي المصدر الأساسي للبائع. وقد حددت إصدارات BIG-IP المتأثرة وأخبرت العملاء بالترقية إلى الإصدارات المُصلحة أو تطبيق التخفيفات. سجلت قاعدة البيانات الوطنية للثغرات (NVD) إدخال CVE-2022-1388 على أنها حرجة. وحث تنبيه CISA، F5 Releases Security Advisory for BIG-IP، المستخدمين والمسؤولين بسرعة على تطبيق التحديثات أو الحلول البديلة.

كان التوقيت مهمًا لأن تطوير الاستغلال العام كان سريعًا. وصف استجابة Rapid7 للتهديدات الناشئة emergent threat response الثغرة على أنها تجاوز للمصادقة في iControl REST يسمح بطلبات غير معلنة لتجاوز المصادقة. وشرحت مقالة Horizon3.ai التقنية technical write-up آليات الاستغلال وأظهرت مدى سرعة دخول معرفة إثبات المفهوم إلى مجتمعات المدافعين والمهاجمين. وصاغ تحليل Tenable CVE-2022-1388 analysis المشكلة على أنها قضية تنفيذ تعليمات برمجية عن بعد حرجة مع خطر استغلال نشط.

بالنسبة للمشغلين، كان السباق عمليًا: تحديد كل BIG-IP. تحديد ما إذا كان iControl REST مكشوفًا. التصحيح أو تطبيق الحل البديل. تقييد الوصول الإداري. مراجعة السجلات. البحث عن اختراق. تدوير بيانات الاعتماد. تحديد ما إذا كان يمكن الوثوق بالجهاز أو يحتاج إلى إعادة بناء. هذا أكثر من مجرد تذكرة تغيير. يمكن للجهاز الذي يتحكم في توصيل التطبيقات أن يكون في نقطة مميزة في الشبكة.

أضافت CISA لاحقًا CVE-2022-1388 إلى كتالوج الثغرات المستغلة المعروفة. حول ذلك الثغرة من نشرة بائع إلى إشارة استغلال عامة. كانت للوكالات الفيدرالية المدنية مواعيد نهائية للتصحيح. كان لدى المشغلين الخاصين نفس المخاطر العملية حتى بدون التفويض الفيدرالي.

التعرض لمستوى الإدارة كان سؤال التحكم الأول

المكون القابل للاستغلال كان iControl REST، وهي واجهة إدارة وأتمتة. هذا هو المفصل. لا يحتاج العملاء إلى تعريض واجهات الإدارة على نطاق واسع لتطبيقات تخدم المستخدمين. قد يواجه موازن التحميل أو جهاز توصيل التطبيقات الإنترنت على مستوى حركة المرور، ولكن يجب تقييد مستوى إدارته للشبكات الموثوقة، أو خوادم الوثب، أو شبكات VPN، أو القنوات الإدارية.

إرشادات التخفيف ووثائق التعزيز الخاصة بـ F5 قد أكدت منذ فترة طويلة على تقييد الوصول الإداري. إرشادات الإدارة الآمنة لـ BIG-IP BIG-IP secure management guidance والمواد ذات الصلة لتعزيز المنصة تخبر العملاء بتقييد الوصول الإداري، واستخدام أقل امتياز، وفصل حركة المرور الإدارية. هذه الضوابط ليست تجميلية. إنها تحدد ما إذا كانت ثغرة المنتج تصبح تنفيذ تعليمات برمجية عن بعد قابلة للوصول من الإنترنت.

إذا كانت واجهة إدارة BIG-IP مفتوحة للإنترنت، فإن المساءلة لا تتوقف عند F5. العميل أو مشغل الخدمة المدارة كان يتحكم في التعرض. كانوا يتحكمون في قواعد جدار الحماية، وتكوينات IP الذاتية، وتقسيم شبكة الإدارة، ومسارات الوصول الإداري. عيب البائع خطير؛ مستوى الإدارة المكشوف يجعله قابلاً للوصول.

ومع ذلك، فإن مسؤولية البائع والعميل ليست بديلة. F5 كانت مسؤولة عن الثغرة وعن إرشادات واضحة وسريعة وقابلة للتنفيذ. العملاء كانوا مسؤولين عن تقليل التعرض وتطبيق التحديثات. المهاجمون كانوا مسؤولين عن الاستغلال. يظهر الحادث كيف تتراكم هذه الطبقات بدلاً من الإلغاء.

ملاحظة GreyNoise CVE-2022-1388 observation وتحليل Censys للتعرض على الإنترنت internet exposure analysis أعطى المدافعين إحساسًا بالمسح وخطر التعرض. كانت أسطح الإدارة المواجهة للإنترنت قابلة للقياس من الخارج. هذه الرؤية مفيدة، ولكنها تعني أيضًا أن المهاجمين يمكنهم العثور على أهداف.

اختراق الجذر يغير معيار الاسترداد

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

نشرة البائع وتحليلات الاستغلال العامة أوضحت أن الثغرة كانت شديدة. تقرير Unit 42 threat brief وصف محاولات الاستغلال والنشاط التهديدي. ملاحظات NCC Group التقنية technical notes وأبحاث أخرى أظهرت كيف يمكن تسليح الخلل. بالنسبة للمدافعين، كانت النتيجة ليست فقط جدولة التصحيح؛ بل كانت فرز ما بعد الاستغلال.

قرار الاسترداد النظيف يتطلب أدلة. يجب على المشغلين مراجعة سجلات التدقيق، وسجلات الأوامر حيثما كانت متاحة، وطلبات iControl REST، وتغييرات التكوين، وتغييرات الحسابات، ووصول SSH، والاتصالات الصادرة، ومهام cron، ومؤشرات webshell، وتعديلات الملفات. إذا كان التسجيل غير كافٍ، يصبح قرار الثقة أصعب. قد يحتاج الجهاز المخترق إلى إعادة بناء من صورة نظيفة وأساس تكوين.

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

ضوابط الأمان الحرجة لمعهد الأمن السيبراني (CIS) العامة critical security controls هي سياق مفيد: الجرد، إدارة الثغرات، التكوين الآمن، التحكم في الوصول، إدارة سجلات التدقيق، والاستجابة للحوادث تتداخل هنا. العميل الذي يفتقر إلى جرد الأصول لا يمكنه العثور على أجهزة BIG-IP بسرعة. العميل الذي يفتقر إلى التكوين الآمن قد يعرض الإدارة. العميل الذي يفتقر إلى السجلات لا يمكنه الحكم على الاختراق. العميل الذي يفتقر إلى الاستجابة للحوادث قد يقوم بالتصحيح ولكن يترك آثار المهاجم.

الحلول البديلة هي قرارات مخاطرة

عرضت نشرة F5 إصدارات مُصلحة وتخفيفات. الحلول البديلة ضرورية أحيانًا لأن تصحيح جهاز حركة مرور عالي التوفر قد يكون محفوفًا بالمخاطر. قد يكون BIG-IP أمام تطبيقات حرجة. ترقيته قد تتطلب نوافذ صيانة، واختبار تجاوز الفشل، وفحوص توافق التطبيقات، وخطط التراجع. أثناء الاستغلال النشط، انتظار نافذة تغيير مثالية هو بحد ذاته قرار مخاطرة.

التخفيف أيضًا له نطاق. منع كل الوصول إلى iControl REST من الشبكات غير الموثوقة يمكن أن يقلل الاستغلال عن بعد. تقييد الوصول الإداري إلى عناوين موثوقة يمكن أن يساعد. تعطيل المسارات الضعيفة قد يكون له آثار تشغيلية. كل عميل كان عليه أن يقرر أي إجراء ممكن فورًا وأي إجراء يتطلب تحديثًا مخططًا له.

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

Tenable و Rapid7 أكدا على التصحيح العاجل. هذه المصادر هي بائعي أمان، لكنها تعكس حقيقة تشغيلية واسعة: عندما يكون كود الاستغلال عامًا والواجهة الضعيفة يمكن أن تكون مكشوفة للإنترنت، فإن النافذة الآمنة قصيرة. العميل الذي يتأخر يحتاج إلى سبب موثق وتحكم تعويضي.

الاستغلال العام غير عبء الإثبات

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

تغطية SecurityWeek coverage of active exploitation ذكرت أن الاستغلال بدأ بعد أن أصبح كود إثبات المفهوم عامًا. نظام المسح والتقارير من Shadowserver Foundation scan and report ecosystem زود المدافعين برؤية لأنظمة BIG-IP الضعيفة المكشوفة. تظهر هذه المصادر كيف يمكن أن تصبح ثغرة مستوى الإدارة بسرعة مشكلة قابلة للقياس على مستوى الإنترنت.

بالنسبة لمجالس الإدارة ولجان المخاطر، هذا يخلق سؤالًا بسيطًا: إذا كانت أجهزتنا الطرفية ضعيفة ومكشوفة، هل تعاملنا معها على أنها قد تكون مخترقة؟ إذا كانت الإجابة لا، فلماذا؟ إذا كانت الإجابة نعم، فأين دليل المراجعة والتدوير وإعادة البناء؟

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

هذا هو المكان الذي تقصر فيه بعض المنظمات. يقومون بتصحيح الجهاز ويمضون قدمًا لأنه لم يكن هناك انقطاع مرئي. لكن الجهاز ربما كان نقطة انطلاق. غياب تعطيل الخدمة ليس دليلاً على عدم وجود اختراق.

مزودو الخدمات المدارة كانوا في الوسط

العديد من المنظمات لا تدير أجهزة توصيل التطبيقات بمفردها. مزودو الخدمات المدارة، ومزودو الاستضافة، ومشغلو الخدمات المشتركة في القطاع العام، وفرق الشبكات المؤسسية قد يديرون أجهزة BIG-IP لعملاء داخليين أو خارجيين متعددين. هذا يغير المساءلة لأن فريق تشغيلي واحد قد يتحكم في التعرض للعديد من الخدمات التابعة.

إذا كان مزود الخدمة المدارة يتحكم في الجهاز، فقد لا يعرف العميل النهائي الإصدار، أو التعرض، أو وقت التصحيح، أو مراجعة الاختراق. العميل يعتمد على أدلة المزود. المزود يعتمد على نشرة F5 وجرده الخاص. التأخير أو الجهاز المفقود يمكن أن يؤثر على تطبيقات عملاء متعددة.

لذلك يختبر الحادث وضوح العقد. من يجب أن يصحح؟ من يجب أن يخطر؟ من يجب أن يراجع السجلات؟ من يقرر ما إذا كان يعيد البناء؟ من يدور بيانات الاعتماد المشتركة؟ من يدفع مقابل الصيانة الطارئة؟ من يخبر مالكي التطبيقات إذا كان فحص حركة المرور أو الثقة الطرفية قد تأثر؟ إذا كانت هذه الأدوار غير واضحة قبل مايو 2022، فإن CVE-2022-1388 جعلتها عاجلة.

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

وضوح نشرة F5 كان مهمًا

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

نشرة F5 حددت المنتجات المتأثرة والإصدارات المُصلحة. ملأ الباحثون العامون آليات الاستغلال بسرعة. ضاعفت CISA الإلحاح. المزيج أعطى المدافعين ما يكفي للتحرك. السؤال المتبقي هو ما إذا كان كل عميل قد فهم متطلبات التعرض لمستوى الإدارة وآثار الاستجابة للحوادث.

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

فهرس النشرات الأمنية لـ F5 security advisory index قيم للعملاء الذين يتتبعون نشرات المنتج. يظهر الحادث لماذا يحتاج العملاء أيضًا إلى عملية داخلية تربط النشرات بالأصول. يمكن للبائع النشر بسرعة؛ لا يزال على العميل معرفة أي الأجهزة موجودة.

الحادث كشف مشكلة جرد الأصول

الأجهزة الطرفية غالبًا ما تفلت من جرد الخوادم العادي. قد تكون مملوكة لفرق الشبكات، أو مزودي الخدمات المدارة، أو فرق التطبيقات، أو فرق مراكز البيانات، أو وحدات الأعمال المكتسبة. قد لا تشغل وكلاء نقاط النهاية العاديين. قد لا تظهر في لوحات التحكم المصممة للخوادم وأجهزة الكمبيوتر المحمولة. هذا يجعل الاستجابة للطوارئ أصعب.

CVE-2022-1388 تطلبت جردًا حيًا: كل BIG-IP، والإصدار، والتعرض الإداري، والمالك، وخدمة الأعمال، وحالة التصحيح، وحالة الحل البديل، وموقع السجل. إذا كان على المنظمة اكتشاف ذلك أثناء الطوارئ، فقدت وقتًا. إذا لم تكتشف جميع الأجهزة، بقي الخطر.

ينطبق نفس الدرس على منتجات طرفية أخرى: شبكات VPN، جدران الحماية، أجهزة توصيل التطبيقات (ADC)، وكلاء الهوية، بوابات الويب الآمنة، وأجهزة الوصول عن بعد. غالبًا ما تكون أول شيء يمسحه المهاجمون وآخر شيء تتعامل معه برامج التصحيح العادية بشكل نظيف. مستويات إدارتها تحتاج رؤية منفصلة وقواعد تعرض أكثر صرامة.

أدلة موارد الشبكة يمكن أن تساعد. فحوصات الإنترنت، بيانات Censys، فحوصات التعرض على غرار Shodan، تقارير Shadowserver، وإدارة سطح الهجوم الخارجي يمكن أن تظهر ما هو قابل للوصول. لكن المنظمة يجب أن تربط ذلك المنظر الخارجي بالمالكين الداخليين. الفحص الذي يجد BIG-IP مكشوفًا مفيد فقط إذا كان يمكن لشخص ما تصحيحه أو عزله فورًا.

حوكمة التعرض يجب أن تكون مستمرة، وليست مدفوعة بالنشرات

أسوأ وقت لمعرفة ما إذا كانت واجهات الإدارة مكشوفة هو بعد نشرة حرجة. حوكمة التعرض يجب أن تكون مستمرة. كل منظمة مواجهة للإنترنت يجب أن يكون لديها خريطة حالية لسطح الهجوم الخارجي تحدد شبكات VPN، وأجهزة ADC، وجدران الحماية، وبوابات الهوية، ولوحات الإدارة، وواجهات برمجة التطبيقات الإدارية، وأنظمة الاختبار المنسية. تلك الخريطة لا ينبغي أن تكون لوحة معلومات البائع التي لا يقرأها أحد. يجب أن تغذي الملكية والتصعيد وسلطة التغيير.

بالنسبة لـ BIG-IP، سؤال التعرض محدد. ما هي IPs الذاتية ومنافذ الإدارة القابلة للوصول؟ هل iControl REST قابل للوصول فقط من شبكات إدارية موثوقة؟ هل أقران التوفر العالي مقيدون بنفس القدر؟ هل مجموعات أمان السحابة وجدران حماية مركز البيانات متسقة؟ هل خوادم الوثب محصنة؟ هل مستخدمو الإدارة مرتبطون بهويات فردية بدلاً من بيانات اعتماد مشتركة؟ هل يتم تصدير السجلات خارج الجهاز حتى لا يتمكن الجهاز المخترق من محو أدلته الخاصة؟

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

حادث F5 يظهر لماذا حوكمة التعرض المستمرة أكثر موثوقية من الذعر المدفوع بالنشرات. إذا كان مستوى الإدارة غير مكشوف للإنترنت أبدًا، فإن ثغرة حرجة في مستوى الإدارة لا تزال مهمة ولكن لديها نصف قطر انفجار قابل للوصول أصغر. إذا كان مستوى الإدارة مكشوفًا، كل نشرة حرجة تصبح سباقًا ضد المسح العالمي.

الشهادات والمفاتيح تحول اختراق الجهاز إلى مخاطر نهائية

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

لهذا السبب يحتاج الاسترداد إلى جرد أسرار. ما هي مفاتيح TLS الخاصة التي كانت موجودة؟ هل تم تخزين شهادات العميل؟ هل تم تكوين بيانات اعتماد API للأتمتة؟ هل كانت سلاسل SNMP، أو كلمات مرور المسؤول المحلية، أو بيانات اعتماد ربط LDAP، أو أسرار حسابات الخدمة متاحة؟ هل كانت نسخ التكوين محمية؟ هل كانت التقاطات حركة المرور ممكنة؟ هل كانت المفاتيح قابلة للتصدير؟ الإجابة تحدد التدوير.

المنظمات أحيانًا تتجنب تدوير الشهادات بعد اختراق الجهاز لأن التدوير مؤلم. قد يتطلب تنسيقًا عبر الشهادات العامة، و PKI داخلي، والتطبيقات، ومجموعات التحميل المتوازن، و TLS المتبادل، وأنظمة المراقبة، واتصالات الشركاء. الألم ليس سببًا لتجاهل المخاطرة. إذا كان المهاجمون يمكنهم قراءة مواد المفاتيح، فإن التصحيح لا يجعل المفتاح القديم آمنًا.

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

قرارات إعادة البناء تتطلب معايير مكتوبة مسبقًا

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

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

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

يجب أن يدفع حادث F5 المنظمات لكتابة كتيبات إعادة بناء الأجهزة الطرفية لجميع المنتجات المماثلة. الكتيب يجب أن يقول من يمكنه إعلان الجهاز غير موثوق، ومن يوافق على تجاوز الفشل الطارئ، وأين يتم تخزين الصور النظيفة والتكوينات الذهبية، وكيف يتم تدوير الشهادات، وكيف يتم الحفاظ على السجلات، وكيف يتم إخطار مالكي الأعمال. بدون ذلك الكتيب، "تصحيح الآن" يمكن أن يصبح الإجراء الوحيد حتى عندما لا يكون التصحيح كافيًا.

الإبلاغ عن الحالة يجب أن يشمل التعرض والثقة، وليس فقط حالة التصحيح

لوحة التنفيذ الشائعة بعد ثغرة حرجة تظهر أعدادًا: ضعيف، مُصَحح، مخفف، معلق. بالنسبة لـ CVE-2022-1388، هذه اللوحة غير مكتملة. يجب أن تظهر أيضًا مكشوف، غير مكشوف، ربما مستغل، سجلات مراجعة، أسرار مدورة، إعادة بناء مطلوبة، ومالك الخدمة تم إخطاره.

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

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

التقرير المسؤول بعد هذا الحادث يجب أن يتضمن مصفوفة، وليس نسبة مئوية واحدة. كم جهاز تأثر؟ كم كان مكشوفًا للإنترنت؟ كم كان لديه دليل على الاستغلال؟ كم أعيد بناؤه؟ كم سرًا تم تدويره؟ كم بقي على حل بديل؟ كم كان يفتقر إلى سجلات كافية؟ تلك المصفوفة تحول استجابة الثغرة إلى سجل حادث.

الهيئات العامة كان عليها واجب أعلى للتوثيق

عندما تدير الهيئات العامة أو مشغلو الخدمات الحرجة أجهزة طرفية مكشوفة، معيار المساءلة أعلى لأن المواطنين لا يمكنهم اختيار البنية التحتية. كتالوج KEV التابع لـ CISA جعل CVE-2022-1388 قضية تصحيح فيدرالية صريحة. الوكالات الخاضعة للتوجيهات التشغيلية الملزمة كان لها مواعيد نهائية. لكن المواعيد النهائية ليست كل الواجب.

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

هذا لا يعني نشر كل تفصيل. يعني الحفاظ على أدلة التدقيق وتزويد هيئات الرقابة المناسبة بمعلومات كافية. ما هي الأنظمة التي تأثرت؟ هل كانت البيانات الحساسة قابلة للوصول؟ هل تم تدوير المفاتيح؟ هل عانت أي خدمة من توقف؟ هل أبلغت الوكالة الفرق التابعة؟ هل كان البائعون ومزودو الخدمات المدارة مستجيبين؟

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

اتصال العميل إلى أسفل الجهاز كان غالبًا غير مرئي

جزء غير مدروس من حوادث الأجهزة الطرفية هو الاتصال بمالكي التطبيقات. فريق الشبكات قد يصحح BIG-IP. مالك التطبيق قد لا يعلم أبدًا أن الجهاز أمام خدمته كان يحتمل أن يكون مخترقًا. إذا أظهرت السجلات لاحقًا نشاطًا مشبوهًا، قد لا يكون فريق التطبيق مستعدًا لمراجعة السجلات الخلفية، أو تدوير أسرار التطبيق، أو إخطار المستخدمين.

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

مزودو الخدمات المدارة يواجهون نفس مشكلة الاتصال. إذا كان المزود يدير BIG-IP لعملاء متعددين، قد يتردد في إخطار كل عميل بثغرة إذا كان يعتقد أنه لم يحدث اختراق. ولكن إذا كان التعرض موجودًا والسجلات غير كاملة، قد يحتاج العملاء إلى معرفة أن الثقة لا يمكن إثباتها بالكامل. لغة العقد يجب أن تحدد هذه العتبة قبل الطوارئ.

المبدأ المسؤول بسيط: الطرف الذي يتحكم في الجهاز يدين لمالكي الخدمات التابعة بأدلة كافية لاتخاذ قرار المخاطرة الخاص بهم. الصمت قد يقلل الذعر، لكنه يمكن أن يمنع أيضًا مراجعة التابعة الضرورية.

إصلاح أمن المنتج يجب أن يشمل الإعدادات الافتراضية الآمنة

مسؤولية منتج F5 لم تنته بإصدار مُصلح. ثغرات حرجة في مستوى الإدارة يجب أن تدفع البائعين لفحص الإعدادات الافتراضية الآمنة، وحدود المصادقة، وتغطية الاختبار، وإرشادات التعزيز، وبيانات العملاء عن بعد. إذا كان العديد من العملاء يعرضون واجهات الإدارة، يجب أن يسأل البائع لماذا. هل المنتج سهل النشر بشكل غير آمن؟ هل التحذيرات ضعيفة جدًا؟ هل البنى الآمنة صعبة؟ هل واجهات برمجة التطبيقات مفرطة الصلاحيات؟ هل فصل مستوى الإدارة غير ملائم؟

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

هذا مهم لأن بائعي الأجهزة غالبًا ما يخدمون عملاء بنضج متفاوت. مشغل واسع النطاق قد يكون لديه فرق مخصصة ومختبرات اختبار. مستشفى أو حكومة محلية قد يكون لديه مهندس شبكة واحد ومزود خدمة مدارة. تصميم المنتج يجب أن يأخذ في الاعتبار هذا الواقع. النشرات المكتوبة فقط للمشغلين النخبة تترك العملاء الأضعف مكشوفين.

الحوافز الاقتصادية تفسر لماذا تبقى مستويات الإدارة مكشوفة

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

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

حادث F5 ليس درسًا لبائع واحد. إنه درس حول اقتصاديات الوصول الإداري. المنظمات تقبل مكاسب راحة صغيرة تخلق مخاطر ذيل كبيرة. تلاحظ عدم التوازن فقط عندما تظهر ثغرة حرجة ويبدأ الاستغلال عالميًا.

ما الأدلة التي من شأنها تغيير الاستنتاج

الاستنتاج سيتغير بأدلة خاصة بالمنظمة. إذا كان بإمكان العميل إظهار أن واجهة إدارة BIG-IP الخاصة به لم تكن أبدًا قابلة للوصول من شبكات غير موثوقة، وتم التصحيح على الفور، وكانت لديه سجلات كافية تظهر عدم وجود نشاط مشبوه، يجب أن تكون خطورة حادثه أقل. إذا كان العميل لديه إدارة مكشوفة، وتصحيح متأخر، وسجلات مفقودة، وأسرار مخزنة، يجب أن تكون الخطورة أعلى حتى بدون انقطاع عام.

أدلة خاصة بـ F5 يمكن أن تغير أيضًا تقييم البائع. سجل عام مفصل للسبب الجذري وتحسين الإعدادات الافتراضية الآمنة سيعزز الثقة في أن الدروس على مستوى المنتج تم استيعابها. مشاكل متكررة في مستوى الإدارة بدون إعدادات افتراضية أقوى ستضعف تلك الثقة. سجل CVE العام وحده لا يمكنه الإجابة عن سؤال المنتج طويل الأجل.

الأدلة المتاحة الآن تدعم نتيجة واضحة لكن محدودة: CVE-2022-1388 جعلت تعرض مستوى إدارة BIG-IP اختبارًا عمليًا للمساءلة. عيب المنتج كان من F5. الواجهة المكشوفة، وتسلسل التصحيح، والمراجعة الجنائية، وقرار إعادة البناء كان لكل مشغل.

حوادث الأجهزة تحتاج حزمة أدلة

الناتج العملي بعد طوارئ BIG-IP يجب أن يكون حزمة أدلة، وليس فقط تذكرة مغلقة. الحزمة يجب أن تحدد كل جهاز، والإصدار، وحالة التعرض، ووقت التصحيح أو الحل البديل، والسجلات المراجعة، والنشاط المشبوه الموجود أو غير الموجود، والأسرار المدورة، وقرار إعادة البناء، ومالكي الخدمات الذين تم إخطارهم، والمخاطر المتبقية المقبولة. تلك الحزمة تسمح للمدققين اللاحقين ومالكي التطبيقات بفهم ما حدث بالفعل.

حزم الأدلة أيضًا تقلل النسيان المؤسسي. ثغرة جهاز طرفي حرجة قد تشعر بالإلحاح لأسبوعين ثم تختفي من جدول التنفيذ. بعد ستة أشهر، قد لا تزال نفس المنظمة لديها قواعد جدار حماية مؤقتة، ومفاتيح غير مدورة، واستثناءات غير موثقة، أو أجهزة خارج الجرد. حزمة أدلة منظمة تجعل المتابعة مرئية.

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

F5 وبائعو الأجهزة الآخرون يمكنهم دعم ذلك بنشر قوائم مراجعة الاستجابة للحوادث مع نشراتهم. العملاء لا ينبغي أن يضطروا لتجميع خطوات مراجعة ما بعد الاستغلال من نشرات البائع، وتنبيهات CISA، ومدونات الطرف الثالث. لثغرات RCE الحرجة على واجهات الإدارة، يمكن للنشرة أن تشير مباشرة إلى السجلات والمؤشرات وأنواع بيانات الاعتماد ومعايير إعادة البناء وأوامر التحقق الآمنة.

مقارنة الحادث بحملات الأجهزة الطرفية اللاحقة يشحذ الدرس

CVE-2022-1388 كانت جزءًا من نمط أوسع عبر البنية التحتية الطرفية. المهاجمون يستهدفون بشكل متكرر شبكات VPN، وجدران الحماية، وأجهزة توصيل التطبيقات (ADC)، وبوابات الوصول عن بعد، وأجهزة الهوية لأن هذه الأنظمة مكشوفة، ومتميزة، ومراقبة بشكل غير متساوٍ. الحملات اللاحقة ضد بائعين آخرين كررت نفس أسئلة التحكم: هل كان مستوى الإدارة مكشوفًا، هل تمت سرقة الجلسات أو الرموز، هل قام العملاء بالتصحيح بسرعة كافية، هل تطلبت الأجهزة إعادة بناء، وهل كانت السجلات موجودة خارج الجهاز؟

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

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

منظمة ناضجة ستغلق الدورة في أربعة آفاق زمنية

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

المنظمات غالبًا ما تكمل الأفق الأول وتفقد الزخم قبل الرابع. هكذا تعود نفس فئة الفشل. ثغرة جهاز طرفي يجب أن تترك خلفها جردًا أقوى، ليس فقط جهازًا مُصَححًا. يجب أن تترك تقسيم شبكة أقوى، ليس فقط تذكرة تغيير مغلقة. يجب أن تترك خرائط مالك أوضح وشروط عقد، ليس فقط نشرة أمنية.

حدث F5 مفيد لأنه يعطي اختبارًا ملموسًا يمكن إعادة تشغيله. اسأل اليوم: إذا ظهرت ثغرة حرجة جديدة في مستوى إدارة BIG-IP، هل يمكن للمنظمة تحديد كل جهاز في ساعة واحدة؟ هل يمكنها تحديد التعرض للإنترنت في ساعة واحدة؟ هل يمكنها التصحيح أو العزل في يوم واحد؟ هل يمكنها معرفة ما إذا كان الجهاز قد تم استغلاله؟ هل يمكنها تدوير الأسرار المخزنة؟ هل يمكنها إخبار مالكي التطبيقات بما حدث؟ إذا كانت الإجابة لا، فإن درس 2022 غير مكتمل.

براءة العميل لا تزيل مسؤولية العميل

من العدل أن نقول إن العملاء لم ينشئوا CVE-2022-1388. من العدل أيضًا أن نقول إنهم سيطروا على ظروف مخاطرة مهمة. العميل الذي عرض واجهات الإدارة، وافتقر إلى الجرد، وأخر التصحيح دون ضوابط تعويضية، أو فشل في مراجعة الاختراق، كان لديه مسؤولية عملية تجاه بيئته. التمييز مهم لأنه وإلا فإن كل ثغرة جهاز تصبح مجرد قصة بائع ولا يتعلم أي مشغل.

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

بالنسبة لـ F5 BIG-IP، هذه الطبقات مرئية بشكل غير عادي: عيب المنتج، تعرض مستوى الإدارة، سباق التصحيح، توفر الاستغلال، الثقة بعد الاستغلال، واتصال العميل. كل طبقة كان لها مالك مختلف. الاستجابة الناضجة تسميها جميعًا.

يجب أن يتم هذا التسمية مسبقًا. يجب أن يعرف مالك التطبيق من يملك جهاز توصيل التطبيقات. يجب أن يعرف مالك الشبكة من يوافق على العزل الطارئ. يجب أن يعرف مالك الأمان أين يتم الاحتفاظ بالسجلات. يجب أن يعرف مزود الخدمة المدارة ما هي الأدلة التي يتوقعها العميل. بدون هذه التعيينات، سيتحول عيب مستوى الإدارة التالي مرة أخرى إلى سباق بين سرعة الاستغلال والارتباك التنظيمي.

اختبار المساءلة

يجب الحكم على حادث F5 BIG-IP من خلال ستة ضوابط.

أولاً، التعرض: هل كان iControl REST قابلاً للوصول من شبكات غير موثوقة؟ إذا كان الأمر كذلك، فإن العميل أو المشغل المدار كان لديه فشل في التحكم في التعرض مستقل عن عيب البائع.

ثانيًا، سرعة التصحيح والتخفيف: ما مدى سرعة تثبيت الإصدارات المُصلحة أو تطبيق التخفيفات بعد نشرة F5 في مايو 2022 وتنبيه CISA؟

ثالثًا، مراجعة ما بعد الاستغلال: إذا كان الجهاز مكشوفًا قبل التصحيح، هل بحث المشغل عن اختراق، وتنفيذ أوامر، واستمرارية، وتغييرات حسابات، ووصول إلى البيانات؟

رابعًا، تدوير بيانات الاعتماد: هل قام المشغل بتدوير الأسرار المخزنة على الجهاز أو القابلة للوصول منه إذا لم يمكن استبعاد الاختراق؟

خامسًا، قرار إعادة البناء: هل حدد المشغل متى لم يعد الجهاز المُصَحح جديرًا بالثقة ويتطلب إعادة بناء نظيفة؟

سادسًا، اتصال البائع والعميل: هل قدمت F5 إرشادات قابلة للتنفيذ وهل أبلغ العملاء أو مزودي الخدمات المدارة مالكي التطبيقات المعتمدين بسرعة كافية؟

النتيجة النهائية مقيدة. أصدرت F5 ثغرة حرجة في واجهة إدارية. تبع الاستغلال العام بسرعة. العملاء الذين لديهم مستويات إدارة مكشوفة كان لديهم سيطرة عملية على ما إذا كان هذا العيب يصبح قابلاً للوصول من الإنترنت. بمجرد أن أصبح الاستغلال عامًا، كان على الاستجابة أن تكون أكثر من مجرد تصحيح: كان عليها أن تشمل مراجعة التعرض، والفرز الجنائي، وتدوير بيانات الاعتماد، وقرارات إعادة البناء حيث كانت الثقة غير مؤكدة. BIG-IP يقف على حافة التطبيقات المهمة. يجب معاملة مستوى إدارته كسطح تحكم عالي القيمة، وليس كراحة إدارية.