Tim Shephard

يمكن تقديم الرموز المميزة التي يتم الحصول عليها من خلال آليات المصادقة المفوضة — مثل رموز الوصول OAuth1 أو بيانات اعتماد التطبيقات أو علاقات الثقة — إلى مسار المصادقة «token-method» لإعادة المصادقة. وهذا يسمح للمهاجم بالخروج عن نطاق المشروع المقصود. وعلى وجه التحديد، عندما يتم تقديم رمز اعتماد تطبيق دون نطاق صريح، يصدر النظام رمزًا جديدًا يقتصر نطاقه على المشروع الافتراضي لمالك بيانات الاعتماد بدلاً من المشروع الذي صدرت بيانات الاعتماد من أجله في الأصل، مما يؤدي إلى تجاوز حدود المشروع.

يفشل خادم الوكيل في إزالة رؤوس التحديث الداخلية من طلبات العملاء قبل إعادة توجيهها إلى خوادم الكائنات. يمكن للمستخدم المصادق عليه الذي يتمتع بحق الكتابة إدخال الرؤوس `X-Container-Host` و`X-Container-Device` و`X-Delete-At-Host` و`X-Delete-At-Device` لإعادة توجيه طلبات تحديث الحاويات إلى خادم يتحكم فيه المهاجم، مما يؤدي إلى تزوير الطلبات من جانب الخادم (SSRF). وهذا يسمح بكشف البيانات الوصفية الداخلية للمجموعة، مثل فهارس سياسات التخزين، وتعيينات الأقسام، وأسماء الأجهزة، وعندما يكون التشفير أثناء التخزين نشطًا، النص المشفر ومتجهات التهيئة لمفتاح التشفير على مستوى الحاوية. بالإضافة إلى ذلك، يمكن استخدام آلية إعادة التوجيه لنطاق الشرائح لإنشاء قوائم وهمية في حاويات عشوائية.

يقوم OpenStack Horizon بإنشاء نصوص برمجية لتنزيل ملفات OpenStack RC قد تحتوي على اسم مشروع مُعدّ خصيصًا يتضمن أحرفًا خاصة في شل. الأحرف الخاصة في شل هي أحرف خاصة تفسرها شل سطر الأوامر لتنفيذ إجراءات محددة، مما قد يؤدي إلى تنفيذ أوامر غير مقصودة في حالة عدم التعامل معها بشكل صحيح.

يفشل برنامج تشغيل RabbitMQ في oslo.messaging في إجراء التحقق من اسم مضيف TLS عند الاتصال بوسيط الرسائل. وعلى الرغم من أن برنامج التشغيل يتيح التحقق من صحة سلسلة الشهادات عند تكوين `ssl ca file`، إلا أنه لا يمرر اسم مضيف الوسيط المتوقع إلى مكدس TLS. ونتيجة لذلك، يتم قبول أي شهادة موقعة من قبل سلطة التصديق (CA) الخاصة بالنشر بغض النظر عن اسم المضيف. وهذا يسمح للمهاجم القادر على اعتراض حركة مرور مستوى التحكم (control-plane) بانتحال صفة وسيط RabbitMQ وتنفيذ هجوم «الرجل في الوسط» (man-in-the-middle) على حركة مرور RPC والإشعارات. تتأثر جميع خدمات OpenStack التي تستخدم oslo.messaging مع RabbitMQ عبر TLS.

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

توجد مشكلة تتمثل في أن نقطة النهاية ’POST /v3/credentials‘ تفشل في التحقق من أن `project id` الذي يقدمه المستدعي لبيانات اعتماد من نوع EC2 يتطابق مع المشروع الخاص ببيانات اعتماد التطبيق الذي يقوم بالمصادقة. وهذا يسمح للمهاجم الذي يمتلك بيانات اعتماد تطبيق غير مقيدة لمشروع واحد بإنشاء بيانات اعتماد EC2 تستهدف مشروعًا مختلفًا. ومن ثم، يمكن أن يؤدي التبادل اللاحق عبر ’/v3/ec2tokens‘ إلى إصدار رمز Keystone يقتصر نطاقه على المشروع المستهدف مع الاحتفاظ بـ `app cred id` الأصلي، مما يتيح التنقل الأفقي عبر المشاريع ضمن نطاق دور مالك بيانات الاعتماد.