اختطاف تحديثات Softaculous يكشف ثغرات أمنية خطيرة
تعرف كيف استغل قراصنة اختطاف نطاقات IP لشبكة Softaculous لنشر برمجيات خبيثة عبر تحديثات مزيفة بسبب ثغرات في بروتوكول التوجيه ونقص التوقيع الرقمي وشهادات TLS مزورة في هجوم كشف هشاشة بنية الإنترنت. وورلد برس عربي

حين يصبح التحديث التلقائي سلاحاً: كيف اختطف قراصنة شبكة Softaculous لنشر برمجيات خبيثة؟
تخيّل أنّك تُثبّت تحديثاً لبرنامجٍ تثق به تماماً، من خادمٍ تعرف عنوانه، عبر اتصالٍ يبدو آمناً ثم تكتشف لاحقاً أنّ ذلك التحديث لم يأتِ من المصدر الأصلي قط. هذا بالضبط ما حدث مع عملاء Softaculous خلال عطلة نهاية أسبوع واحدة، في هجومٍ كشف عن ثغراتٍ متراكمة في بنية الإنترنت التحتية ذاتها.
ماذا حدث بالضبط؟
قُبيل الساعة التاسعة مساءً بتوقيت UTC يوم الجمعة، بدأ مهاجمون مجهولو الهوية باختطاف نطاق عناوين IP المُخصَّص لشركة Softaculous وهي شركة إماراتية تُطوّر منصّة تثبيت البرمجيات الشهيرة وبيئة إدارة الخوادم الافتراضية Virtualizor. النطاق المُختطَف هو 162.55.80.0/24، وهو كتلة تحتوي على 256 عنوان IP تستخدمها الشركة لخدمات التحديث ومواقع العملاء.
الآلية التقنية للهجوم تعتمد على بروتوكول BGP وهو بروتوكول التوجيه الذي يُنظّم حركة البيانات بين الشبكات المستقلة (Autonomous Systems) على الإنترنت. يعمل BGP على مبدأ الثقة: حين تُعلن شبكةٌ ما عن امتلاكها نطاقاً من عناوين IP، تقبل الشبكات الأخرى هذا الإعلان دون تحقّق مستقل في الغالب. المهاجمون استغلّوا هذه الثقة العمياء بذكاء.
أعلن المهاجمون عن النطاق /24 الأصغر بدلاً من النطاق الشرعي /16 الذي يحتوي على أكثر من 65,000 عنوان. والسبب في نجاح هذه الحيلة تقني بحت: أجهزة التوجيه (الراوترات) تُفضّل دائماً النطاق الأكثر تحديداً (longest-prefix-match)، فأيّ حزمة بيانات متجهة نحو تلك العناوين الـ256 كانت تصل إلى خوادم المهاجمين لا إلى Softaculous.
يشرح دوغ مادوري، خبير BGP ورئيس قسم تحليل الإنترنت في Infoblox، الأمر بوضوح: "لأنّه لم يكن ثمّة مسار قائم للنطاق 162.55.80.0/24 يُنافسه، انتشر هذا المسار بقدر ما سمحت به آليات تصفية المسارات الأخرى. ولأنّه كان مساراً أكثر تحديداً، فإنّ أيّ حركة مرور متجهة إلى هذا النطاق كانت تُفضّله على المسار الشرعي 162.55.0.0/16 بسبب تفضيل أجهزة التوجيه للمطابقة مع أطول بادئة."
ثلاثة إخفاقات متتالية
ما يجعل هذا الهجوم لافتاً ليس تطوّره التقني فحسب، بل تضافر ثلاثة إخفاقات مستقلة أتاحت له النجاح.
الإخفاق الأول: إعدادات RPKI المتساهلة لدى Hetzner
تمتلك Hetzner Online مزوّد الاستضافة الذي يستضيف بنية Softaculous إعدادات RPKI (Resource Public Key Infrastructure) متساهلة. RPKI هو نظام تشفيري مصمَّم تحديداً لمنع اختطاف BGP، إذ يُتيح للشبكات التحقّق من أنّ الجهة التي تُعلن عن نطاق IP هي فعلاً مالكته الشرعية. لكنّ إعدادات Hetzner سمحت بقبول نطاقات فرعية بحجم /24، وهو ما استغلّه المهاجمون.
الأخطر من ذلك أنّ المهاجمين زوّروا مسار AS بحيث يبدو أنّ Hetzner (AS24940) هي المُعلِن الأصلي. يوضّح مادوري: "لأنّ المهاجم أضاف 24940 بوصفه آخر رقم AS في المسار، اعتُبر المسار صالحاً من حيث RPKI لسببين: أوّلاً لأنّ ROA اشترط أن يكون المصدر AS24940، وثانياً لأنّه سمح بأن يتراوح طول البادئة بين 24 و16. ونتيجةً لذلك، كان هذا المسار صالحاً وفق RPKI ولم يكن عُرضةً للحذف من قِبَل الشبكات التي ترفض المسارات غير الصالحة."
يُلخّص بن كارترايت-كوكس، خبير BGP ومنشئ مجموعة أدوات BGP Tools، المشكلة بلا مجاملة: "سمحت Hetzner بالإعلان عن نطاقات IP أكثر دقةً (/24 بدلاً من /16)، ما أتاح للمختطِف انتحال هويتها والفوز تلقائياً في قرارات التوجيه."
الإخفاق الثاني: غياب التحقّق التشفيري في التحديثات
حتى لو نجح المهاجمون في اختطاف حركة المرور، كان بالإمكان إفشال هجومهم لو أنّ Softaculous وقّعت حزم التحديث رقمياً (code signing). لكنّ الشركة أقرّت في تحذيرها الأمني بأنّ هذا الإجراء لم يكن مُطبَّقاً: "عملاء تحديث منتجنا لم يكونوا يتحقّقون تشفيرياً من حزم التحديث، لذا لم يكن بالإمكان رفض حزمةٍ معدَّلة على هذا الأساس."
التوقيع الرقمي على التحديثات ممارسةٌ معيارية في صناعة البرمجيات ليست رفاهية بل ضرورة. غيابها هنا حوّل الهجوم من مجرد اختطاف لحركة مرور إلى توزيع فعلي لبرمجيات خبيثة.
الإخفاق الثالث: شهادات TLS مزوَّرة
استغلّ المهاجمون سيطرتهم على حركة المرور للحصول على شهادات TLS صادرة عن Let's Encrypt وهي جهة إصدار شهادات مجانية ومعتمدة. عملية التحقّق من ملكية النطاق (domain validation) التي تعتمد عليها Let's Encrypt تمرّ عبر الإنترنت، وبما أنّ المهاجمين سيطروا على مسار حركة المرور، تمكّنوا من اعتراض طلبات التحقّق والحصول على شهادات شرعية الشكل لنطاقاتٍ لا يملكونها.
أشارت Let's Encrypt في بيانٍ عبر البريد الإلكتروني إلى أنّ آلية "CAA account binding" كانت ستُصعّب هذا الاستغلال بشكل ملحوظ وهي آلية تربط إصدار الشهادات بحسابٍ بعينه لا بالتحقّق من النطاق وحده.
33 ساعة من الإخفاق المتكرّر
الجدول الزمني للحادثة يكشف عن إشكاليةٍ أعمق: ليس فقط أنّ الهجوم نجح، بل أنّ الكشف عنه استغرق وقتاً طويلاً بشكل لافت.
بعد نحو 12 ساعة من بدء الاختطاف الأوّل، استعادت Hetzner السيطرة على النطاق. لكنّها توقّفت عن الإعلان عن المسار الصحيح، فاستغلّ المهاجمون هذا الفراغ وأعادوا الاختطاف في جولةٍ ثانية استمرّت قرابة 10 ساعات. إجمالاً، امتدّ نشاط الاختطاف على مدى نحو 33 ساعة متقطّعة خلال عطلة نهاية الأسبوع ولم تكتشف Softaculous وشركاؤها الهجوم إلا بعد مرور نحو 22 ساعة.
المسار المُعلَن في الهجوم مرّ عبر: AS6204 (Zet.net)، ثم AS62390 (Nexon Host)، وصولاً إلى AS24940 (Hetzner Online). ويُشير المحقّقون إلى احتمال أنّ بنية تحتية Nexon Host كانت مخترَقة أو مُستغَلَّة لتنفيذ الهجوم. ولا تزال Softaculous وHetzner وZet.net جميعها لم تردّ على الأسئلة الموجَّهة إليها بشأن الحادثة.
ليست حادثة معزولة
هجمات اختطاف BGP ليست جديدة، لكنّها نادراً ما تُوظَّف لتوزيع برمجيات خبيثة بهذه الدقة. في عام 2015، استُخدم اختطاف BGP في هجوم استهدف Hacking Team. وفي عام 2022، أفضى اختطاف مماثل لعناوين Amazon إلى سرقة عملة بيتكوين بقيمة 235,000 دولار.
ما يميّز هجوم Softaculous هو استهداف سلسلة التوريد البرمجية (software supply chain): المهاجمون لم يخترقوا الخوادم مباشرةً، بل نصبوا أنفسهم في المسار بين الشركة وعملائها، محوّلين آلية الثقة ذاتها التحديث التلقائي إلى ناقل للعدوى.
ماذا يعني هذا لمديري الخوادم؟
إن كنت تُدير خوادم تعتمد على Virtualizor أو أيّ برنامج يتحدّث إلى Softaculous للتحديثات، فإنّ التحذير الأمني الرسمي يُوصي بمعاملة كلّ خادم Virtualizor باعتباره متأثّراً محتملاً وإجراء الفحوصات اللازمة. تقول Softaculous: "نعتقد أنّ عدداً صغيراً فقط من الخوادم تأثّر فعلياً، لكنّنا لا نستطيع إنتاج قائمة حاسمة، لذا يُرجى معاملة كلّ خادم Virtualizor باعتباره ضمن نطاق الفحوصات أدناه."
أمّا على المستوى البنيوي، فإنّ الدرس الأوسع يخصّ كلّ مزوّد استضافة وكلّ شركة برمجيات: التحقّق التشفيري من التحديثات ليس خياراً، وإعدادات RPKI المتساهلة تُحوّل الحماية النظرية إلى وهم، وشهادات TLS وحدها لا تُثبت أنّك تتحدّث إلى الجهة التي تظنّها.
يصفها كارترايت-كوكس بعبارةٍ لا تحتاج إلى تعليق: "أخطاء سخيفة كان يمكن تجنّبها." السؤال الذي يبقى مفتوحاً هو: كم من البنية التحتية العربية تعمل اليوم بإعداداتٍ مماثلة، وتنتظر مَن يكتشفها قبل المهاجمين؟
أخبار ذات صلة

كيف بنى الرومان قنواتهم المائية الشاهقة؟

توتنهام هوتسبير توفّر 85% من رسوم الترخيص عبر هجرة VMware

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