initstring/lxd_rootتصعيد الامتيازات في لينكس عبر LXD
يتمتع أعضاء مجموعة lxd المحلية على أنظمة لينكس بالعديد من السبل لتصعيد صلاحياتهم إلى صلاحيات الجذر (root). يحتوي هذا المستودع على أمثلة لاستغلالات محلية مؤتمتة بالكامل للحصول على صلاحيات الجذر. شرح مفصّل للثغرة ودليل استغلال خطوة بخطوة متاح في مدونتي هنا.
الاستغلالات أدناه ليست عمليات هروب من الحاويات، بل استغلالات محلية للجذر تستغل الحاويات وتستهدف نظام التشغيل المضيف. يتطلب نجاح الاستغلال وصولًا بصلاحيات منخفضة إلى بيئة المضيف.
أعتقد أن استراتيجيتي مع الإصدار الثاني من الاستغلال فريدة، وكانت مثيرة للاهتمام بدرجة كافية (بالنسبة لي على الأقل) لكتابة شرح مفصل في المدونة المرتبطة أعلاه.
lxd_rootv1.sh بتركيب نظام ملفات المضيف / داخل حاوية، حيث يتمتع المستخدم منخفض الصلاحيات على المضيف بوصول جذر. ينعكس هذا الوصول الجذر على المضيف، مما يسمح بإضافة المستخدم الحالي إلى ملف /etc/sudoers. وقد استغل آخرون هذا الأمر قبلي.lxd_rootv2.py بتركيب مقبس UNIX الخاص بـ systemd التابع للمضيف داخل حاوية ثم يعيد تركيبه على المضيف مرة أخرى عبر أجهزة بروكسي LXD. تمتلك أجهزة البروكسي هذه صلاحيات الجذر، وتمرر بيانات اعتمادها الخاصة أثناء اتصالات المقبس، بدلاً من بيانات اعتماد المستخدم منخفض الصلاحيات الذي بادر بالاتصال. يُساء استغلال هذا الأمر لإنشاء خدمة systemd مؤقتة تضيف المستخدم الحالي إلى ملف /etc/sudoers.يتطلب كلا الاستغلالين حاوية، لذا قم بإنشاء واحدة أولاً. بعد ذلك، شغّل الاستغلال من نظام التشغيل المضيف مع تمرير اسم الحاوية كوسيط أول.
# Exploit with v1
$ bash lxd_rootv1.sh <container name>
# Exploit with v2
$ python3 lxd_rootv2.py <container name>
قبل أن أكتشف هذه المشكلات، لم يكن هناك أي شيء في توثيق LXD الرسمي يحذر المستخدمين من خطورة مجموعة lxd. أي شخص يتبع الإرشادات الرسمية لتكوين LXD كان سيضيف حسابه إلى هذه المجموعة قبل نشر أول حاوية له. فتحت تقرير خطأ لدى Canonical للتعبير عن مخاوفي - يمكنك قراءة السلسلة كاملة هنا. أجرى فريق LXD تعديلات سريعة على التوثيق، الذي ينص الآن بوضوح على أن هذه المجموعة يجب أن تُمنح فقط لمن يُؤتمنون على صلاحيات الجذر.
كما هو الحال دائمًا، كان التفاعل مع فريق Canonical عبر متتبع الأخطاء الخاص بهم تجربة ممتعة حقًا. أود أن أشكرهم على وقتهم وعلى نظرهم المدروس في أفكاري. أوصي بشدة الباحثين الأمنيين الآخرين بنقل الأمور إليهم مباشرة بهذه الطريقة.
لست أول شخص يستغل LXD. لقد أُثيرت هذه المسألة كمصدر قلق في عدة تذاكر على GitHub يعود تاريخها إلى عام 2016:
صاحب الرابط الأول هو أول شخص (simpoir) حدد هذا الخطر، على حد علمي.
كتب @reboare مدونة رائعة حول استغلال LXD باستخدام نفس أسلوب استغلالي في الإصدار الأول، قبل وقت طويل من قيامي بذلك:
شكرًا لفريق LXD على صنع أداة رائعة جدًا. أنا شخصيًا أستخدم LXD وأعجب به كثيرًا. لا أعتقد أن هذا يشكل عائقًا أمام استخدام LXD، بل أعتقد أنه من المهم جدًا فهم الخطر المحتمل عند إضافة مستخدمين إلى مجموعة lxd.
لا يوجد إصلاح رسمي لأي من هاتين الثغرتين. يجب أن يدرك أي شخص يستخدم LXD أن إضافة مستخدمين إلى مجموعة lxd هو في الأساس منحهم صلاحيات الجذر.
إذا كنت تستخدم LXD على مضيف أحادي المستخدم، مثل جهاز مكتبي، فقد يكون من الأفضل عدم استخدام مجموعة lxd إطلاقًا وتشغيل sudo عندما تحتاج إلى التواصل مع واجهة برمجة التطبيقات (API).
بالنسبة للبيئات المشتركة التي يعمل فيها عدة أشخاص على حاويات، قد يكون من الأفضل إنشاء بيئات متداخلة. سيتمكن كل مستخدم فردي من مجموعة LXD من استغلال بيئته الخاصة، لكنه سيحتاج بعد ذلك إلى بذل جهد أكبر للخروج من تلك الحاوية لاستغلال الحاويات الأخرى.