هجمات سلسلة التوريد السحابية السرية: دراسة حالة ودروس لفرق الأمان

تعد إدارة الأسرار وبيانات الاعتماد تحديًا صعبًا في البيئات السحابية المعقدة التي تواجه الإنترنت.

على مدار بحثنا الأخير حول الثغرات الأمنية في موفر الخدمة السحابية، اكتشفنا ثلاثة أنماط تكوين خاطئة تم التغاضي عنها والتي تعرض البيئات السحابية لمخاطر هجوم سلسلة توريد CI/CD. تتيح هذه التكوينات الخاطئة للجهات الفاعلة الخبيثة تنفيذ حركة جانبية ومعالجة التعليمات البرمجية المصدر من أجل التلاعب بعناصر المؤسسات ونشر التعليمات البرمجية الضارة إلى الخدمات الداخلية أو العملاء الخارجيين.

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

لماذا تعتبر خطوط أنابيب CI/CD أهدافًا قيمة للمهاجمين؟

إن خط أنابيب CI/CD عبارة عن مجموعة من الممارسات والأدوات التي تساعد المؤسسات على تطوير وبناء ونشر برامج عالية الجودة لمستخدميها بسرعة وكفاءة مع تقليل مخاطر الأخطاء والأخطاء.

يتضمن مسار CI/CD عادةً الخطوات التالية:

• تتم كتابة التعليمات البرمجية من قبل المطورين ويتم الالتزام بها من خلال نظام التحكم في الإصدار، مثل Git.

• يتم إنشاء التعليمات البرمجية واختبارها تلقائيًا باستخدام أدوات التكامل المستمر (CI)، مثل Jenkins وCircleCI.

• يتم تعبئة التعليمات البرمجية المضمنة تلقائيًا ونشرها في بيئة مرحلية للاختبار والتحقق من الصحة.

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

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

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

التكوينات الخاطئة الشائعة لـ CI/CD وكيفية تجنبها

على مدار بحثنا حول البيئات السحابية، حددنا التكوينات الخاطئة السائدة في CI/CD والتي تميل إلى التغاضي عنها من قبل ممارسي الأمن وقمنا بتجميعها في قائمة تتضمن خطوات الإصلاح الموصى بها.

نظرًا لأن المهاجمين غالبًا ما يستغلون العديد من العيوب الأمنية لاختراق مكون CI/CD، فإن مجرد معالجة إحدى المشكلات التالية يمكن أن يقلل بشكل كبير من سطح الهجوم في مؤسستك.

1. الوصول المفرط إلى سجلات الحاويات

يتم نشر سجلات الحاويات بشكل شائع في البيئات السحابية المعبأة في حاويات لتخزين صور الحاويات المستخدمة في مرحلتي الإنشاء والإنتاج. يمكن سحب هذه الصور الخاصة باستخدام بيانات اعتماد تسجيل الحاوية التي غالبًا ما تكون موجودة في نظام الملفات الخاص بالمثيلات الموجودة في الحاوية.

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

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

مثال لتدفق الهجوم:

• يقوم أحد المهاجمين باختراق خادم متصل بالإنترنت داخل بيئة حاوية

• يجدون بيانات اعتماد تسجيل الحاوية في نظام الملفات

• إنهم يستفيدون من بيانات الاعتماد لجلب صور خاصة إضافية من السجل

• أنها تصيب الصور مع التعليمات البرمجية الضارة

الحل: أقل امتيازات الوصول إلى سجلات الحاويات

تأكد من أن حلول تسجيل الحاويات الخاصة بك تطبق ضوابط الوصول والنطاق المناسبين. في حين أن معظم موفري الخدمات السحابية يوفرون إدارة أذونات التسجيل عبر هويات IAM، فإن موفري SaaS يقدمونها عادةً من خلال واجهة الويب الخاصة بالخدمة أو واجهة برمجة التطبيقات (API).

تعيين read-only أو write-only امتيازات الأدوار، وتقييد تلك pull و push أذونات فقط للمستودعات والصور التي يحتاجون إليها. على سبيل المثال، لا يحتاج المطورون إلى أذونات الكتابة حيث لا ينبغي عليهم دفع الصور مباشرة إلى السجلات أو الخدمات الموجودة في حاويات والتي تعمل على تنسيقات الحاوية. أما بالنسبة للأدوار مع push الأذونات، يجب أن يشاركوا فقط في المرحلة الأخيرة من مسار CI/CD لدفع الصور النهائية إلى السجل.

بالإضافة إلى ذلك، تجنب منح إذن موارد القائمة للتطبيقات وعمليات التشغيل الآلي التي تستخدم سجلات الحاويات لمنع المهاجم من إجراء الاستطلاع ومعرفة المستودعات التي يمكن الوصول إليها.

دراسة الحالة: وصول حساب خدمة Pod إلى سجلات الحاويات

من أجل سحب الصور الخاصة، يجب أن تتمتع عقدة Kubernetes بإمكانية الوصول إلى سجل الحاوية الذي تم تخزينها فيه. تم العثور على بيانات الاعتماد الخاصة بتسجيل الحاوية هذا في مورد سري. يتم ذكر اسم السر في كل تكوين جراب imagePullSecrets مجال.

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

مثال لتدفق الهجوم:

• يقوم أحد المهاجمين باختراق حجرة في تطبيق يواجه الإنترنت

• لقد وجدوا رمزًا مميزًا لحساب خدمة Kubernetes في نظام الملفات

• يستخدمون الرمز المميز لجلب سر تسجيل الحاوية من المجموعة

• إنهم يستفيدون من بيانات الاعتماد لجلب صور خاصة إضافية من السجل

• أنها تصيب الصور مع التعليمات البرمجية الضارة

الحل: تقييد الوصول إلى حساب خدمة pod والامتيازات

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

2. الأسرار المنسية في عملية البناء

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

أثناء بحثنا، وجدنا أسرارًا حساسة في مواقع مختلفة تم تجاهلها، بما في ذلك ملفات سجل Linux bash والطبقات الأساسية لصور الحاوية. قد تظهر بعض الأسرار في طبقة الصورة ولكنها ستكون مخفية في نظام الملفات المضغوط النهائي. يمكن لهذه الأسرار المنسية أن تسمح للمهاجم بإجراء حركة جانبية ثم تنفيذ تعليمات برمجية عن بعد للتلاعب بعمليات إنشاء الصور.

مثال لتدفق الهجوم:

• يقوم أحد المهاجمين باختراق خادم متصل بالإنترنت

• يجدون بيانات اعتماد CI/CD في ملف .bash_history الملف الذي كان من عملية إنشاء صورة نظام التشغيل

• يمنح السر إمكانية الوصول إلى مجموعة تخزين داخلية تحتوي على عناصر جاهزة للإنتاج تُستخدم في عملية الإنشاء

• يقوم المهاجم بتعديل القطع الأثرية لنشر التعليمات البرمجية الضارة في الإصدارات التالية

مثال لتدفق الهجوم 2:

• يقوم المهاجم بجلب صور الحاويات المتاحة للعامة من سجل الحاويات العام للشركة

• وجدوا أسرارًا حساسة في ملفات تاريخ الحاويات

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

• يحتوي دلو التخزين على عناصر جاهزة للإنتاج تُستخدم في عملية إنشاء الصور

• يقوم المهاجم بتعديل القطع الأثرية الموجودة في المجموعة لنشر تعليمات برمجية ضارة في تصميمات الصور

الحل: مسح شامل للأسرار التي يحتمل أن تكون منسية

لمنع المهاجمين من الحصول على أسرار حساسة، يجب على مؤسستك تنفيذ فحص منتظم لبيئاتك وعناصر الإنتاج الخاصة بك بحثًا عن الأسرار في المرحلة النهائية من كل بناء قطعة أثرية. ويمكن القيام بذلك باستخدام المنتجات ذات الصلة أو الأدوات مفتوحة المصدر مثل Trufflehog.

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

• سجلات AWS SSM — /var/log/amazon/ssm/*

• تاريخ باش —~/.bash_history أو /root/.bash_history 

• ملفات مجلة Linux — /var/log/journal/*

من خلال اتخاذ هذه الخطوات، يمكنك حماية عناصرك والحفاظ على أمان خطوط أنابيب CI/CD الخاصة بك.

3. مسارات الحركة الجانبية بين بيئات الإنتاج والبناء الداخلي

يمكن أن يوفر الاتصال بين تطبيقات المنظمة التي تواجه الإنترنت ومكونات CI/CD الداخلية للخصوم القدرة على تنفيذ الحركة الجانبية.

في هجوم Hell’s Keychain، سمح عدم وجود ضوابط كافية للشبكة للباحثين بالوصول إلى مستودع CI/CD الداخلي. لا يعد هذا التكوين الخاطئ فريدًا بالنسبة إلى IBM Cloud، حيث تمت ملاحظته عبر العديد من موفري الخدمات السحابية وعملائهم. من وجهة نظرنا، غالبًا ما يتم التغاضي عن هذه المشكلة في مناقشات الصناعة وحلول الأمان السحابية.

مثال لتدفق الهجوم:

• يقوم أحد المهاجمين باختراق خادم متصل بالإنترنت

• يجدون أسرارًا حساسة في .bash_history الملف الذي كان من عملية إنشاء صورة نظام التشغيل

• السر يمنح الوصول إلى دلو التخزين الداخلي

• يحاول المهاجم الاتصال بدلو التخزين

• لقد فشلت بسبب سياسة الموارد المقيدة، والتي تسمح فقط بالاتصالات من الشبكة الافتراضية الخاصة CI/CD

الحل: الأصول الهامة المعزولة

يمكن أن يؤدي تنفيذ سياسات الشبكة القوية وفرض تجزئة السحابة إلى حماية مؤسستك من هذا النوع من هجمات سلسلة التوريد CI/CD. من المهم أيضًا مراقبة مفاتيح الوصول إلى السحابة في البيئات التي تواجه الإنترنت والتحقق من أنها لا تمنح الوصول إلى بيئات CI/CD. علاوة على ذلك، يجب أن تقتصر الهويات السحابية ومستودعات التخزين على شبكة CI/CD الافتراضية.

في حالات حلول SaaS CI/CD مثل GitHub حيث يكون من المستحيل تقييد الوصول إلى الشبكة، فمن الضروري عدم تخزين بيانات اعتماد الخدمة أو رمز الوصول في التطبيقات التي تواجه الإنترنت. إذا تمكن أحد المهاجمين من اختراق مثل هذا التطبيق، فسيكون قادرًا على تجاوز جميع قيود الشبكة والوصول مباشرة إلى الخدمة التي تحتوي على رمز الإنتاج والتحف.

أخيرًا، يجب أن تفكر في اعتماد إجراءات أمنية مثل المصادقة الثنائية وعناصر التحكم في الوصول المستندة إلى الدور لحماية حلول SaaS CI/CD الخاصة بك.

ملخص

تعد خطوط أنابيب CI/CD جزءًا أساسيًا من عملية تطوير البرامج، مما يمكّن المؤسسات من تقديم برامج عالية الجودة بسرعة وبشكل مستمر. ومع ذلك، تعد خطوط الأنابيب هذه هدفًا جذابًا للمهاجمين الضارين: يمكن أن يؤدي مكون واحد مخترق إلى تعريض بيئات واشتراكات متعددة للخطر.

في منشور المدونة هذا، قمنا بوصف التكوينات الخاطئة الشائعة لخطوط أنابيب CI/CD وقدمنا ​​نصائح حول كيفية معالجتها لمنع هجمات سلسلة التوريد. تتضمن هذه التكوينات الخاطئة الوصول إلى سجل الحاوية ذي الامتيازات الزائدة، والأسرار المنسية، والارتباط بين بيئة الإنتاج وCI/CD. يمكن أن يؤدي تنفيذ واحدة فقط من أفضل الممارسات المذكورة أعلاه إلى تقليل مساحة الهجوم في مؤسستك بشكل كبير وحماية سلسلة توريد البرامج الخاصة بك.