داخل هجوم سلسلة التوريد «Megalodon» على GitHub

اعتمدت الحملة على الأتمتة مع تمويه اجتماعي يجعل التغييرات تبدو وكأنها صيانة روتينية لخطوط CI.

روبوتات CI مزيفة وحسابات مؤقتة

أنشأ المهاجمون حسابات GitHub مؤقتة بأسماء عشوائية، واستخدموا هويات تبدو كأنها أنظمة أتمتة مثل:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

بهذه الطريقة بدت الالتزامات وكأنها صادرة عن أدوات بناء آلية وليس عن مهاجم بشري.

تزوير بيانات الالتزام

تم تصميم رسائل الالتزام وبيانات المؤلف لتبدو طبيعية—مثل تحديثات إعدادات CI أو تحسينات في ملفات workflow—ما سمح لها بالاندماج مع النشاط المعتاد للمستودعات وتأخير اكتشافها.

استهداف المستودعات ذات الحماية الضعيفة

ركزت الحملة على المستودعات التي تفتقر إلى قواعد حماية الفروع (Branch Protection) الصارمة. عندما لا يُطلب مراجعة طلبات السحب أو تُفرض قيود على تعديل ملفات workflow، يستطيع المهاجم دفع التغييرات مباشرة إلى الفرع الافتراضي للمستودع.

حقن مهام GitHub Actions خبيثة

كل التزام خبيث أضاف ملف workflow لـ GitHub Actions يحتوي على حمولة Bash مشفرة بصيغة Base64. عند تشغيل خط CI، تُفك الشفرة ويبدأ السكربت في جمع الأسرار من بيئة التنفيذ.

هذا يعني أن الهجوم قد يبقى غير ملاحظ حتى يتم تشغيل خط CI التالي للمستودع.

ما البيانات التي حاولت الحمولة سرقتها

السكربت المشفر داخل ملفات workflow صُمم لجمع معلومات حساسة من بيئة CI ثم إرسالها إلى بنية تحتية يتحكم بها المهاجمون.

من بين الأهداف التي ذُكرت في التقارير:

• متغيرات البيئة الخاصة بـ CI/CD
• بيانات اعتماد مزودي السحابة مثل AWS وGoogle Cloud وAzure
• مفاتيح SSH الخاصة
• رموز API وأسرار التطبيقات
• رموز GitHub Actions OIDC
• أسرار التهيئة الأخرى المتاحة داخل بيئة التشغيل

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

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

لماذا يُعد سرقة رموز OIDC خطيرًا بشكل خاص

أحد أهم أهداف حمولة Megalodon كان رموز GitHub Actions OIDC.

تعتمد العديد من خطوط CI/CD الحديثة على OpenID Connect (OIDC) للمصادقة مع خدمات السحابة دون تخزين مفاتيح طويلة العمر. بدلاً من ذلك، يطلب workflow رمز هوية مؤقتًا يتم استبداله ببيانات اعتماد قصيرة الأجل للوصول إلى الخدمات السحابية.

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

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

وبالتالي قد يؤدي اختراق workflow إلى:

• الوصول إلى البنية التحتية السحابية
• اختطاف عمليات النشر
• استخراج أسرار إضافية من الخدمات السحابية

حتى لو كانت الرموز قصيرة العمر، فإن دقائق من الوصول قد تكون كافية للمهاجم لتوسيع الاختراق.

لماذا كان هذا الهجوم مهمًا

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

عند استهداف workflows الخاصة بـ CI يمكن للمهاجمين:

• سرقة الاعتمادات تلقائيًا عند تشغيل خطوط البناء
• الوصول إلى أنظمة النشر والبنية السحابية
• الاختباء داخل تغييرات تبدو روتينية في الأتمتة

ولأن آلاف المشاريع تعتمد على CI للوصول إلى موارد حساسة، فإن تعديل ملف workflow واحد قد يعرّض العديد من الأنظمة المرتبطة للخطر.

هل كان للهجوم علاقة باختراق GitHub عبر إضافة VS Code؟

في الوقت نفسه تقريبًا، أعلنت GitHub عن حادثة أمنية منفصلة تتعلق بإضافة خبيثة في Visual Studio Code تم تثبيتها على جهاز أحد الموظفين. وقد مكّن ذلك المهاجمين من الوصول إلى نحو 3800 مستودع داخلي في GitHub قبل احتواء الحادثة.

الاختراق ارتبط بإضافة خبيثة ضمن متجر VS Code كانت قادرة على سرقة رموز الوصول والأسرار من بيئة المطور.

بعض التقارير أشارت إلى تشابه في التوقيت والأساليب بين هذه الحادثة وهجمات سلسلة التوريد الأخرى التي تستهدف أدوات التطوير. لكن لا يوجد دليل علني يؤكد أن الاختراق الداخلي في GitHub أدى مباشرة إلى حملة Megalodon.

حتى الآن يُنظر إلى الحادثتين على أنهما حدثان منفصلان وقعا في الفترة نفسها داخل منظومة أدوات التطوير.

الدرس الأوسع لأمن CI/CD

يُظهر Megalodon مدى سرعة انتشار هجوم سلسلة توريد عندما تُستخدم الأتمتة على نطاق واسع. عبر الجمع بين حسابات روبوت مزيفة والتزامات آلية وملفات workflow مسمومة، استطاع المهاجمون تحويل بنية البناء نفسها إلى أداة لسرقة البيانات.

الحادثة عززت عدة ممارسات دفاعية مهمة لفرق التطوير، مثل:

• تطبيق قواعد حماية صارمة للفروع
• فرض مراجعة إلزامية لتغييرات ملفات workflow
• تقليل صلاحيات مهام CI قدر الإمكان
• مراقبة حسابات الأتمتة والتغييرات في إعدادات CI

ومع اعتماد المؤسسات بشكل متزايد على خطوط النشر الآلية لإدارة البنية السحابية والإنتاج، أصبح أمن CI/CD جزءًا أساسيًا من الدفاع عن سلسلة توريد البرمجيات.