جعل 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 وأخبرت العملاء بالترقية إلى الإصدارات الثابتة أو تطبيق التخفيفات. إدخال قاعدة بيانات الثغرات الوطنية لـCVE-2022-1388سجل الثغرة كحرجة. تنبيه CISA،إصدار F5 لاستشارة أمنية بشأن BIG-IP، حث المستخدمين والمسؤولين بسرعة على تطبيق التحديثات أو الحلول البديلة.

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

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

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

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

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

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

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

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

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

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

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

أوضحت استشارة البائع وتحليلات الاستغلال العامة أن الثغرة كانت شديدة. وصف موجز التهديد من Unit 42 لـCVE-2022-1388محاولات الاستغلال ونشاط التهديد. وأظهرتالملاحظات التقنيةلـ NCC Group وأبحاث أخرى كيف يمكن تحويل الثغرة إلى سلاح. بالنسبة للمدافعين، لم تكن النتيجة مجرد جدولة التصحيح؛ بل كانت فرز ما بعد الاستغلال.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جلس مزودو الخدمات المدارة في المنتصف

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عندما تشغل الوكالات العامة أو مشغلو الخدمات الحيوية أجهزة حافة مكشوفة، يكون معيار المساءلة أعلى لأن المواطنين لا يمكنهم اختيار البنية التحتية. جعل كتالوج 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 ومدونات الأطراف الثالثة. بالنسبة للاستغلال عن بُعد الحرج على واجهات الإدارة، يمكن أن تشير الاستشارة مباشرة إلى السجلات والمؤشرات وأنواع بيانات الاعتماد ومعايير إعادة البناء وأوامر التحقق الآمنة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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