هجوم سلسلة التوريد على GitHub Action: reviewdog/action-setup

تحديث 21 مارس 2025:

يمكننا الآن الكشف علنًا عن تفاصيل إضافية حول هذا الحادث.

1) الهدف المحدد المذكور في المنشور الأصلي هو Coinbase، الذي أكد محاولة فاشلة للتسوية coinbase/agentkit. حدد Wiz هويات GitHub ذات الصلة بالهجوم، مما يشير إلى أن المهاجم نشط في النظام البيئي للعملات المشفرة، ويتحدث الفرنسية والإنجليزية، وتتوافق ساعات العمل مع أوروبا أو إفريقيا.

تم تقديم أول إشارة إلى هذا الارتباط من قبل سان تران في 15 مارس. واكتشفنا أدلة أخرى على هذا الارتباط، بما في ذلك:

1. التزام على tj-actions/changed-files اعتبارًا من 13 مارس، مع متغير حمولة يستهدف بشكل صريح مستودعات Coinbase

2. تسجيل الدخول لسير العمل coinbase/agentkit من 14 مارس، مرتبط بارتكاب انتحال شخصية موظف في Coinbase، مما يدل على محاولة موازية لتسوية سلسلة التوريد الخاصة بالمستودع، من قبل نفس الممثل

3. إزالة changelog.yml، سير العمل الذي يستخدم tj-actions/changed-files، في غضون ساعة من التوصل إلى حل وسط لـ tj-actions وقبل وقت طويل من الكشف العلني بواسطة StepSecurity

تمت مشاركة تحليل Wiz الكامل مع Coinbase من خلال قنوات الكشف المسؤولة الخاصة بهم. يمكنك مراجعة الجدول الزمني عبر الكشف العام عن Unit42، والذي يعكس تقرير Wiz الخاص.

2) تمكنت haya14busa من تحديد ومعالجة المستخدم المخترق، بمساعدة GitHub، والذي أدى إلى حدوث الاختراق. action-setup حادثة. لم تتم إضافة الحساب المتورط بشكل ضار عبر سير عمل Invite الذي تمت مناقشته مسبقًا، بل تم اختراقه بنفسه. سنستمر في المشاركة بشكل مسؤول مع تطور المعلومات. ويستمر Wiz في دعم reviewdog المشرف، بعد إفصاحنا المسؤول عن التسوية action-setup. نشكر haya14busa و tj-actions المشرفين على تعاونهم ودقتهم في معالجة هذا الحادث. في هذه المرحلة، نعتقد أنهم قاموا بحل الحادث وقللوا من تعرضهم لهجمات مستقبلية.

تحديث 19 مارس 2025: تم تعيين هذه المشكلة إلى CVE-2025-30154.

تحديث 19 مارس 2025: قام أحد مشرفي المراجعة، ردًا على ما كشفه Wiz، بنشر تفاصيل الحادثة وردهم عليها.

تسبب هجوم سلسلة التوريد على GitHub Action tj-actions/changed-files الشهير في قيام العديد من المستودعات بتسريب أسرارها خلال عطلة نهاية الأسبوع. اكتشفت Wiz Research هجومًا إضافيًا على سلسلة التوريد على reviewdog/actions-setup@v1، والذي ربما يكون قد ساهم في اختراق tj-actions/changed-files. في هذه المرحلة، نعتقد أن هذه سلسلة من الهجمات على سلسلة التوريد تؤدي في النهاية إلى هدف محدد عالي القيمة.

• كما ذكرنا سابقًا، فإن GitHub Action المستخدم على نطاق واسع tj-actions/changed-files تم اختراقه بحمولة ضارة تسببت في تسرب المستودعات المتأثرة لأسرارها في السجلات. بالامتداد، tj-actions/eslint-changed-files كما تم اختراقه في نفس الوقت، كما يعتمد عليهtj-actions/changed-files.

• استنادًا إلى دليل من عدنان خان، حددت شركة Wiz Research أن علامة v1 الخاصة بـ reviewdog/action-setup تم اختراق Github Action في الفترة التي سبقت حادثة tj-actions. تعتبر الاستجابة الفورية ضرورية للتخفيف من مخاطر سرقة بيانات الاعتماد وتسوية خط أنابيب CI.

• كشف القائمون على tj-actions أن رمز وصول Github الشخصي (PAT) المخترق كان السبب الجذري الذي سمح للمهاجمين بتعديل المستودع.

• ونحن نعتقد أنه من المحتمل التوصل إلى حل وسط reviewdog/action-setup هو السبب الجذري لتسوية tj-action-bot PAT. tj-actions/eslint-changed-files الاستخدامات reviewdog/action-setup@v1، و tj-actions/changed-files مستودع يدير هذا tj-actions/eslint-changed-files الإجراء باستخدام رمز الوصول الشخصي. تم اختراق إجراء المراجعة خلال نفس النافذة الزمنية تقريبًا مثل تسوية TJ-actions PAT.

• لأن التسوية reviewdog/action-setup لم يتم الكشف عنها مسبقًا ويبدو أنه تم علاجها بالصدفة، فهناك خطر مستمر لتكرارها. قد يؤدي هذا إلى تكرار التسوية tj-actions/changed-files.

• كشف Wiz عن هذه المشكلة لـ reviewdog وGitHub.

كما رأينا مع tj-actions، قام إجراء reviewdog المخترق بإدخال تعليمات برمجية ضارة في أي سير عمل لـ CI يستخدمه، مما يؤدي إلى تفريغ ذاكرة مشغل CI التي تحتوي على أسرار سير العمل. على الرغم من أن هذه هي نفس النتيجة كما في حالة tj-actions، إلا أن الحمولة كانت متميزة ولم تستخدم الضفيرة لاسترداد الحمولة. وبدلاً من ذلك، تم ترميز الحمولة باستخدام Base64 وإدراجها مباشرة في ملف install.sh الذي يستخدمه سير العمل.

في المستودعات العامة، ستكون الأسرار مرئية للجميع كجزء من سجلات سير العمل، على الرغم من أنها مشوشة كحمولة Base64 مشفرة مزدوجة. حتى الآن، لم يتم ملاحظة أي تسرب خارجي للأسرار إلى خادم يتحكم فيه المهاجم؛ كانت الأسرار يمكن ملاحظتها فقط داخل المستودعات المتأثرة نفسها.

نعتقد أن علامة v1 الخاصة بـ reviewdog Action قد تمت الإشارة إليها على التزام ضار في 11 مارس بين الساعة 18:42 و20:31 بالتوقيت العالمي، قبل أن تعود علامة v1 للإشارة إلى التزام قديم. ربما قام المهاجم بدفع الالتزام الأقدم بالقوة للتغطية على التسوية، مما يعني أنه حقق هدفًا ضيقًا ورغب في البقاء متخفيًا. (تحرير: أرجعت مسودة سابقة لهذا المنشور هذا إلى عثرة الإصدار التلقائي، وتم تحريرها بناءً على تعليقات مشرف المراجعة)

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

اعتبارًا من 17 مارس 2025، تم العثور على علامة واحدة فقط (الإصدار 1) من إجراء إعداد المراجعة/الإجراء متأثرة. لن يتأثر العملاء الذين كانوا يستخدمون إصدارًا مثبتًا بتجزئة من reviewdog/action-setup أو الذين تم تثبيتهم بعلامة مختلفة.

ومع ذلك، يتم استخدام هذا الإجراء بعد ذلك كجزء من العديد من الإجراءات الأخرى من reviewdog، بما في ذلك:

• reviewdog/action-shellcheck

• reviewdog/action-composite-template

• reviewdog/action-staticcheck

• reviewdog/action-ast-grep

• reviewdog/أخطاء العمل

يمكن أن يتأثر العملاء الذين كانوا يستخدمون إجراءات/إجراءات مراجعة أخرى متأثرة، بغض النظر عن إصدار هذا الإجراء.

التحقيق لا يزال مستمرا. يمكننا أن نقول إن المهاجم حصل على وصول كافٍ لتحديث علامة v1 إلى التعليمات البرمجية الضارة التي وضعها على مفترق المستودع. تتمتع منظمة Github للمراجعة بقاعدة كبيرة نسبيًا من المساهمين ويبدو أنها تضيف المساهمين بشكل نشط من خلال الدعوات الآلية. يؤدي هذا إلى زيادة سطح الهجوم حتى يتم اختراق وصول المساهم أو الحصول على وصول المساهم بشكل ضار.

سنقوم بتحديث منشور المدونة هذا مع ظهور معلومات جديدة.

1. استخدم استعلام Github هذا للعثور على مراجع لإجراءات GitHub المتأثرة في مستودعات مؤسستك (استبدل yourorg باسم مؤسسة Github الخاصة بك).

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

3. انتقل إلى وظيفة سير العمل ذات الصلة، وقم بتوسيع خطوة “Run reviewdog/action-setup@v1”. إذا رأيت سطرًا بعنوان “🐶 تحضير البيئة…”، فهذا يعني أنه تم تشغيل التعليمات البرمجية الضارة. تحقق مما إذا كانت هناك سلسلة Base64 مزدوجة التشفير بداخلها. إذا كان موجودًا، فهذا يعني أنه تم تنفيذ الحمولة الضارة بنجاح، ويعتمد التأثير على ما إذا كان الريبو عامًا أم خاصًا: إذا كان الريبو عامًا، فهذا يعني أن الأسرار الموجودة في السلسلة قد تم تسريبها علنًا في سجلات سير العمل، ونحن نوصي بشدة بتدويرها في أقرب وقت ممكن. بخلاف ذلك، إذا كان الريبو خاصًا، فهذا يعني أن الأسرار لم يتم تسريبها علنًا، ولكن لا يزال يتعين عليك التفكير في تدويرها.

لاحظ أنه إذا تأثر المستودع الخاص بك ولكن الأسرار الوحيدة التي تم الكشف عنها هي رموز GitHub المميزة التي تبدأ بالبادئة ghs_، هذه عبارة عن رموز مميزة قصيرة العمر وتنتهي صلاحيتها تلقائيًا خلال 24 ساعة أو بمجرد اكتمال مهمة سير العمل. وبالتالي، ما لم تتم مقاطعة المهمة والفشل في إكمالها، تكون هناك مخاطر محدودة على المدى الطويل من التعرض لـ A ghs_ رمز وحده.

بالإضافة إلى ذلك، إذا كان سير العمل الخاص بك لا يشير بشكل صريح إلى الأسرار المخصصة (على سبيل المثال، الرمز المميز: ${{ secrets.MYSECRET }})، فمن غير المرجح أن تكون الأسرار الحساسة قد تعرضت للخطر نتيجة لهذا الحادث. يكمن الخطر الأساسي في احتمالية الكشف عن الأسرار المخصصة المشار إليها بوضوح ضمن مسارات العمل المتأثرة.

1. توقف عن استخدام الإجراءات المتأثرة على الفور واستبدلها ببديل أكثر أمانًا إن أمكن.

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

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

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

2. يتم تشغيل تدقيق سير العمل السابق بحثًا عن نشاط مشبوه. تحقق من السجلات بحثًا عن طلبات الشبكة الصادرة غير العادية، وأعط الأولوية لمراجعة المستودعات حيث يمكن الوصول إلى سجلات مشغل CI بشكل عام، حيث قد يتم الكشف عن الأسرار في السجلات.

3. استخدم ميزة قائمة السماح في GitHub لمنع تشغيل إجراءات GitHub غير المصرح بها وتكوين GitHub للسماح بالإجراءات الموثوقة فقط.

1. يمكن لعملاء Wiz Code المزودين بموصل GitHub استخدام عناصر التحكم التي تم إنشاؤها في مستودعات التعليمات البرمجية المتأثرة لاكتشاف وجود الإجراءات المخترقة.

2. يمكن لعملاء Wiz Sensor المزودين بـ Sensor المنشور على أحمال عمل CI اكتشاف الأنشطة الضارة المرتبطة بهذا الهجوم، مثل تفريغ ذاكرة العملية.

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

4. يمكن لعملاء Wiz أيضًا الرجوع إلى تقرير Threat Intel Center بشأن هذا الهجوم، والذي يتضمن إمكانات إضافية وسيتم تحديثها عند إضافة إمكانات جديدة.