في 6 سبتمبر 2023، نشرت Microsoft متابعة لتقريرها الاستقصائي الأولي الصادر في 11 يوليو حول Storm-0558 – وهو ممثل تهديد منسوب إلى الصين تمكن من الحصول على مفتاح توقيع سمح لهم بالوصول غير المشروع إلى حسابات Exchange وOutlook. يجب الإشادة بشركة Microsoft على المستوى العالي من الشفافية الذي أظهرته، واستعدادها لمشاركة هذه المعلومات مع المجتمع. ومع ذلك، نشعر أن منشور المدونة الأخير يثير العديد من الأسئلة بقدر ما يجيب عليه.
معلومات تم الكشف عنها حديثا
فيما يلي ملخص للمعلومات الجديدة المقدمة في أحدث تقرير لشركة Microsoft حول كيفية اختراق مفتاح التوقيع من قبل جهة التهديد (راجع الرسم البياني أعلاه للحصول على تمثيل مرئي لتدفق الهجوم كما نفهمه حاليًا):
-
هناك دليل على أن حساب شركة أحد مهندسي Microsoft قد تم اختراقه بواسطة Storm-0558 “[at some point] بعد أبريل 2021.”، باستخدام رمز وصول تم الحصول عليه من جهاز مصاب ببرامج ضارة.
-
كان لدى هذا المهندس إذن للوصول إلى خادم تصحيح الأخطاء في شبكة شركة Microsoft.
-
يحتوي خادم تصحيح الأخطاء هذا على ملف تفريغ الأعطال الذي نشأ في نظام التوقيع الموجود في شبكة الإنتاج المعزولة لـ Microsoft.
-
يحتوي تفريغ الأعطال هذا، والذي كان نتيجة العطل الذي حدث في أبريل 2021، على مفتاح توقيع MSA المذكور أعلاه.
-
كان تضمين مفتاح التوقيع في تفريغ الأعطال هذا نتيجة لخطأ، وتسبب خطأ منفصل في عدم اكتشاف مفتاح التوقيع على خادم تصحيح الأخطاء.
-
استنادًا إلى الأحداث الموضحة أعلاه، خلصت Microsoft إلى أن الطريقة الأكثر احتمالاً التي حصل بها Storm-0558 على مفتاح توقيع MSA كانت من خلال هذا الحساب المخترق، وذلك عن طريق الوصول إلى خادم تصحيح الأخطاء وإخراج ملف تفريغ الأعطال الذي يحتوي على مادة المفتاح.
إلى جانب توفير المعلومات المذكورة أعلاه حول مدى احتمالية تعرض المفتاح للاختراق، فإن أحدث تقرير لشركة Microsoft يؤكد أيضًا علنًا استنتاجاتنا الخاصة (المنشورة في 21 يوليو) حول العوامل المساهمة في هذا الحادث، وهي:
-
قبل اكتشاف ممثل التهديد هذا في يونيو 2023، لم تتضمن Azure AD SDK (الموصوفة في التقرير على أنها “مكتبة وثائق وواجهات برمجة التطبيقات المساعدة”) وظيفة للتحقق بشكل صحيح من معرف مصدر رمز المصادقة المميز. بمعنى آخر، كما أوضحنا في منشور مدونتنا السابق، فإن أي تطبيق يعتمد فقط على SDK لتنفيذ المصادقة سيكون معرضًا لخطر قبول الرموز المميزة الموقعة بنوع مفتاح خاطئ.
-
كما هو مذكور في تقرير Microsoft الأصلي، تأثر Exchange بثغرة أمنية تسببت في قبول رموز مصادقة Azure AD باعتبارها صالحة على الرغم من توقيعها بواسطة مفتاح توقيع MSA – تم استغلال هذه الثغرة الأمنية في النهاية بواسطة Storm-0558 للوصول إلى حسابات المؤسسة. في تقريرها الأخير، أوضحت Microsoft أن هذه المشكلة كانت في الواقع نتيجة لوظيفة التحقق المفقودة في SDK: في وقت ما من عام 2022، افترض فريق التطوير المسؤول عن المصادقة في Exchange بشكل غير صحيح أن Azure AD SDK أجرى التحقق من صحة جهة الإصدار بشكل افتراضي. وقد تسبب هذا في تنفيذ عملية التحقق بشكل غير صحيح، مما أدى إلى حدوث ثغرة أمنية.
ماذا يعني هذا؟
يبدو أن الجدول الزمني الذي يمكن استخلاصه من التقرير الأخير يشير إلى أنه نظرًا لسياسات الاحتفاظ بالسجل (أمر مفهوم، نظرًا لأن النشاط ربما امتد على مدار عامين)، لا تستطيع Microsoft حساب كل أنشطة جهة التهديد هذه داخل شبكتها إلا جزئيًا بين أبريل 2021 ومايو 2023. بالإضافة إلى ذلك، لا يوضح التقرير صراحة متى تم نقل تفريغ التعطل إلى بيئة تصحيح الأخطاء أو عندما تم اختراق حساب المهندس؛ فقط أن كل حدث من هذه الأحداث وقع في وقت ما بعد أبريل 2021. إذا افترضنا أن كلاهما حدث في أقرب وقت ممكن على المخطط الزمني – دعنا نقول مايو 2021 – فهذا يعني أن جهة التهديد ربما كانت تمتلك مفتاح التوقيع لأكثر من عامين قبل اكتشافها في يونيو 2023. علاوة على ذلك، في حين قامت Microsoft بمراجعة سجلاتها وحددت بشكل نهائي استخدام رموز المصادقة المزورة لحسابات Exchange وOutlook طوال شهر مايو 2023، ومع ذلك، فقد توصلنا إلى استنتاج مفاده أن جهة التهديد ربما كانت تقوم بتزوير رموز المصادقة المميزة لخدمات أخرى خلال فترة العامين هذه.
كما أوضحنا في منشور مدونتنا الأخير حول هذا الموضوع، فإن الشخص الذي يمتلك مفتاح توقيع MSA هذا لم يقتصر على تزوير رموز المصادقة المميزة لـ Exchange وOutlook فقط – بل كان من الممكن أن يكون قد قام بتزوير رموز مميزة من شأنها أن تسمح له بانتحال صفة حسابات المستهلكين في أي تطبيق مستهلك أو تطبيق مختلط الجمهور، وحسابات المؤسسة في أي تطبيق ينفذ التحقق من الصحة بشكل غير صحيح، مثل Exchange. بمعنى آخر، كان Storm-0558 في وضع يسمح له بالوصول إلى مجموعة واسعة من الحسابات في التطبيقات التي تديرها Microsoft (مثل SharePoint) أو عملائها. كما أوضحنا في منشور مدونتنا السابق، كان هذا مفتاحًا قويًا للغاية.
الوجبات السريعة الرئيسية من الوجبات الجاهزة الرئيسية
استنادًا إلى ما يمكن أن نتعلمه من أحدث تقرير لشركة Microsoft، يجب أن يكون لدى عملاء السحابة النصائح التالية من هذه الحادثة:
-
يجب على المؤسسات فحص سجلاتها بحثًا عن أدلة تتعلق بهذا النشاط في نافذة زمنية تمتد بين أبريل 2021 ويونيو 2023 (يمكن لشركة Microsoft تضييق هذه النافذة من خلال الإشارة بدقة إلى الوقت الذي تم فيه اختراق حساب المهندس).
-
يجب على المؤسسات استخدام وحدة أمان الأجهزة (HSM) لتخزين المفاتيح كلما أمكن ذلك – وهذا سيضمن عدم تضمين المواد الأساسية مطلقًا في عمليات تفريغ الأعطال. كما فعل الآخرون ذُكر، ربما يكون النطاق الذي تعمل به Microsoft قد جعل من المستحيل عليهم القيام بذلك، ولكن يجب على المؤسسات الأصغر بالتأكيد أن تجعل ذلك أولوية.
-
كإجراء وقائي دفاعي متعمق، يجب إزالة بيانات تصحيح الأخطاء وتفريغ الأعطال بشكل منتظم، حيث يمكن أن تحتوي على معلومات تم فك تشفيرها والتي قد تكون منجم ذهب للجهات الفاعلة في مجال التهديد بمجرد وصولهم إلى البيئة. بشكل عام، غالبًا ما يمكن العثور على الأسرار الحساسة في أماكن غير متوقعة، مثل سجل bash، وطبقات الصور المخفية، وما إلى ذلك.
-
بالإضافة إلى ذلك، يجب على المؤسسات الاحتفاظ بمخزون من الأصول التي يتم فيها جمع بيانات تصحيح الأخطاء وتفريغ الأعطال أو تخزينها أو فهرستها، والتأكد من وجود ضوابط الوصول للحد من تعرض هذه الأصول.
-
يجب عزل بيئات الإنتاج الحساسة بشكل صحيح عن بيئات الشركات التي تكون أكثر عرضة لخطر التسوية. على الرغم من عدم وجود دليل يشير إلى أن جهة التهديد تمكنت من اختراق الحدود الأمنية لشركة Microsoft أو الوصول إلى بيئة الإنتاج نفسها، فإن السبب الجذري هنا هو فشل نظافة البيانات عند نقل البيانات التي يحتمل أن تكون حساسة بين البيئتين.
-
ينبغي تدوير مفاتيح التوقيع بشكل منتظم، ويفضل أن يتم ذلك كل بضعة أسابيع. في هذه الحالة، تم إصدار مفتاح التوقيع الذي تم الحصول عليه في أبريل 2016 وانتهت صلاحيته في أبريل 2021، لكنه ظل صالحًا حتى تم تدويره أخيرًا في يوليو 2023 بعد تحقيق Microsoft في هذه الحادثة. وهذا يعني أن المفتاح كان طويل العمر للغاية وكان قيد الاستخدام لأكثر من 7 سنوات. بينما قامت Microsoft بتدوير مفاتيح التوقيع الخاصة بها بعد هذا الحادث، يظهر واحد على الأقل (معرف المفتاح -KI3Q9nNR7bRofxmeZoXqbHZGew) في كل من قائمة المفاتيح الحالية وفي نفس القائمة التي ظهرت فيها في أكتوبر 2022. إذا ظل هذا المفتاح قيد الاستخدام، فيجب تدويره أيضًا، وذلك فقط للحد من تأثير أي حادث محتمل مماثل (غير مرجح).
-
يجب مراقبة واختبار آليات المسح السرية – خاصة تلك التي تم وضعها للتخفيف من مخاطر تسرب المفاتيح من بيئات الثقة العالية إلى المنخفضة – بانتظام واختبارها للتأكد من فعاليتها.
-
تعتبر الإعدادات الافتراضية فعالة، والوثائق وحدها ليست كافية لتشكيل سلوك المطور. يجب على أدوات تطوير البرامج (SDK) إما تنفيذ الوظائف الهامة بشكل افتراضي، أو تحذير المستخدمين في حالة فاتتهم خطوة التنفيذ الحيوية التي يجب تنفيذها يدويًا. إذا أساء المطورون في Microsoft فهم وثائقهم الخاصة وارتكبوا هذا الخطأ الفادح، فمن المنطقي أن يكون أي من عملائهم قد فعل الشيء نفسه.
أسئلة بلا إجابة
وعلى الرغم من أن تقرير مايكروسوفت يجيب على بعض الأسئلة الملحة المتعلقة بهذه القضية، إلا أنه لا تزال هناك عدة أسئلة دون إجابة:
-
هل كان هذا في الواقع كيف حصل Storm-0558 على مفتاح التوقيع؟ وذكرت شركة مايكروسوفت أن تحقيقاتها قد انتهت، مما يعني أنها استنفدت جميع الأدلة المتاحة لها. لذلك، ربما لن نحصل أبدًا على إجابة محددة لهذا السؤال.
-
ما مدى احتمالية تعرض مفاتيح التوقيع الأخرى التي كانت صالحة خلال فترة السنتين للاختراق بنفس الطريقة؟ هل هناك دليل على عكس ذلك؟ (من الواضح أنه سيكون من الصعب جدًا إثبات ذلك).
-
متى بالضبط تم اختراق حساب المهندس؟ والأهم من ذلك، ما هي أقرب نقطة زمنية ممكنة يمكن أن يحصل فيها Storm-0558 على مفتاح التوقيع؟
-
هل كان جهة التهديد تستهدف هذا المهندس على وجه التحديد بسبب وصوله إلى بيئة تصحيح الأخطاء، أم أنه كان لديه أهداف أخرى في الاعتبار؟
-
هل كان حساب المهندس والجهاز المصاب ببرامج ضارة هما الكيانان الوحيدان المعروفان المخترقان داخل بيئة شركة Microsoft خلال هذه الفترة؟ هل حدد التحقيق المستخدمين أو الأنظمة الأخرى المخترقة؟ متى (وكيف) أسس المهاجم موطئ قدمه الأولي في البيئة؟
-
عندما تقول Microsoft إنها لم تلاحظ جهة التهديد التي تستهدف مستخدمي أي تطبيقات أخرى غير Exchange وOutlook، فهل هذا يعني أنها أثبتت بشكل قاطع أن جهة التهديد لم تقم بتزوير رموز الوصول للخدمات الأخرى؟ بمعنى آخر، هل لديهم بالفعل السجلات اللازمة (التي تعود إلى فترة زمنية كافية وتحتوي على البيانات المطلوبة) للتحقق من ذلك بشكل معقول؟
-
في أي مرحلة حدد ممثل التهديد الثغرة الأمنية في Exchange التي سمحت له باستخدام رموز المصادقة المزورة الموقعة بواسطة مفتاح توقيع MSA لانتحال صفة مستخدمي AAD؟ هل كان بإمكانهم اكتشاف ذلك بطريقةٍ ما بشكل مستقل عن الحصول على مفتاح التوقيع؟ هل من الممكن أن يكونوا قد اكتشفوا نفس الثغرة الأمنية التي تؤثر على التطبيقات الأخرى قبل أن يصبح Exchange عرضة للخطر في عام 2022؟
فيما يتعلق بالسؤال الأخير حول كيفية اكتشاف جهة التهديد لثغرة التحقق من صحة معرف المُصدر في Exchange، يمكننا طرح نظرية مفادها أنهم أدركوا في البداية أن SDK (وهو مفتوح المصدر) لم يتضمن التحقق من صحة نقطة النهاية بشكل افتراضي، وافترضوا بشكل صحيح أن بعض مستخدمي SDK على الأقل – بما في ذلك مطوري Microsoft – سيفشلون بالتالي في تنفيذ هذا التحقق بشكل صحيح.
ومن الجدير بالذكر أيضًا أنه على عكس تقرير مايكروسوفت السابق، فإن هذا التقرير الأخير لا يتضمن أي مؤشرات فنية جديدة تتعلق بنشاط جهة التهديد، على الرغم من أن مايكروسوفت وجدت دليلاً على مثل هذا النشاط داخل شبكة الشركة الخاصة بها.
تمت كتابة منشور المدونة هذا بواسطة Wiz Research، كجزء من مهمتنا المستمرة لتحليل التهديدات التي تواجه السحابة، وبناء آليات تمنعها وتكتشفها، وتقوية استراتيجيات أمان السحابة.
