كشفت شركة OVHcloud عن تعرض أداة سطر الأوامر الخاصة بها (OVHcloud CLI) لهجوم على سلسلة التوريد البرمجية، بعدما نجح مهاجم في الاستيلاء على حساب أحد المساهمين على منصة GitHub واستخدامه لاستبدال ملفات التحميل الخاصة بخمس إصدارات من الأداة بملفات خبيثة مصممة لسرقة الأسرار والاعتمادات المخزنة على الأجهزة التي تقوم بتشغيلها. ووفقًا للشركة، ظلت الملفات المعدلة متاحة للتنزيل لفترة بلغت نحو 94 دقيقة يوم 19 أكتوبر قبل اكتشاف الواقعة وإزالة الملفات المصابة.
وتُعد هذه الحادثة نموذجًا متقدمًا لهجمات سلسلة التوريد الرقمية، وهي الفئة التي تستهدف البرمجيات أو قنوات التوزيع الموثوقة بدلًا من استهداف الضحايا مباشرة، بما يسمح للمهاجمين بالاستفادة من الثقة التي يضعها المستخدمون في أدوات ومشروعات مفتوحة المصدر.
هجوم استهدف مسار التحديث والتنزيل الرسمي
بحسب التفاصيل المنشورة، استغل المهاجم حساب GitHub مخترقًا تابعًا لأحد المساهمين في المشروع، وقام باستبدال أرشيفات التحميل المرتبطة بخمسة إصدارات قائمة بالفعل من أداة OVHcloud CLI بملفات تنفيذية خبيثة. وتشير الشركة إلى أن الشيفرة المصدرية الأصلية للمشروع لم تتعرض للتعديل، كما أن وسم الإصدارات (Tags) وخطوط البناء والتطوير CI/CD لم يتم اختراقها، بل جرى رفع ملفات جديدة مباشرة إلى صفحات الإصدارات المنشورة مسبقًا.
وأوضحت الشركة أن الإصدارات المتضررة شملت النسخ من v0.11.0 وحتى v0.15.0، بينما بقي الإصدار v0.10.0 سليمًا وغير متأثر بالحادثة. كما سارعت إلى حذف الملفات البديلة ونشر إصدار جديد وآمن يحمل الرقم v0.16.0 باستخدام ميزة “الإصدارات غير القابلة للتعديل” (Immutable Releases)، التي تمنع أي جهة من استبدال الملفات المرتبطة بالإصدار بعد نشره.
ولم يتأثر بالهجوم سوى المستخدمين الذين قاموا بتنزيل الأداة أو تحديثها خلال نافذة زمنية محددة امتدت من الساعة 12:47 حتى 14:21 بالتوقيت العالمي UTC، عبر قنوات تنزيل لا تتحقق من صحة البصمات الرقمية للملفات.
من هم المستخدمون المعرضون للخطر؟
أشارت OVHcloud إلى أن الخطر يقتصر على من قاموا بتثبيت الأداة أو تحديثها خلال فترة التعرض، سواء عبر سكربت التثبيت الرسمي أو من خلال تنزيل الملفات يدويًا من صفحة الإصدارات أو من خلال أنظمة التكامل المستمر التي تعتمد على روابط التنزيل المباشرة دون تثبيت قيم تجزئة ثابتة للتحقق من سلامة الملفات.
ومن بين السيناريوهات الخطرة كذلك استخدام أمر التحديث المدمج في الأداة نفسها، والذي كان يقوم بتنزيل الملفات واستبدال النسخة الموجودة دون التحقق من البصمة الرقمية للملفات المستلمة.
في المقابل، أكدت التحقيقات أن مستخدمي Homebrew لم يتأثروا بالهجوم، لأن المنصة تفرض التحقق من قيمة SHA-256 لكل ملف قبل تثبيته، ما يؤدي إلى فشل عملية التثبيت فور اكتشاف أي اختلاف في التجزئة. كما لم يتضرر المستخدمون الذين اعتمدوا على go install أو قاموا ببناء البرنامج من الشيفرة المصدرية مباشرة، إضافة إلى مستخدمي صور Docker الرسمية التي لم يُعاد بناؤها خلال فترة الهجوم.
وتبرز هذه النقطة أهمية آليات التحقق من النزاهة الرقمية للبرمجيات، إذ إن غياب التحقق من البصمات الرقمية سمح بتمرير الملفات الخبيثة إلى بعض المستخدمين رغم عدم اختراق الشيفرة المصدرية للمشروع نفسه.
مؤشرات فنية على النسخ الخبيثة
بدأ اكتشاف الحادثة عندما لاحظ أحد العملاء فشلًا في مهمة تكامل مستمر CI تعتمد على تثبيت قيمة SHA-256 ثابتة لأحد الملفات، ما دفعه إلى فحص الملف المشبوه ونشر النتائج في بلاغ على GitHub.
وكشف التحليل أن النسخة الخبيثة تحمل خصائص مختلفة عن الإصدار الأصلي، من بينها ظهور معرف إصدار غير رسمي مولّد تلقائيًا بواسطة Go، إضافة إلى الإشارة إلى التزام برمجي مختلف عن ذلك المرتبط بالإصدار الشرعي. كما احتوت الملفات المزورة على معلمات بناء لم تكن موجودة في النسخ الأصلية الصادرة عن OVHcloud.
وأشارت التقارير إلى أن البرمجية المعدلة صُممت لسرقة الأسرار المخزنة محليًا على الأجهزة المصابة، بما في ذلك مفاتيح الوصول واعتمادات واجهات البرمجة والبيانات الحساسة الأخرى التي يمكن الوصول إليها من النظام. غير أن الشركة لم تكشف حتى الآن عن الملفات التي كانت البرمجية تستهدفها تحديدًا أو الوجهة التي كانت ترسل البيانات المسروقة إليها.
ولهذا السبب نصحت الشركة جميع المستخدمين الذين يعتقدون أنهم شغّلوا النسخ المشبوهة أو غير القادرين على التأكد من سلامة بيئاتهم باعتبار جميع الأسرار الموجودة على الأجهزة متسربة محتملًا، مع ضرورة تدوير كلمات المرور والمفاتيح والرموز السرية من جهاز مختلف وآمن قبل إعادة تثبيت النسخة النظيفة.
كيف وقع الاختراق وما علاقة GlassWorm؟
أظهر التحقيق أن السبب الجوهري للحادث يعود إلى عدم تفعيل ميزة “الإصدارات غير القابلة للتعديل” في مستودع GitHub الخاص بالمشروع. وفي الوضع الافتراضي يمكن للمستخدمين الذين يمتلكون صلاحيات مناسبة حذف الملفات المرفقة بإصدار منشور وإعادة رفع ملفات جديدة بالاسم نفسه دون تغيير رابط التحميل، وهو ما استغله المهاجم في هذه العملية.
وأكد مؤسس الشركة أن المشكلة لم تنتج عن اختراق خطوط التطوير أو البنية التحتية للشركة، بل عن إمكانية تعديل الملفات المنشورة مباشرة على GitHub بسبب عدم تفعيل خاصية الحماية المذكورة مسبقًا، والتي جرى تفعيلها لاحقًا بعد اكتشاف الحادث.
وتوصل باحثو OpenSourceMalware إلى وجود صلة محتملة بين الحساب المخترق وحملة البرمجيات الخبيثة المعروفة باسم GlassWorm، وهي حملة اشتهرت سابقًا بإخفاء تعليمات برمجية ضارة داخل محارف Unicode غير المرئية والاعتماد على معاملات شبكة Solana لجلب مراحل إضافية من البرمجية الخبيثة. ومع ذلك، شدد الباحثون على أن الربط بين الحادثتين لا يزال في إطار الاستنتاجات التحليلية، إذ لا توجد أدلة قاطعة تؤكد أن الجهة نفسها تقف وراء العمليتين.
وتسلط الحادثة الضوء مجددًا على تصاعد مخاطر هجمات سلسلة التوريد مفتوحة المصدر، خاصة في ظل اعتماد المؤسسات والمطورين على أدوات خارجية يتم تثبيتها تلقائيًا عبر الإنترنت. كما تؤكد أهمية تفعيل آليات التحقق من سلامة الملفات، واستخدام التواقيع الرقمية، والاعتماد على الإصدارات غير القابلة للتعديل، إلى جانب فرض التحقق الإجباري من قيم التجزئة قبل تنزيل البرمجيات أو تحديثها.
