كشفت أبحاث ويز com.CosmosEscape، ثغرة أمنية خطيرة في خدمة قاعدة بيانات Azure الرئيسية، Azure Cosmos DB، عبر Gremlin API. كان من الممكن استغلال الثغرة الأمنية لاختراق كل قاعدة بيانات في الخدمة، بما في ذلك قواعد البيانات الداخلية الخاصة بشركة Microsoft – مما قد يؤدي إلى تمكين هجوم عبر الخدمات.
من خلال CosmosEscape، كان من الممكن أن يحصل المهاجمون على ما أطلقنا عليه اسم مفتاح الكون الرئيسي – سر على مستوى النظام الأساسي يمنح قدرتين قويتين بشكل لا يصدق:
-
الاستيلاء – استرداد المفتاح الأساسي لأي حساب Cosmos DB عند الطلب، مما يؤدي إلى الوصول الكامل للقراءة والكتابة.
-
تعداد – سرد جميع قواعد البيانات الموجودة على الخدمة مع إمكانية التصفية حسب معرفات مؤسسة محددة مثل معرفات الاشتراك والمستأجر.
ومن الممكن أن تؤدي هذه القدرات، المتسلسلة معًا، إلى تمكين الاستهداف الدقيق على نطاق النظام الأساسي: بدءًا من تحديد قواعد بيانات مؤسسة معينة وحتى اختراقها، وكل ذلك من نقاط نهاية يمكن الوصول إليها بشكل عام.
يتم استخدام Cosmos DB داخليًا عبر Microsoft – حيث تقوم خدمات مثل Microsoft Entra ID وMicrosoft Teams وMicrosoft Copilot بتخزين البيانات في Cosmos DB. ومن المحتمل أن يكون من الممكن الوصول إلى قواعد بياناتهم عبر هذه الثغرة الأمنية.
قامت Microsoft الآن بمعالجة المشكلة بالكامل، بما في ذلك إزالة Cosmos Master Key. قدمت Microsoft أيضًا حواجز حماية جديدة إلى Cosmos DB لمنع الهجمات المماثلة.
وقد تم دعم هذا البحث من خلال إصدار مبكر من Atlas، وهو الباحث في ثغرات الذكاء الاصطناعي لدينا. نتوقع المزيد من أطلس قريبا.
قامت Microsoft بمعالجة هذه المشكلة بشكل كامل. لا يلزم اتخاذ أي إجراء من جانب العميل. أجرت Microsoft تحقيقًا شاملاً ولم تجد أي دليل على استغلال هذه الثغرة الأمنية بخلاف البحث الموضح في هذه المدونة.
يدعم Cosmos DB واجهات برمجة التطبيقات المتعددة للاستعلام، ومن بينها Gremlin، وهي لغة استعلام بيانية شائعة:
// Find all users over 30 and return their friends' names
g.V().hasLabel('user').has('age', gt(30)).out('knows').values('name')أثناء تشغيل استعلامات Gremlin ضد Cosmos DB، لاحظنا استثناءً مريبًا لـ .NET. نظرًا لأن معظم مكدسات Gremlin مفتوحة المصدر تعتمد على JVM، فقد أشار الاستثناء إلى أن Cosmos DB كان يستخدم محرك جريملين مخصص. كان هذا مثيرًا للاهتمام – على عكس SQL القياسي، حيث يقوم المحرك بتعيين الاستعلامات إلى مجموعة ثابتة من العمليات المضمنة، غالبًا ما تقوم خوادم Gremlin بتجميع الاستعلامات في تعليمات برمجية قابلة للتنفيذ وتشغيلها في بيئة مقيدة. تاريخيًا، لم تكن صناديق الرمل هذه صامدة بشكل جيد. لقد اشتبهنا في أن وضع الحماية Gremlin الخاص بـ Cosmos DB قد يكون ضعيفًا أيضًا.
وكان. قام محرك Cosmos DB بترجمة استعلامات Gremlin إلى كود .NET، مما أدى إلى فرض مجموعة من القيود المصممة لمنع الاستعلامات من الوصول إلى ما هو أبعد من عمليات Gremlin. ومع ذلك، فإن هذه القيود لم تأخذ في الاعتبار بشكل كافٍ انعكاس .NET – مما يسمح لنا بتطوير قراءة الملفات وكتابتها، وفي النهاية أساسيات تنفيذ التعليمات البرمجية التعسفية، كل ذلك من خلال الاستعلامات مقابل قاعدة البيانات الخاصة بنا.
توضح الصورة التالية مخرجات استعلام Gremlin المصمم خصيصًا والذي تم تشغيله على قاعدة البيانات الخاصة بنا، مما أدى إلى تنفيذ الأمر “اسم المضيف” على الواجهة الخلفية لقاعدة بيانات Cosmos:
من خلال تجاوز وضع الحماية Gremlin، حصلنا على تنفيذ التعليمات البرمجية على بوابة قاعدة البيانات، وهي خدمة تنفذ استعلامات العملاء نيابةً عنهم، وتعمل على مجموعات Service Fabric متعددة المستأجرين.
وبالنظر حولك، لم تتم استضافة قواعد بيانات العملاء في هذه المجموعات، ولكن لا يزال يتعين على بوابة قاعدة البيانات الوصول إليها بطريقة ما. وتبين أنه فعل ذلك مثلما يفعل أي عميل Cosmos DB – باستخدام المفتاح الأساسي للحساب المستهدف، والذي يمنح الوصول الكامل للقراءة والكتابة إلى قواعد بيانات الحساب.
ولكن كيف يمكن لـ DB Gateway استرداد المفتاح الأساسي لحساب Cosmos DB الخاص بنا؟
مفتاح الكون الرئيسي
من خلال بيانات الاعتماد المتوفرة في المجموعة، تمكنت بوابة قاعدة البيانات من الوصول إلى مفتاح التوقيع الذي يمكنه استرداد المفتاح الأساسي للحساب المطلوب.
وسرعان ما اكتشفنا مفتاح التوقيع لم يكن نطاقها لحساب واحد. لقد نجح هذا النظام عبر المستأجرين والمناطق وحتى إصدارات واجهة برمجة التطبيقات (API) – SQL وMongoDB وCassandra وGremlin. لقد كان مفتاحًا على مستوى النظام الأساسي يمكنه استرداد المفتاح الأساسي لأي حساب Cosmos DB على الخدمة، كل ذلك من خلال نقاط نهاية يمكن الوصول إليها بشكل عام. لقد أطلقنا عليه اسم مفتاح الكون الرئيسي.
متجر التكوين – دليل حسابات Cosmos DB
قام المفتاح الرئيسي أيضًا بفتح قفل متجر التكوين: سجل إقليمي لكل حساب Cosmos DB – يحتوي على أسماء الحسابات ومعرفات الاشتراك ومعرفات المستأجر وإعدادات الشبكة والعلامات والمزيد. اعتمدت بوابة قاعدة البيانات عليها في إعدادات الحساب، مثل عناوين IP المسموح لها بالوصول إلى قاعدة البيانات.
كان متجر Config Store بحد ذاته عبارة عن قاعدة بيانات Cosmos DB، مما يعني أنه يمكن الاستعلام عنها بالمرونة الكاملة لمحرك SQL الخاص بـ CosmosDB. ويعني ذلك أيضًا أن مفتاح Cosmos Master Key يمكنه استرداد مفتاحه الأساسي، مما يمكّن المهاجمين الذين استغلوا CosmosEscape من إدراج جميع الحسابات في منطقة ما، أو الاستعلام عن طريق معرف مستأجر محدد لتحديد قواعد بيانات مؤسسة معينة.
معًا، قام Cosmos Master Key وConfig Store بتمكين سلسلة هجوم قوية:
-
استعلم عن ConfigStore لتعداد جميع حسابات Cosmos DB في منطقة ما، أو قم بالتصفية حسب المستأجر أو الاشتراك لاستهداف مؤسسات محددة.
-
استخدم مفتاح Cosmos الرئيسي لاسترداد المفتاح الأساسي للهدف، ومنح حق الوصول الكامل للقراءة والكتابة إلى جميع قواعد البيانات الخاصة به.
أثر هذا على أكثر من مجرد قواعد بيانات العملاء. يعمل Cosmos DB كبنية أساسية أساسية للعديد من خدمات Microsoft وAzure – مما يعني أن قواعد البيانات الداخلية الخاصة بشركة Microsoft قد تم الكشف عنها بالتساوي.
أثر CosmosEscape أيضًا على حسابات Cosmos DB الخاصة والمعزولة بالشبكة. نظرًا لأن بوابة قاعدة البيانات مسؤولة عن فرض عزل الشبكة، فإن اختراقها يسمح بالوصول المباشر إلى قواعد البيانات الخاصة. علاوة على ذلك، يشير الوصول للكتابة إلى Config Store إلى احتمالية قيام مهاجم بالكتابة فوق إعدادات عزل الشبكة.
تم بناء المنصات السحابية في طبقات. توجد خدمات مثل Cosmos DB في طبقة البنية التحتية – حيث تعمل على تشغيل العروض ذات المستوى الأعلى مثل Microsoft Teams وMicrosoft Entra ID وMicrosoft Copilot. يمكن أن تتصاعد الثغرة الأمنية في هذه الطبقة إلى أعلى وتهدد الخدمات المبنية فوقها.
تتطلب الخدمات السحابية متعددة المستأجرين حد عزل قوي واحدًا على الأقل حول التنفيذ الذي يتحكم فيه المستأجر – وهو الحد الذي يكشف فقط عن سطح هجوم صغير ومدقق بشكل كبير. يجب التعامل مع كل شيء داخل تلك الحدود على أنه خاضع لسيطرة المستأجر وغير موثوق به. من الناحية المثالية، يجب رسم الحدود بإحكام حول بيئة المستأجر: كلما قل عدد الموارد التي تحتوي عليها، أصبح من الأسهل ضمان بقاء بيانات الاعتماد المميزة وواجهات برمجة التطبيقات الداخلية والمسارات المشتركة بين المستأجرين بعيدة المنال.
لقد كشفنا بشكل مسؤول عن هذه الثغرة الأمنية لشركة Microsoft، التي قامت بمعالجتها بالكامل. قامت Microsoft بنشر إصلاح سريع بسرعة، ومنذ ذلك الحين عمل فريق Cosmos DB على مدار الساعة على عملية ترحيل كبيرة إلى بنية أفضل وأكثر صلابة. نود أن نشكر فرق MSRC وCosmos DB على تعاونهم في هذه القضية والشراكة المستمرة.
للحصول على سلسلة الاستغلال الكاملة والتحليل المتعمق وبعض المفاجآت، انضم إلينا في Black Hat USA في حديثنا: مفتاح واحد للحكم عليهم جميعًا: الاستيلاء على خدمة سحابية رائدة.
تقدر Microsoft الفرصة المتاحة لها للتحقيق في النتائج التي أبلغت عنها Wiz ضمن الكشف المنسق عن الثغرات الأمنية (CVD). أجرت Microsoft مراجعات موسعة لسجلات الوصول ولم تجد أي دليل على نشاط غير مصرح به خارج نشاط الاختبار الذي أجراه الباحث، ولم يتم الوصول إلى أي بيانات للعملاء. لا يوجد أي إجراء مطلوب من قبل العميل.
بمجرد الإبلاغ عن المشكلة، قامت فرق الاستجابة الهندسية والأمنية في Microsoft على الفور بالتحقيق في هذه الثغرة الأمنية وتطوير تخفيف فوري لها في Gremlin API لـ Azure Cosmos DB، وفي غضون 48 ساعة، تم نشر التخفيف لمنع نقطة الدخول لمتجه الهجوم هذا. أجرت Microsoft اختبارات اختراق واسعة النطاق للبحث عن نواقل هجوم مماثلة دون تحديد أي منها.
نفذت Microsoft تعزيزًا إضافيًا للنظام الأساسي مصممًا لتعزيز بنية المصادقة الأساسية وتحسين الوضع الأمني العام. عززت هذه التحسينات مصادقة خدمة إلى خدمة وقدمت المزيد من إمكانيات حماية الشبكة والمراقبة والكشف لتحسين الوضع الأمني لقاعدة بيانات Azure Cosmos DB، مع الحفاظ على الموثوقية والتوافر والأداء.
ستواصل Microsoft تعزيز النظام الأساسي، مما يعزز التزامنا بحل هذه المشكلات وتعزيز الحماية للعملاء
20 نوفمبر 2025 – أبلغت شركة Wiz Research عن الثغرة الأمنية لشركة Microsoft.
20 نوفمبر 2025 – مايكروسوفت تقر بالاستلام.
22 نوفمبر 2025 – تنشر Microsoft إصلاحًا سريعًا وتبدأ العمل على إصلاح معماري طويل المدى.
يوليو 2026 – أكملت Microsoft طرح الإصلاح على المدى الطويل في جميع المناطق.
30 يوليو 2026 – الإفصاح العلني.
أهلاً! نحن يوفال ابراهامى (@yuvalavra)، ساجي تساديك (@sagitz_)، نير أوهفيلد (@ nirohfeld)، رونين شوستين (@ronenshh)، وهيلاي بن ساسون (@hillai)، ونعوم مالرون (@noamsec) من فريق أبحاث Wiz (@wiz_io). نحن مجموعة من المتسللين ذوي القبعة البيضاء المخضرمين بهدف واحد: جعل السحابة مكانًا أكثر أمانًا للجميع. نحن نركز بشكل أساسي على العثور على نواقل هجوم جديدة في السحابة والكشف عن مشكلات العزل لدى بائعي السحابة ومقدمي الخدمات. نحن نحب أن نسمع منك! لا تتردد في الاتصال بنا على X (Twitter) أو عبر Research@wiz.io.
