ثغرة أرغو سي دي غير مرقعة قد تسمح لمهاجمين بتنفيذ أوامر عن بُعد والسيطرة على بيئات Kubernetes إذا تمكنوا من الوصول إلى خدمة repo-server.
ما هي ثغرة أرغو سي دي الجديدة؟
تكشف التفاصيل عن خلل أمني خطير في مكوّن repo-server داخل Argo CD، وهي منصة شائعة لإدارة ونشر التطبيقات على Kubernetes. الخطورة هنا أن الهجوم لا يحتاج إلى تسجيل دخول، بل يكفي وصول المهاجم إلى المنفذ الداخلي الخاص بالخدمة.
وبحسب ما رصده تيكبامين، فإن المشكلة لم تحصل حتى الآن على CVE رسمي، كما لا يتوفر لها تحديث أمني يعالجها بشكل كامل. ورغم الإبلاغ عنها في يناير 2025، بقيت دون إصلاح لنحو 18 شهراً.
أين تكمن نقطة الضعف؟
يقوم repo-server بقراءة مستودعات Git ثم بناء ملفات manifests التي تحدد ما الذي سينشره Kubernetes داخل العنقود. لكن خدمة gRPC الداخلية الخاصة به تفتقر إلى المصادقة، ما يسمح بتمرير طلبات خبيثة لتنفيذ أوامر على الخادم.
- المكوّن المتأثر: repo-server
- الإصدار الذي تم اختباره: Argo CD v2.13.3
- نوع الخطر: تنفيذ أوامر عن بُعد
- الحالة الحالية: لا يوجد تصحيح رسمي
كيف يمكن استغلال ثغرة أرغو سي دي؟
يعتمد السيناريو على أداة kustomize التي يستخدمها Argo CD لتحويل ملفات المستودع إلى manifests قابلة للنشر. هذه الأداة تدعم خيار --helm-command لتحديد الملف التنفيذي الذي تستدعيه بدلاً من Helm.
المهاجم يستطيع عبر طلب غير موثّق إلى خدمة GenerateManifest تمرير سكربت خبيث موجود في مستودع Git يسيطر عليه. وعند تشغيل kustomize، يتم تنفيذ السكربت مباشرة، ما يفتح الباب أمام السيطرة على repo-server.
لماذا لا تكفي كلمة “داخلي” للحماية؟
نظرياً، توفّر Argo CD سياسات شبكة Kubernetes لعزل repo-server عن بقية المكوّنات. لكن المشكلة أن تثبيت المنصة عبر Helm Chart الشائع يترك هذا العزل معطلاً افتراضياً عندما تكون networkPolicy.create مضبوطة على false.
- إذا تم اختراق Pod واحد داخل العنقود، قد يصبح الوصول إلى repo-server ممكناً
- غياب العزل الشبكي يرفع مستوى الخطر بشكل كبير
- بيئات النشر الافتراضية قد تكون أكثر عرضة للهجوم
هل يمكن للمهاجم السيطرة على Kubernetes بالكامل؟
الخطر لا يتوقف عند تنفيذ الأوامر على repo-server فقط. بعد الوصول، يمكن للمهاجم قراءة كلمة مرور Redis الخاصة بـ Argo CD من متغيرات البيئة، ثم استخدامها لتلويث بيانات النشر المخزنة داخل الذاكرة المؤقتة.
هذا السيناريو يعيد إحياء أثر ثغرة CVE-2024-31989 بشكل غير مباشر. فحتى بعد إضافة كلمة مرور لـ Redis في السابق، ما تزال البيانات داخل الكاش غير موقعة رقمياً، ما يعني أن سرقة كلمة المرور قد تعيد نفس مسار الهجوم عند أول مزامنة تلقائية.
كيف تحمي أنظمة Kubernetes من هذه الثغرة؟
حتى لحظة كتابة هذا التقرير، لا توجد نسخة مرقعة تسد ثغرة أرغو سي دي. لذلك يبقى الحل العملي هو تفعيل سياسات الشبكة في Kubernetes بحيث لا يتمكن من الوصول إلى repo-server وRedis إلا مكوّنات Argo CD المصرح لها فقط.
- تفعيل Network Policies فوراً
- عزل منافذ repo-server وRedis عن بقية الحاويات
- مراجعة إعدادات Helm Chart الافتراضية قبل النشر
- تقييد حركة East-West داخل العنقود
الخلاصة أن ثغرة أرغو سي دي تمثل تهديداً مباشراً لبيئات Kubernetes، خصوصاً في الشركات التي تعتمد الإعدادات الافتراضية. ولهذا ينصح تيكبامين بمراجعة العزل الشبكي فوراً بدل انتظار تحديث قد يتأخر أكثر.
