تم العثور على العديد من المشاريع المفتوحة المصدر البارزة، بما في ذلك تلك الخاصة بـ Google وMicrosoft وAWS وRed Hat، لتسريب رموز مصادقة GitHub من خلال عناصر GitHub Actions في سير عمل CI/CD.
يمكن للمهاجمين الذين يسرقون هذه الرموز الحصول على وصول غير مصرح به إلى مستودعات خاصة، أو سرقة الكود المصدري، أو حقن كود ضار في المشاريع.
وقد دفع اكتشاف وحدة 42 التابعة لشركة Palo Alto Networks أصحاب المستودعات الشهيرة التي تسربت فيها الأسرار من خلال أدوات GitHub Actions إلى اتخاذ إجراءات. ومع ذلك، لا تزال المشاكل الأساسية دون حل حيث قررت GitHub عدم معالجة المخاطر، مما يضع مسؤولية تأمين أدواتها على عاتق المستخدمين.
نظرًا للوضع الحالي، يحتاج مستخدمو GitHub إلى فهم المخاطر وتقييم تعرضهم لها واتخاذ التدابير اللازمة لمنع التسريبات في المستقبل.
المصدر: الوحدة 42
تسريب رموز GitHub
الوحدة 42 تقرير يسلط التقرير الضوء على مجموعة من العوامل، بما في ذلك إعدادات افتراضية غير آمنة، وسوء تكوين المستخدم، وفحوصات أمنية غير كافية، والتي يمكن أن تؤدي إلى تسرب رموز GitHub في ما يسمى بهجوم “ArtiPACKED”.
نقطة الخطر الأولى هي إجراء “actions/checkout”، والذي يستخدم عادةً في سير عمل GitHub لاستنساخ كود المستودع بحيث يكون متاحًا أثناء تشغيل سير العمل.
بشكل افتراضي، يعمل هذا الإجراء على إبقاء رمز GitHub في دليل .git المحلي (مخفي) كما هو مطلوب للعمليات المعتمدة ضمن سير العمل.
إذا قام مستخدم عن طريق الخطأ بتحميل دليل الخروج بأكمله كجزء من قطعة أثرية، فسيتم الآن عرض رمز GitHub داخل مجلد git.
المصدر: الوحدة 42
قد تتضمن المعلومات الحساسة الأخرى التي قد تكون موجودة في هذا المجلد مفاتيح API، ورموز وصول الخدمة السحابية، وبيانات اعتماد الحساب المختلفة.
يمكن أن يحدث تعرض مماثل من خلال تحميلات القطع الأثرية الخاطئة من خلال القطع الأثرية التي تم إنشاؤها أثناء عملية CI/CD، مثل مخرجات البناء ونتائج الاختبار، والتي يتم تخزينها ويمكن الوصول إليها لمدة تصل إلى ثلاثة أشهر.
نقطة فشل أخرى هي خطوط أنابيب CI/CD التي تستخدم متغيرات البيئة لتخزين رموز GitHub. إذا سجلت الإجراءات أو البرامج النصية داخل سير العمل هذه المتغيرات، إما عن قصد أو عن طريق الخطأ، فسيتم تحميل السجلات كقطع أثرية.
تلاحظ الوحدة 42 أن إجراء “super-linter” يمكنه إنشاء سجلات مفصلة تتضمن متغيرات البيئة عندما يتم تعيين الخاصية “CREATE_LOG_FILE” على “True”.
استغلال التسريبات
في النهاية، قد يسعى المهاجمون إلى استغلال سيناريوهات حالة السباق المحددة حيث يتعين استخراج رموز GitHub المؤقتة من السجلات واستخدامها قبل انتهاء صلاحيتها.
تظل رموز GitHub صالحة طوال مدة مهمة سير العمل، لذا فإن إمكانية استغلالها تختلف حسب الحالة.
عادةً ما يكون ‘Actions_Runtime_Token’ المستخدم داخليًا بواسطة GitHub للتخزين المؤقت وإدارة القطع الأثرية صالحًا لمدة ست ساعات، وبالتالي فإن نافذة الاستغلال صغيرة.
تتمتع الأسرار والرموز المخصصة، مثل مفاتيح API أو رموز الوصول للخدمات السحابية، بعمر افتراضي متفاوت، من بضع دقائق إلى عدم انتهاء الصلاحية أبدًا.
تقدم الوحدة 42 سيناريو هجوم يحدد المشاريع أو المستودعات العامة التي تستخدم GitHub Actions وتستخدم البرامج النصية الآلية لفحصها بحثًا عن معايير تزيد من احتمالية إنشاء القطع الأثرية.
يمكن لمجموعة مختلفة من البرامج النصية تنزيل القطع الأثرية تلقائيًا من خطوط أنابيب CI/CD الخاصة بمستودعات البيانات المستهدفة، وهي عملية بسيطة في حالة المستودعات العامة. بعد ذلك، ستقوم بفحصها بحثًا عن الأسرار.
المصدر: الوحدة 42
التخفيف
حددت الوحدة 42 الحالات الـ 14 التالية لمشاريع مفتوحة المصدر كبيرة تعرض القطع الأثرية باستخدام رموز GitHub وأبلغت عنها للأطراف المتضررة لإصلاحها:
- فايربيس (جوجل)
- أمان OpenSearch (AWS)
- كلير (ريد هات)
- نظام Active Directory (Adsys) (Canonical)
- مخططات JSON (Microsoft)
- أتمتة مستودعات TypeScript، ومشغل اختبار روبوت TypeScript، وAzure Draft (Microsoft)
- برنامج CycloneDX SBOM (OWASP)
- سمك القد
- ليبيفنت
- حارس أباتشي كافكا (Aiven-Open)
- ملحق Git (داتالاد)
- بينروز
- سطح السفينة
- Concrete-ML (Zama AI)
بشكل عام، يُنصح مستخدمي GitHub بتجنب تضمين أدلة كاملة في القطع الأثرية التي تم تحميلها، وتطهير السجلات، ومراجعة تكوينات خط أنابيب CI/CD بانتظام.
يجب تعديل الإعدادات الافتراضية للإجراءات الخطيرة مثل “الإجراءات/الخروج” حتى لا تظل بيانات الاعتماد موجودة. علاوة على ذلك، يجب ضبط أذونات الرموز المستخدمة في سير العمل على أقل قدر من الامتيازات اللازمة للحد من الضرر في حالة تعرضها.