في وقت متأخر من ليل الأحد 8 نوفمبر، نشر الباحث الأمني شون بيلز مستودعًا على GitHub باسم Able2Shell. كان بداخله أدلة استغلال لأكثر من ثلاثين ثغرة يوم-صفر مزعومة في N-central، منصة المراقبة والإدارة عن بعد (RMM) التي يستخدمها مزوّدو الخدمات المُدارة وفرق تقنية المعلومات لتشغيل حواسيب وخوادم وشبكات الآخرين.
وبعد ظهر الاثنين، كانت N-able قد أوقفت بيئات N-central المستضافة في الأميركتين وأوروبا وآسيا والمحيط الهادئ، وطلبت من عملاء النسخ المحلي إطفاء خوادمهم «حتى إشعار آخر». مورّد لديه آلاف الشركاء ومئات الآلاف من نقاط النهاية تحمّل التوقف بدلًا من الانكشاف.
هذا ليس اثنين عاديًا. هذا باب رئيسي يُقتحم بينما صانع الأقفال ما زال يقرأ الدليل.
ما الذي نُشر تحديدًا
يستهدف المستودع إصدار N-central Appliance 2026.4.0.31، وهو بناء ما قبل الإطلاق، ويرى بيلز أن معظم الثغرات إن لم تكن كلها تمتد إلى إصدارات أقدم. الفئات وحدها تكشف العمق:
- تجاوز المصادقة
- كشف بيانات الاعتماد
- كتابة ملفات عشوائية واختراق المسارات
- هجمات XSS تُنفَّذ بصلاحية root عندما يفتح المدير بيانات تعريف تحديث خبيثة
- حقن XXE
- تنفيذ شيفرة عن بعد (RCE)
- تصعيد امتيازات محلي ينقل شيفرة حساب الخدمة
nableإلى root
الأسوأ هو سلسلة كاملة. ثغرة XXE بلا مصادقة في وظيفة استيراد الخدمات تتيح سرقة جلسة محلية موثوقة، وإعادة تعيين كلمة مرور حساب، وتنفيذ أوامر على الخادم باسم nable. السلسلة نفسها تستطيع إنشاء حساب Default Administrator مُفعّل ببيانات يعرفها المهاجم، أي أن غريبًا أصبح يملك الواجهة التي تدير أسطولك. نشر بيلز فيديو للهجوم كاملًا، مع مخرجات الطرفية: الحساب أُنشئ، تسجيل الدخول نجح، وصل إلى وظائف الإدارة، والأوامر تُنفَّذ.
تقول N-able إنها لم ترصد استغلالًا فعليًا ولا وصولًا غير مصرّح به للبيانات، وإن تحديثًا عاجلًا قيد التطوير والتحقق، مع تعهّد بتحديثات كل أربع ساعات. بقيت خدمات Ecoverse خلف N-able Login تعمل، أما الباقي فأُغلق.
ثمة تفصيل يستحق التوقف عنده: أكد بيلز لموقع BleepingComputer أن الاكتشاف كان مدعومًا بالذكاء الاصطناعي. أكثر من ثلاثين ثغرة في جهاز مؤسسي، خلال دورة بحث واحدة. هذا هو المعيار الجديد للسرعة.
لماذا فعلها، ولماذا يهمنا ذلك أكثر من الثغرات
هذه ليست حكاية قديس وشرير، وقراءتها بهذا الشكل لن تعلّمك شيئًا.
يقول بيلز إنه تجاوز الإفصاح المنسّق عن قصد. سببه: أنه كان قد أبلغ قبل نحو خمسة أو ستة أشهر عن ثغرتي تنفيذ شيفرة عن بعد في منتج آخر من N-able، مع ثغرة تصعيد امتيازات، وإنها ما زالت بلا تحديث. ويقول إنه أرسل متابعات على مدى أربعة إلى ستة أسابيع دون رد، وإنه لم يُدفع له عبر برنامج المكافآت. وبعد النشر، تواصل معه الرئيس التنفيذي والمدير التقني لـ N-able وطلبا منه سحب المستودع والتعاون، دون تهديد.
ولم تجب N-able عن أسئلة BleepingComputer بشأن تلك البلاغات السابقة.
فهل هو باحث متهور يُلقي ثغرات حيّة يوم الاثنين، أم مسار إفصاح معطّل لدرجة أن النشر كان الرافعة الوحيدة؟ الاحتمالان صحيحان معًا. والدرس المزعج لمن يشتري برمجيات مؤسسية هو أن الضغط الوحيد الذي حرّك هذا المورّد فعلًا كان الفضيحة العلنية مضافًا إليها انقطاع عالمي.
وهناك كلفة حقيقية. هذا الأسبوع، فني في مزوّد خدمة مُدارة لدى عيادة من 40 موظفًا يحاول إغلاق التذاكر بلا واجهة. التوقف ليس مفهومًا مجردًا. نشر ثلاثين ثغرة بلا تحديث يعرّض مستخدمين عاديين للخطر، وأداة الـ RMM هذه تعتمد عليها مستشفيات صغيرة ومدارس.
مشكلة الـ RMM التي لا أحد يريد طباعتها على شريحة عرض
الـ RMM بحكم التصميم هو أكثر برنامج متمتع بالامتيازات في المؤسسة: وكيل على كل نقطة نهاية، وبيانات اعتماد لكل بيئة عميل، ووصول إلى صدفة عن بعد، ونشر تحديثات، وتنفيذ سكربتات. نموذج العمل «واجهة واحدة، مئات المؤسسات». ونموذج الأمان غالبًا «ثِق بنا».
ولهذا فهو هدف يطبع المال:
- تسجيل دخول واحد، مئات المستأجرين. من يخترق الـ RMM يرث كل علاقات العملاء خلفه.
- تنفيذ عن بعد جاهز. لا حاجة للبحث عن حركة جانبية، المنتج يقدّمها كميزة.
- وكلاء موقّعون في كل مكان. حماية نقاط النهاية تمرّر الترافيك لأنه يأتي من منصتك الإدارية.
- تحديثات متأخرة. الجهاز يبقى جهازًا. لا أحد يحدّثه ليل الثلاثاء كما يفعل بخادم ويب.
ما يجب فعله خلال 72 ساعة
- الجرد أولًا. ما نسخ N-central التي تملكها أو ترثها عبر شريك، وما نقاط النهاية التي ما زال وكيلها مسجلًا؟ لا يمكنك إطفاء ما لا تجده.
- العزل. البيئات المستضافة متوقفة أصلًا. وفي النسخ المحلي: أطفئ كما طُلب، أو إن تعذّر، حصر الوصول الوارد في عناوين الإدارة المعروفة وأنهِ الانكشاف الخارجي فورًا.
- اعتبر بيانات الاعتماد في N-central محروقة. دوّر كل ما خزّنته المنصة: بيانات نشر الوكلاء، وحسابات الخدمة، ورموز الـ API، واتصالات Microsoft 365 وGoogle Workspace المفوّضة، وسلاسل SNMP، وبيانات النسخ الاحتياطي.
- ابحث عن آثار السلسلة. مديرون محليون جدد، وحساب Default Administrator مفعّل، واتصالات صادرة من المستخدم
nable، وإعادة تعيين كلمات مرور غير متوقعة، ونداءات استيراد خدمات لم تُنفّذها. - افحص EDR بحثًا عن عمليات فرعية تحت وكيل الـ RMM. أي صدفة أو أداة أرشفة تُطلق من ذلك الأصل تستحق نظرة هذا الأسبوع لا الربع القادم.
- اختبر مسار الاستعادة قبل أن تحتاجه. التحديث العاجل قادم، وخطة التراجع لا يمكن أن تكون «سنتدبر الأمر».
- اكتب اتفاقية الإفصاح التي تتوقعها. ثم اطلب من كل مورّد RMM أن يعلن اتفاقيته كتابيًا، مع شروط المكافآت ومدد الاستجابة.
زاوية الخليج
بالنسبة لعملاء دبي والخليج، الأمر يقع في نقطة محددة. تقنية المعلومات المُفوّضة هي الأصل لشريحة واسعة من شركات السوق المتوسط هنا، وكثير منها يعمل عبر هذه الفئة بالذات. وإن كنت جهة منظّمة، فإن تأخر التحديث لدى مورّدك صار مخاطرة رقابية لا حاشية تشغيلية. والجهات الرقابية تسأل السؤال نفسه: من يستطيع تنفيذ شيفرة في بيئتك، وكيف تعرف ذلك؟
الإجابة الصادقة في معظم الشركات هي: «مزوّد خدمتنا المُدارة، عبر واجهة لم ندققها يومًا». وهذه الإجابة تحتاج تحديثًا قبل الحادث القادم، لا بعده.
الخلاصة
ستعود N-central للعمل، على الأرجح خلال أيام. سيصدر تحديث عاجل، وسيُحدّث الشركاء، وستنتقل الأخبار إلى شيء آخر.
الدرس الذي سيبقى أصغر وأقسى: حدّ ثقتك هو قائمة صلاحيات مورّدين، وهذه القائمة أطول من هيكلك التنظيمي. انقطاع RMM يزعجك يومًا واحدًا. اختراق RMM يعني كل عميل لديك، في تبويب متصفح واحد عند مهاجم.