يُبلغ المسؤولون الذين يشغّلون NetScaler كبوابة VPN ووصول عن بُعد عن أمر مقلق: أجهزة تُعيد التشغيل تلقائياً، وبأعداد كبيرة. وفقاً لموقع heise online، يقول باحثو الأمن والمسؤولون إن الأجهزة المتأثرة كانت على أحدث مستوى تحديث. ويربط التقرير هذا السلوك بثغرة zero-day يمكن أن تسبب أعطالاً وتنفيذاً للتعليمات. تتناول هذه المقالة ما تم الإبلاغ عنه، ولماذا تهمّ هذه الفئة من أعطال NetScaler من نوع zero-day وتنفيذ التعليمات البنية التحتية للوصول عن بُعد، وما يمكن للفرق فعله الآن.
ما يراه المسؤولون: عمليات إعادة تشغيل على أجهزة NetScaler محدّثة بالكامل
التفصيل الجوهري في تقرير heise بسيط. الأجهزة تُعيد التشغيل من تلقاء نفسها، وكثير منها في آنٍ واحد، والأنظمة المتأثرة لم تكن تشغّل برمجيات قديمة. كانت محدّثة.
هذه النقطة الأخيرة هي ما يجعل الأمر جديراً بالملاحظة. معظم نصائح الثغرات تختصر في "طبّق أحدث تحديث". عندما تظل الأجهزة على أحدث مستوى تحديث تتعطل، فإن هذه النصيحة لم تعد كافية بحد ذاتها. وهذا لا يعني أن التحديث بلا جدوى. بل يعني أن التحديث طبقة واحدة، وتحتاج الفرق إلى طبقات أخرى بينما تتطور الأوضاع.
هناك أمور قليلة يجدر ذكرها بوضوح، لأن التفاصيل العلنية محدودة:
- يصف المصدر تقارير من باحثين ومسؤولين، وليس تحليلاً كاملاً للسبب الجذري من الجهة المصنّعة.
- عمليات إعادة التشغيل التلقائية عرض. وهي تشير إلى فشل عملية ما، لكن مجرد إعادة التشغيل لا يثبت أن الجهاز قد تم اختراقه.
- ليس واضحاً بعد من ملخص heise بالضبط كيف ترتبط هذه النشاطات بالثغرات المُفصح عنها سابقاً، لذا تعامل مع أي استنتاجات قاطعة بحذر.
لماذا تهمّ ثغرة NetScaler من نوع zero-day المسببة للأعطال وتنفيذ التعليمات بوابات VPN
غالباً ما تنبع الأعطال وتنفيذ التعليمات من المشكلة الجذرية نفسها. يصف التحليل العلني لثغرات NetScaler الأخيرة، بما في ذلك موجز التهديدات Unit 42 من Palo Alto Networks، حزمة خبيثة تسبب تلفاً في الذاكرة أو عطلاً، مما قد يؤدي إما إلى تنفيذ التعليمات أو حجب الخدمة. بعبارة أخرى، قد يتمكن المهاجم الذي لا يستطيع تشغيل التعليمات بشكل موثوق من إسقاط الجهاز رغم ذلك، وقد يترك من يستطيع تشغيل التعليمات أعطالاً خلفه كأثر جانبي لمحاولات غير موثوقة.
لهذا تستحق عمليات إعادة التشغيل غير المبررة الاهتمام بدلاً من التغاضي عنها. تقع البوابة على حافة الشبكة، وتنهي اتصالات المستخدمين عن بُعد، وغالباً ما تكون قابلة للوصول من الإنترنت بحكم التصميم. إذا تم الاستيلاء عليها، فقد يحصل المهاجم على موطئ قدم قريب من بيانات الاعتماد وبيانات الجلسات والموارد الداخلية. وإذا تعطلت فحسب، يفقد العاملون عن بُعد الوصول ويشعر العمل بذلك فوراً.
هناك أيضاً مشكلة كشف عملية. عادةً ما تتمتع أجهزة الحافة بمراقبة نقاط النهاية أقل من الحواسيب المحمولة أو الخوادم، لذا قد تكون إعادة التشغيل هي العلامة الوحيدة المرئية على وجود خطب ما.
كيف يتناسب هذا مع حملة NetScaler الأوسع من نوع zero-day
يأتي هذا التقرير في خضم سلسلة أخبار خطيرة بالفعل عن NetScaler. لقد تناولنا كيف تُستغل ثغرتان في NetScaler من نوع zero-day، هما CVE-2026-88771 وCVE-2026-88772، على مستوى العالم، وكيف كان المهاجمون يسلسلون ثغرات تنفيذ تعليمات عن بُعد غير المرقّعة ضد بوابات VPN. وقد حذّرت شركة الأبحاث watchTowr في وقت سابق من استغلال نشط لثغرات NetScaler من نوع zero-day قبل توقع الإصلاحات.
كما أشار تقرير من Help Net Security إلى أن مجموعة يُشتبه في أنها مدعومة من دولة استغلت CVE-2026-88772 لأسابيع، بدءاً من أوائل سبتمبر. وتشير كتابات علنية أخرى إلى أن CVE-2026-88772 تتضمن حالة تجاوز في الذاكرة وتتطلب تمكين DTLS.
ما إذا كانت عمليات إعادة التشغيل الواردة في تقرير heise وجهاً جديداً لتلك الثغرات نفسها أو شيئاً منفصلاً هو السؤال الذي ينبغي للمسؤولين مواصلة طرحه. الافتراض الأكثر أماناً هو أن الوضع لا يزال يتطور، وأن كون الجهاز على أحدث مستوى تحديث ليس ضماناً للسلامة.
ما يمكن لمسؤولي الشبكات فعله بينما الصورة غير واضحة
لا شيء مما يلي يحل محل إصلاح من الجهة المصنّعة، لكن كل خطوة تقلل المخاطر أو تحسّن الرؤية:
- راقب تنبيهات الجهة المصنّعة عن كثب. تحقق من نشرات الأمن الخاصة بـ Citrix وNetScaler وتنبيهات CISA بشكل متكرر، وكن مستعداً لتطبيق التوجيهات الجديدة بسرعة، بما في ذلك أي إصلاحات محدّثة للإصدارات الحالية.
- تتبّع عمليات إعادة التشغيل غير المتوقعة. استخرج سجل وقت التشغيل وإعادة التشغيل من أجهزتك. يجب تصعيد مجموعات عمليات إعادة التشغيل غير المخطط لها، خاصة عبر عدة أجهزة، بدلاً من اعتبارها مجرد عدم استقرار.
- راجع سجلات البوابة. ابحث عن حركة مرور واردة غير عادية، وأنماط اتصال غريبة، ونشاط إداري غير مألوف حول وقت أي إعادة تشغيل. احفظ السجلات ومخلفات الأعطال قبل إعادة تشغيل الأجهزة أو إعادة بنائها حيثما أمكن.
- قلّل التعرّض. إذا لم تكن هناك حاجة لميزة ما، ففكّر في تعطيلها. على سبيل المثال، تشير التحليلات العلنية إلى أن DTLS شرط مسبق لإحدى الثغرات، لذا تأكد مما إذا كنت تستخدمه فعلاً.
- قيّد وصول الإدارة. أبقِ واجهات الإدارة بعيدة عن الإنترنت العام واقصرها على الشبكات الموثوقة.
- خطّط للاختراق. إذا وجدت علامات على تلاعب، فتعامل مع الجهاز على أنه غير موثوق، وبدّل بيانات الاعتماد والأسرار التي مرّت عبره، وراجع أين كان يمكن للمهاجم أن يتحرك بعد ذلك.
ماذا يعني هذا لك
إذا كنت تدير أجهزة NetScaler، فهذه لحظة مناسبة لفحص سجل إعادة التشغيل والسجلات، وليس حالة التحديث فقط. إعادة تشغيل هادئة وغير مبررة تستحق تذكرة تحقيق.
إذا كنت موظفاً أو عميلاً يتصل عبر VPN الخاصة بالشركة، فهناك القليل مما يمكنك فعله مباشرة. ومع ذلك، من المعقول اتباع توجيهات مؤسستك، واستخدام كلمات مرور فريدة، وتمكين المصادقة متعددة العوامل حيثما توفرت، والإبلاغ عن أي مطالبات تسجيل دخول غير متوقعة أو مشكلات في الجلسات إلى فريق تقنية المعلومات لديك.
بالنسبة لأي شخص يختار أو يقيّم إعدادات الوصول عن بُعد، فالدرس أوسع: بوابات مواجهة للإنترنت أهداف عالية القيمة، والدفاع متعدد الطبقات (التقسيم، والتسجيل، وقواعد الوصول الصارمة) لا يقل أهمية عن سرعة الترقيع.
النقاط الرئيسية
تُظهر التقارير عن عمليات إعادة تشغيل جماعية على أجهزة محدّثة بالكامل لماذا لم تنتهِ بعد قصة أعطال NetScaler من نوع zero-day وتنفيذ التعليمات. راقب التنبيهات الرسمية، ودقّق في سجلات بوابتك بحثاً عن علامات اختراق، وقلّل التعرّض غير الضروري. للاطلاع على الجداول الزمنية للاستغلال ونظرة أعمق على مخاطر بوابات VPN، راجع تغطيتنا لكيفية استهداف الثغرات من نوع zero-day للمؤسسات الحكومية والمالية، وعاود الزيارة مع ظهور مزيد من التفاصيل.
