التكامل المستمر والنشر المستمر (CI/CD) pipelineتلعب دورًا محوريًا في تسهيل تطوير البرامج المبسطة. ومع ذلك، مثل هذه pipelineمع تزايد أهمية أمن المعلومات، أصبحت ضرورة حمايتها من الثغرات الأمنية أكثر إلحاحًا. يركز هذا التحقيق المتعمق على معالجة خطر بارز تم تحديده في قائمة OWASP Top 10 CI/CD المخاطر الأمنية: مسمومة Pipeline التنفيذ (معدات الوقاية الشخصية).
ما هو مسموم Pipeline التنفيذ (معدات الوقاية الشخصية)
وفقًا لـ OWASP Top-10 CI/CD "المخاطر الأمنية،"تسمم Pipeline التنفيذ (معدات الوقاية الشخصية) تشير المخاطر إلى قدرة المهاجم على الوصول إلى أنظمة التحكم بالمصدر - ودون الوصول إلى بيئة البناء - لمعالجة عملية الإنشاء عن طريق إدخال تعليمات برمجية/أوامر ضارة في الإنشاء pipeline ترتيب، بشكل أساسي "تسميم" pipeline وتشغيل تعليمات برمجية ضارة كجزء من عملية الإنشاء"
في بضع كلمات، مسموم Pipeline يتم تنفيذ (PPE) عندما يمكن للمهاجم تعديل pipeline منطق.
هناك اثنان المتغيرات:
- معدات الوقاية الشخصية المباشرة (D- معدات الوقاية الشخصية): في سيناريو D-PPE، يقوم المهاجم بتعديل ملف تكوين CI في المستودع الذي يمكنهم الوصول إليه، إما عن طريق دفع التغيير مباشرة إلى فرع بعيد غير محمي في الريبو، أو عن طريق إرسال طلب PR مع التغيير من فرع أو تفرع. منذ سي آي pipeline يتم تحديد التنفيذ من خلال الأوامر الموجودة في ملف تكوين CI المعدل، ويتم تشغيل الأوامر الضارة للمهاجم في النهاية في عقدة الإنشاء بمجرد الإنشاء pipeline يتم تشغيل.
- معدات الوقاية الشخصية غير المباشرة (معدات الوقاية الشخصية): في بعض الحالات، لا تتوفر إمكانية استخدام معدات الحماية الشخصية الدفاعية (D-PPE) للخصم الذي لديه إمكانية الوصول إلى SCM المستودع (على سبيل المثال إذا كان pipeline تم تكوينه لسحب ملف تكوين CI من فرع منفصل ومحمي في نفس المستودع). في مثل هذا السيناريو، بدلا من تسميم pipeline في حد ذاته، يقوم المهاجم بإدخال تعليمات برمجية ضارة في الملفات المشار إليها بواسطة ملف pipeline (على سبيل المثال: البرامج النصية المشار إليها من داخل ملف pipeline ملف الضبط)
في كلتا الحالتين، سيقوم GitHub بتنفيذ التعديل pipeline دون الحاجة إلى مراجعة أو موافقة سابقة.
الكشف المبكر عن معدات الوقاية الشخصية
كيف يمكننا اكتشاف هذا النوع من الثغرة الأمنية؟
دعونا نرى هذا المثال pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed. ومحتوى البرنامج النصي الوهمي (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0استخدم pipeline إنه بسيط للغاية: هدفه هو تزويد المراجع ببعض التلميحات الأولية لـ Pull Request عملية قبول (العلاقات العامة):
- سيتم تشغيله طلب سحب (أي كلما تم إنشاء العلاقات العامة)
- يقوم بالخروج من رمز العلاقات العامة (أي الرمز المساهم)
- وسوف تجعل البناء
- سيتم إجراء اختبارات على التعليمات البرمجية المساهمة (على سبيل المثال عن طريق تنفيذ برنامج نصي Shell)
ستفشل الخطوتان رقم 3 (إنشاء الإنشاء) ورقم 4 (تشغيل الاختبار) إذا لم يتم تجميع الكود أو فشل في اجتياز الاختبارات. لذا، فإن هذه الخطوات تعتبر شرطًا ضروريًا، ولكن ليس كافيًا، لقبول العلاقات العامة. في حالة النجاح، سيشرع مسؤول الريبو في مراجعة الكود المُساهم، وبناءً على ذلك، سيقبل/يرفض/يعلق على العلاقات العامة.
ماسح زيجيني
زيجيني يوفر CLI ("ماسح زيجيني") التي يمكن تضمينها في ملف pipeline أو تشغيله في سطر الأوامر. سيقوم الماسح الضوئي Xygeni بمعالجة الملف pipelineللتحقق من الثغرات الأمنية، وإذا تم توفير GitHub PAT، فسوف يتصل بـ GitHub لاكتشاف الثغرات الأمنية على مستوى المؤسسة/الريبو.
مخزون زيجيني
عندما نقوم بتنفيذ Xygeni Scanner على هذا الريبو، فإنه يكتشف مجموعة مفيدة من الأصول (ملف مخزون زيجيني). سيتم ملء المخزون بالعديد من الأنواع المختلفة من CI/CD الأصول، مثل:
- استخدم SCM حيث يتم تخزين الريبو
- استخدم SCM الإضافات المثبتة / المستخدمة
- استخدم مستودع الكود نفسها
- استخدم SCM منظمة حيث ينتمي الريبو
- استخدم CI/CD Pipelineوالوظائف
- استخدم CI/CD تشغيل pipelines
- IaC المصادر المحددة في الريبو
- خارجي تبعيات
- إلخ..
في مثالنا، يمكننا تصفية المخزون حسب نوع الأصول المحدد (SCM- والأصول المرتبطة بـ CICD)، لذلك يمكننا أن نرى أن:
- SCM النظام هو GitHub Cloud
- يتم تخزين Repo في GitHub Cloud وينتمي إلى مؤسسة GitHub محددة
- هناك اثنان pipelineمدعوم بواسطة GitHub (CI/CD النظام)
- كل ما pipeline يحتوي على خطوة واحدة محددة
وذلك باختيار ما سبق pipeline يمكننا أن نرى بعض نقاط الضعف:
- At pipeline المستوى، فهو عرضة لكليهما مباشرة و معدات الوقاية الشخصية غير المباشرة.
يمكننا أن نرى تفاصيل هؤلاء المسمومين Pipeline نقاط الضعف في التنفيذ
اكتشف Xygeni أنه كذلك عرضة لـ D-PPE لأنه تم تشغيله على Pull Request الحدث ولا توجد عناصر تحكم أمان إضافية، لذا يمكن لأي مستخدم مستودع تعديل pipeline وسيتم تنفيذ تلك التعديلات دون أي مراجعة أو موافقة.
وبنفس المعنى، اكتشف Xygeni أيضًا أنه كذلك عرضة لـ I-PPE بسبب استدعاء البرنامج النصي Shell من ملف pipeline: يمكن لأي مستخدم الريبو تعديل البرنامج النصي Shell وسيتم تنفيذ هذه التعديلات دون أي مراجعة أو موافقة.
هل تريد معرفة المزيد؟
استغلال معدات الوقاية الشخصية
لاستغلال معدات الوقاية الشخصية، دعونا نفكر في السيناريو الذي يوجد فيه نوعين من مستخدمي الريبو:
- An المستخدم الداخلي (مطور داخلي يعمل على هذا الريبو)، مع أذونات الكتابة على الريبو
- An مستخدم خارجي (مطور خارجي يعمل على الريبو هذا ولكن مع أذونات القراءة في الريبو)، أي لا يُسمح له بتفرع الريبو ويُجبر على العمل على مفترق الطرق.
لنتخيل أن كلاهما مهاجمين خبيثين (أو ينتحلهما ممثل خبيث). الريبو يحتوي على بعض الأسرار وكلاهما يريد لسرقة سر الريبو وإرسالها إلى خادم يسيطر عليه القراصنة. للقيام بذلك، سوف يستفيدون من المسموم Pipeline نقاط الضعف في التنفيذ pipeline.
في كلتا الحالتين (المستخدم الخارجي والداخلي)، يقومون بفتح Pull Request مع نفس التعديلات:
- استخدم pipeline ويتم تعديل البرنامج النصي شل إلى اقرأ السر من البيئة و إرساله إلى خادم يسيطر عليه القراصنة
التعديلات قد تكون على النحو التالي:
سوف يقوم كلا المستخدمين بإنشاء Pull Request مع التعديلات. عند إنشاء العلاقات العامة، سيقوم GitHub بتنفيذ كلا التعديلين (دون الحاجة إلى مراجعة أو موافقة مسبقة)، مما أدى إلى ما يلي:
نفس الشيء بالنسبة لمستخدمي الكتابة والقراءة، وفي كلتا الحالتين يتم تنفيذ D-PPE وI-PPE، مع اختلاف ذلك مستخدم القراءة غير قادر على الوصول إلى الأسرار. (!!!!)
هذا السبب هو لأنه، في حالة العلاقات العامة القادمة من مفترق الطرق، لا يسمح GitHub بالوصول إلى أسرار الريبو. على الرغم من أن مستخدم القراءة لا يمكنه قراءة الأسرار، إلا أنه لا يزال بإمكانه تشغيل أي برنامج آخر. أحد الأمثلة النموذجية للهجوم هو إنشاء PRs التي تقوم بتنزيل عامل تعدين العملات المشفرة، لذلك سيقوم مشغل GitHub بتنفيذ عامل تعدين العملات المشفرة عند تنفيذ عملية مسمومة pipeline.
هذه ليست بيئة آمنة بالطبع!! ما الذي يمكن أن يفعله مسؤول الريبو لتجنب ذلك؟
بعد بعض البحث على Google، قرر مسؤول الريبو تعديل ملف pipeline ليتم تشغيلها على pull_request_target حدث. لماذا؟ لأن pipelineلا يسمح بالتنفيذ عند pull_request_target pipeline التعديلات، أي بالرغم من أي تعديل من قبل المستخدم "الأصلي" pipeline سيتم تنفيذها.
باتباع مثالنا، سيكون الهجوم هو نفسه كما كان من قبل. ماذا سيحدث بعد ذلك بعد هذا pipeline تعديل؟
كما هو متوقع، لم يتم تنفيذ D-PPE ولكن، لأن I-PPE لا تزال موجودة، أصبح مستخدم القراءة الآن قادرًا على الوصول إلى سر الريبو !!!
ما هو السبب وراء حصول مستخدم القراءة الآن على إمكانية الوصول إلى الأسرار؟ على الرغم من أن pipeline لا يمكن تعديله، فلا يزال من الممكن تعديل البرنامج النصي للصدفة. عندما يكون للـ pipeline يتم تشغيله على pull_request_target، وسيتم تنفيذه في الوضع المميز so سيكون أيضًا نص شل، مما أدى إلى وصول برنامج شل النصي إلى أسرار الريبو !!
اجراءات وقائية
يوفر GitHub بعض التدابير للحماية من العلاقات العامة الضارة.
قواعد حماية الفروع
باستخدام GitHub، يمكنك تحديد قواعد حماية الفروع على الفروع المحددة.
بالنسبة لفروعك المحمية، يمكنك تحديد سياسة ذلك الازعر pull request قبل الدمج (بالإضافة إلى شروط إضافية مثل العدد المطلوب من الموافقات والمراجعات من مالكي الكود وما إلى ذلك)
هناك شرطان يستحقان اهتمامًا خاصًا هما:
- "السماح للجهات الفاعلة المحددة بتجاوز المطلوب pull requests".
- "لا تسمح بتجاوز الإعدادات المذكورة أعلاه"
في حين أن معظم الشروط تضيف صرامة إلى السياسة، فإن هذه الشروط تخفف من السياسة وقد يؤدي ذلك إلى فتح باب للأنشطة الضارة، على سبيل المثال، في حالة سرقة بيانات الاعتماد من قبل الجهات "المميزة".
تقييد أذونات GITHUB_TOKEN (الأقل امتيازًا)
تقييد أذونات رمز GitHub بالأذونات المطلوبة فقط؛ بهذه الطريقة، حتى في حالة نجاح المهاجمين في اختراق بياناتك pipeline، فلن يتمكنوا من فعل الكثير.
تجنب استيفاء السلسلة باستخدام pipeline متغيرات البيئة
عندما تستخدم بعض متغيرات الإدخال في ملف pipeline، انتبه إلى أنه يجب اعتبارها بيانات "غير موثوقة" بشكل افتراضي (يتم التحكم في محتواها من قبل المستخدم النهائي). يرى الإجراءات غير الموثوقة وسير العمل آمن و تعلم إجراءات جيثب.
يجب عليك دائمًا استخدام متغيرات البيئة لإدراج متغيرات الإدخال داخل البرامج النصية بدلاً من استخدام استيفاء السلسلة.
تشغيل سير العمل ومتطلبات الموافقة
في عمل جمهور اتفاقات إعادة الشراء، يسمح GitHub بتحديدها كيفية العمل مع العلاقات العامة "الخارجية"..
تتيح إعدادات مؤسسة GitHub ("المؤسسة >> الإعدادات >> الإجراءات >> عام") تحديد كيفية إدارة العلاقات العامة الخارجية:
بشكل افتراضي، سيطلب GitHub موافقة العلاقات العامة للمساهمين لأول مرة، مما يجعل هجمات الطلبات الضارة أكثر تعقيدًا. ومع ذلك، قد يكتسب المهاجم ثقة المشرفين على المشروع على سبيل المثال من خلال المساهمة ببعض البريئة pull request قبل الهجوم الحقيقي.
في هذا المعنى ، فإن يضيف الخيار الثالث (يتطلب موافقة جميع المتعاونين الخارجيين) مستوى أعلى من التحكم.
في عمل خاص اتفاقيات إعادة الشراء، يوفر GitHub أيضًا تحكمًا مفيدًا على مستوى المنظمة ومستوى الريبو.
"تشغيل سير العمل من Pull Requests"(لم يتم تحديده افتراضيًا) يسمح للمستخدمين بتشغيل سير العمل من PRs fork (باستخدام GITHUB_TOKEN مع أذونات للقراءة فقط وبدون إمكانية الوصول إلى الأسرار). من خلال تحديد هذا الخيار مع الخيار الأخير ("تتطلب الموافقة على سير عمل شوكة العلاقات العامة") ، يمكنك الوصول إلى سياسة مماثلة لسياسة إعادة الشراء الخاصة (كما هو موضح أعلاه).
كما رأينا في استغلال معدات الوقاية الشخصية من مستخدم القراءة، السماح بتشغيل سير العمل من الشوكة pull requests غير آمن!!
الخيارات المتبقية("إرسال رموز الكتابة إلى سير العمل من الشوكة pull requests"و"إرسال الأسرار والمتغيرات إلى سير العمل من أجل pull requests") خفض مستوى الأمان تطبق على شوكة العلاقات العامة.
يمكنك تحديد سياسة الشوكة هذه إما على مستوى المؤسسة أو على مستوى الريبو. إذا تم تعطيل السياسة على مستوى المؤسسة، فلا يمكن تمكينها على مستوى الريبو. ولكن، إذا تم تمكين السياسة على مستوى المؤسسة، فيمكن تعطيلها على مستوى الريبو.
الملخص
نأمل أن تكون قد رأيت الآثار المترتبة على وجود بعض pipeline عرضة للتسمم Pipeline تنفيذ. من السهل جدًا القيام بذلك commit ضعيف pipeline، ومن الصعب أن تكتب واحدة آمنة.
لذا، من المهم جدًا استخدام Xygeni Scanner للتعرف على نقاط الضعف هذه.
لا يمكنك حل الـ Vuln إلا إذا كنت على علم بوجوده !!
ولكن…ما زال هناك سؤال معلق… كيفية تجنب I-PPE؟
وهذا سيكون موضوع مقالتنا القادمة 🙂… التسمم غير المباشر Pipeline التنفيذ (I-PPE) !!
