
ثغرة CVSS 10.0 في LXD وMicroCloud تتيح انتحال هوية عملاء موثوقين
أصلحت Canonical ثغرة CVSS 10.0 في LXD وMicroCloud تتيح لمن يملك الشهادة العامة لعميل موثوق ووصولًا إلى واجهة HTTPS API تسجيل الدخول كعميل موثوق دون مفتاح ذلك العميل الخاص.
أصدرت Canonical إصدارات مصححة من LXD وMicroCloud لثغرة حرجة تتيح للمهاجم تسجيل الدخول كعميل موثوق دون امتلاك المفتاح الخاص لذلك العميل. وتُتتبع الثغرة باسم CVE-2026-112816، وتحمل درجة CVSS قدرها 10.0، وتتطلب وصولاً شبكيًا إلى واجهة HTTPS API إضافة إلى الشهادة العامة للعميل الموثوق. وإذا كان الحساب المُنتحل ذا صلاحيات، فقد يحصل المهاجم على وصول root إلى جهاز المضيف، وفق Canonical.
كيف تعمل الثغرة
تتيح LXD وMicroCloud لعملاء عن بُعد الوصول إلى واجهات برمجة التطبيقات (API) عبر TLS متبادل، حيث يعرض العميل شهادة لإثبات هويته. ويُعد العميل موثوقًا عندما تكون شهادته في مخزن ثقة الخادم. كانت الثغرة في طريقة فحص الخادم لتلك الشهادة: قارن كل شهادة يرسلها العميل مع مخزن الثقة، لكن اتصال TLS يثبت فقط أن العميل يملك المفتاح الخاص لأول شهادة في السلسلة، وهي شهادة الورقة (leaf). أما بقية السلسلة فهي ما يختار العميل إرفاقه، لذا يمكن للمهاجم أخذ الشهادة العامة لعميل موثوق، وهي ليست سرية، وإرفاقها خلف شهادته الخاصة، ثم قبوله كأنه ذلك العميل.
من يتأثر
لاستخدام الثغرة لازمان: وصول شبكي إلى واجهة HTTPS API، والشهادة العامة لعميل يثق به الخادم بالفعل. لا يعرض خادم LXD مستقل واجهة API تلك افتراضيًا؛ إنه يستمع فقط على مقبس محلي ما لم يفعّل مسؤول واجهة API الشبكية عبر إعداد core.https_address. MicroCloud، الذي يربط عدة أجهزة تشغّل LXD في عنقود واحد، لديه نقطة ضعف محددة: قالت Canonical إن مهاجمًا يمكنه التقاط الشهادة العامة لعضو أثناء انضمامه إلى العنقود يمكنه ثم تسجيل الدخول كأنه ذلك العضو. يذكر سجل CVE إصدارات LXD 4.0.14 و5.0.10 و5.21.8 و6.9 كمتأثرة، وكل منها قبل الإصدار المصحح الذي يليه.
الإصدارات المصححة
تسرد Canonical إصدارات snap المصححة التالية: LXD 6/stable 6.10.1، LXD 5.21/stable 5.21.9، LXD 5.0/stable 5.0.11، LXD 4.0/stable 4.0.15، MicroCloud 3/stable 3.4.1، وMicroCloud 2/stable 2.1.5. لم تنشأ الثغرة في Canonical: مشروع Incus، الذي بدأ كنسخة مجتمعية (fork) من LXD، أبلغ عنها، وأكّدت Canonical أنها أثّرت في LXD أيضًا. أصلح Incus الثغرة نفسها في الإصدار 7.6.0. حزم أرشيف Ubuntu الخاصة بـ LXD مدرجة على أنها غير متأثرة أو غير مشحونة، لذا الإصدارات المصححة هي snaps. لا يوجد مؤشر علني على أن الثغرة استُخدمت في هجوم. يحمل سجل CVE تقييمًا من CISA (الولايات المتحدة)، مؤرخًا 30 أكتوبر، بأن الثغرة غير معروفة بأنها استُغلت؛ وهي ليست في قائمة CISA للثغرات المستغلة المعروفة، ولم يُنشر أي استغلال فعّال.
ماذا تفعل
حدّث LXD وMicroCloud إلى الإصدارات المصححة. في تثبيت snap، شغّل sudo snap refresh lxd و sudo snap refresh microcloud. قالت Canonical إن إصدارات LXD النقطية المصححة كانت لا تزال تُطرح من قناة candidate إلى stable وقت استشارتها، لذا تحقق من الإصدار الذي لديك فعلًا بعد التحديث بدلًا من افتراض أن الإصلاح وصل. لا تقدم استشارة Canonical أي حل مؤقت لـ LXD. ولأن الهجوم يتطلب وصولًا شبكيًا إلى API، فإن تقييد من يمكنه الوصول إليه يقلل المخاطر حتى التحديث. قال مشروع Incus، الذي أبلغ عن الثغرة نفسها، إنه لا يوجد إصلاح عبر الإعدادات، وأن الخطوة الوحيدة هي تقييد الوصول الشبكي إلى listener. يجب على مستخدمي Incus الانتقال إلى 7.6.0، الذي أصلح هذه الثغرة مع 17 مشكلة أمنية أخرى.
المصادر: The Hacker News
SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي
نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.