الأمن السيبراني

اختراق GitHub Action الخاص بشركة Xygeni عبر تسميم العلامات

في مارس 2023، تعرض GitHub Action الخاص بشركة Xygeni للاختراق من قبل مهاجم غير معروف عبر تقنية تسميم العلامات. هذا الحادث يسلط الضوء على المخاطر الأمنية المرتبطة بإدارة الأكواد والمستودعات.

تمكن أحد المهاجمين غير المعروفين من اختراق أحد GitHub Actions الخاص بشركة Xygeni للأمان التطبيقي هذا الشهر من خلال تسميم العلامات.

أفادت Xygeni، التي تبيع عددًا من المنتجات المدعومة بالذكاء الاصطناعي في مجال أمان التطبيقات، في تقريرها عن الحادث الأمني في 10 مارس أنها “اكتشفت نشاطًا مشبوهًا يؤثر على المستودع المستخدم لنشر GitHub Action الخاص بـ xygeni/xygeni-action.”

استخدم المهاجم طلبات سحب في محاولة لإدخال كود خبيث (زرع للتحكم في الأوامر) في المستودع، على الرغم من أن Xygeni ذكرت أن هذه المحاولات تم حظرها عبر قواعد اكتشاف الفروع الحالية. ثم قام المهاجم بتغيير الاتجاه، مستغلًا “متجهًا منفصلًا عن طريق نقل العلامة القابلة للتغيير v5 للإشارة إلى التزام خبيث تم إنشاؤه خلال محاولات طلب السحب.”

“يمكن أن تسترجع سير العمل التي تشير إلى xygeni/xygeni-action@v5 الكود المخترق دون أي تغيير مرئي في تعريفات سير العمل الخاصة بها،” قالت Xygeni في إفادتها. حصل المهاجم على الوصول من خلال بيانات اعتماد مخترقة مرتبطة برمز صيانة وتطبيق GitHub مثبت على المستودع المعني.

مرتبط: مايكروسوفت تصحح 83 ثغرة في تحديث مارس

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

سبب هجوم Xygeni وإجراءات العلاج

كان منشور Xygeni مفصلًا بشكل ملحوظ، حيث تضمن جدولًا زمنيًا للهجوم بالإضافة إلى تحليل السبب الجذري وتوصيات العلاج.

استنتجت الشركة أن السبب الجذري للاختراق كان هو اختراق مفتاح خاص لتطبيق GitHub تم تثبيته على المستودع وكان له أذونات واسعة غير ضرورية. استخدم المهاجم رمز وصول شخصي (PAT) لأحد الصيانة جنبًا إلى جنب مع بيانات اعتماد تطبيق GitHub: أحدهما لإنشاء طلبات سحب، والآخر للموافقة عليها (حيث لم يكن بإمكان أي منهما تجاوز حماية المستودع بمفرده).

في المستقبل، التزمت Xygeni بفرض عدم قابلية تغيير الإصدارات عبر المستودعات، وتعزيز أذونات المستودع والوصول إلى المساهمين، وجعل الالتزامات الموقعة بشكل تشفيري إلزامية للصيانة، وتقييد الوصول للكتابة لمجموعة محدودة من الصيانة والمديرين.

قال البائع إن على العملاء تحديث سير العمل الخاصة بهم لتثبيت على SHA الالتزام الآمن، ومراجعة سجلات CI، وتدوير الأسرار التي تم الكشف عنها لعداء CI خلال فترة الاختراق.

اختلاف حول جداول زمنية للهجوم

مرتبط: تكوينات سحابة Salesforce “المفرطة السماح” في دائرة الضوء

“لا يزال التحقيق جارياً في المتجه الدقيق الذي تم من خلاله استخراج المفتاح الخاص،” قرأت الإفادة. “يمكن أن تتسرب مفاتيح تطبيق GitHub الخاصة (.pem) من خلال سير العمل غير المكونة بشكل صحيح، أو أجهزة المطورين المخترقة، أو تخزين الأسرار غير الآمن.”

كان أحد المؤشرات العامة الأولى للاختراق في 9 مارس في منشور مدونة من الرئيس التنفيذي والمؤسس المشارك لشركة StepSecurity، فارون شارما.

“في 3 مارس 2026، قام مهاجم لديه وصول إلى حسابات الصيانة ورمز تطبيق GitHub بحقن قشرة عكسية كاملة للتحكم في الأوامر في xygeni/xygeni-action، GitHub Action الرسمي الذي نشرته Xygeni،” كتب شارما. “كانت البوابة متخفية كخطوة ‘استطلاع إصدار المراقبة’. تم فتح ثلاثة طلبات سحب تحمل الكود الخبيث وإغلاقها دون دمج، لكن المهاجم أيضًا نقل العلامة المختصرة v5 للإشارة إلى الالتزام المخترق. لمدة 7 أيام (من 3 إلى 10 مارس)، كان أي شخص يشير إلى xygeni/xygeni-action@v5 في سير العمل الخاصة بهم يقوم بتشغيل زرع C2.”

جادل شارما بأن الهجوم الحقيقي كان العلامة v5، التي يمكن لأي شخص لديه وصول للكتابة استخدامها للإشارة إلى أي التزام، كما فعل المهاجم في النهاية. على الرغم من أن فريق Xygeni تصرف بسرعة لإغلاق جميع طلبات السحب الثلاثة وحذف جميع سير العمل ذات الصلة من المستودع، قال شارما إن الإصلاح الأولي في 9 مارس لا يزال يتضمن العلامة v5. تم تصحيح ذلك في 10 مارس بعد أن أبلغت StepSecurity عن المشكلة.

مرتبط: هل نحن جاهزون للإصلاح التلقائي مع الذكاء الاصطناعي الوكيل؟

يقول شارما لـ Dark Reading عبر البريد الإلكتروني إن هذه كانت حالة لم تقم فيها Xygeni بإجراء إصلاح كامل وكان ينبغي أن تفعل ذلك.

“إغلاق طلبات السحب وحذف سير العمل لم يفعل شيئًا لوقف الاختراق النشط لأن العلامة v5 كانت آلية التسليم بالكامل. … إغلاق طلبات السحب وحذف سير العمل من الرئيسي لم يكن له تأثير على ما كان يشير إليه @v5،” يقول شارما، مضيفًا أنه لمدة سبعة أيام، كانت زرع C2 نشطة. “أي تشغيل لسير العمل باستخدام @v5 خلال الفترة من 3 إلى 10 مارس أعطى المهاجم نافذة زمنية مدتها ثلاث دقائق لتنفيذ الأوامر بشكل تعسفي على ذلك العداء CI – الوصول إلى GITHUB_TOKEN، وأسرار المستودع، والشيفرة المصدرية.”

تتنازع Xygeni بعض جوانب بحث StepSecurity، بما في ذلك بعض التفاصيل المحيطة بوقت تسميم العلامة v5.

“يضع تقرير الباحث توقيت نقل العلامة v5 في حوالي 10:49 بتوقيت UTC في 3 مارس، مباشرة بعد إغلاق طلبات السحب،” قالت Xygeni في تقرير الحادث. “لم تتمكن تحقيقاتنا من تأكيد هذا التوقيت – لم يتم تسجيل أحداث دفع العلامات في سجل نشاط المستودع على GitHub. ما نعرفه هو أن العلامة تم تسميمها في وقت ما بعد إنشاء الالتزام الخبيث وقبل أن يكتشفها المجتمع في 9 مارس.”

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

مقالات ذات صلة

زر الذهاب إلى الأعلى