الوكيل “السري” يعرض عملاء Azure لتنفيذ تعليمات برمجية غير مصرح بها

التحديث في 18 سبتمبر، الساعة 08:00 صباحًا بالتوقيت الشرقي – قامت Microsoft بتحديث نصائحها وأعلنت عن تحديث تلقائي لعروض خدمة PaaS الخاصة بها والتي تستخدم امتدادات الأجهزة الافتراضية الضعيفة بحلول 22 سبتمبر 2021. وأوضحت Microsoft أيضًا المثيلات التي ستظل تتطلب التصحيح اليدوي، راجع التفاصيل.

التحديث في 17 سبتمبر، الساعة 10:00 صباحًا بالتوقيت الشرقي – فريق أبحاث التهديدات التابع لشركة Wiz على علم بمحاولات الاستغلال النشطة واسعة النطاق لـ OMIGOD من خلال شبكات الروبوتات الخبيثة DDoS (Mirai) وأدوات التعدين المشفرة. ونحن نحث العملاء على اتباع خطوات العلاج الموضحة أدناه.

التحديث في 17 سبتمبر، الساعة 06:00 صباحًا بالتوقيت الشرقي – بدأت Microsoft في تحديث خدمات Azure المتأثرة. Azure Log Analytics وغيرها لم يتم تصحيحها بعد. لا تزال الأجهزة الموجودة المدمجة في الخدمات المتأثرة تتطلب التحديث اليدوي. اتبع إرشادات التخفيف المحدثة من قبل MSRC.

‍التحديث في 16 سبتمبر، الساعة 07:00 صباحًا بالتوقيت الشرقي – تم تحديث قائمة الخدمات المتأثرة بفضل الأفراد الذين تواصلوا مع Wiz (الائتمان أدناه).

التحديث في 15 سبتمبر، الساعة 10:00 صباحًا بتوقيت شرق الولايات المتحدة – حتى الآن، لم يتم إصلاح خدمات Azure المتأثرة (انظر القائمة أدناه). لا تزال إصدارات OMI الضعيفة منشورة على أجهزة Linux الافتراضية الجديدة عند تمكين هذه الخدمات

التحديث في 14 سبتمبر، الساعة 3:30 مساءً بتوقيت شرق الولايات المتحدة – تم إصلاح إرشادات الإصلاح الخاصة بشركة Microsoft بعد أن اقترب Wiz من MSRC.

التحديث في 14 سبتمبر، الساعة 2:00 ظهرًا بتوقيت شرق الولايات المتحدة – إرشادات الإصلاح الخاصة بشركة Microsoft ليست فعالة. لم يتم تكوين أجهزة Azure Linux للمستودع الذي يوجد به إصدار OMI الثابت.

أدت الهجمات الإلكترونية لسلسلة التوريد إلى تعطيل الحياة اليومية وهيمنت على عناوين الأخبار هذا العام. أحد أكبر التحديات في منعها هو أن سلسلة التوريد الرقمية لدينا ليست شفافة. إذا كنت لا تعرف ما هو مخفي في الخدمات والمنتجات التي تستخدمها كل يوم، فكيف يمكنك إدارة المخاطر؟

اكتشف فريق بحث Wiz مؤخرًا سلسلة من نقاط الضعف المثيرة للقلق التي تسلط الضوء على مخاطر سلسلة التوريد للتعليمات البرمجية مفتوحة المصدر، خاصة لعملاء خدمات الحوسبة السحابية.

مصدر المشكلة هو وكيل برمجيات موجود في كل مكان ولكنه غير معروف يُسمى Open Management Infrastructure (OMI) المضمن في العديد من خدمات Azure الشائعة.

عندما يقوم العملاء بإعداد جهاز Linux ظاهري في السحابة الخاصة بهم، يتم نشر وكيل OMI تلقائيًا دون علمهم عندما يقومون بتمكين خدمات Azure معينة. وما لم يتم تطبيق التصحيح، يمكن للمهاجمين بسهولة استغلال نقاط الضعف الأربعة هذه للتصعيد إلى امتيازات الجذر وتنفيذ تعليمات برمجية ضارة عن بعد (على سبيل المثال، تشفير الملفات للحصول على فدية).

لقد أطلقنا على هذه المجموعة الرباعية من الأيام الصفرية اسم “OMIGOD” لأن هذا كان رد فعلنا عندما اكتشفناها. نحن نقدر بشكل متحفظ أن الآلاف من عملاء Azure وملايين نقاط النهاية قد تأثروا. في عينة صغيرة من مستأجري Azure التي قمنا بتحليلها، كان أكثر من 65% معرضين للخطر دون علمهم.

أصدرت Microsoft CVEs التالية لـ OMIGOD وأتاحت التصحيح للعملاء أثناء إصدار تصحيح الثلاثاء لشهر سبتمبر 2021:

نحث جميع مستخدمي Azure على قراءة قسم التخفيف في هذه المدونة للتأكد من تصحيح OMI في بيئتهم. للتعمق أكثر في التفاصيل الفنية، راجع منشور OMIGOD الآخر.

من هو الضعيف؟

يتعرض عملاء Azure على أجهزة Linux – والتي تمثل أكثر من نصف جميع مثيلات Azure وفقًا لمايكروسوفت – للخطر إذا استخدموا أيًا من الخدمات / الأدوات التالية:

• أتمتة أزور

• التحديث التلقائي أزور

• مجموعة إدارة العمليات Azure (OMS)

• تحليلات سجل أزور

• إدارة التكوين أزور

• التشخيص أزور

• أزور HD إنسايت

• رؤى حاوية Azure (تمت الإضافة في 16 سبتمبر، الساعة 07:00 صباحًا بالتوقيت الشرقي)

لاحظ أن هذه ليست سوى قائمة جزئية. اتصل بنا على Research@wiz.io إذا كنت على علم بخدمات Azure الإضافية التي تنشر OMI بصمت.

بالإضافة إلى عملاء Azure السحابية، يتأثر عملاء Microsoft الآخرون حيث يمكن تثبيت OMI بشكل مستقل على أي جهاز Linux ويتم استخدامه بشكل متكرر داخل الشركة. على سبيل المثال، تم إنشاء OMI في System Center for Linux، وهو حل إدارة خادم Microsoft.

ما هو OMI؟

البنية التحتية للإدارة المفتوحة (OMI) هو مشروع مفتوح المصدر ترعاه Microsoft بالتعاون مع The Open Group. في الأساس، إنها البنية التحتية لإدارة Windows (WMI) لأنظمة UNIX/Linux. Linux مفتوح المصدر هو نظام التشغيل المفضل على الويب الحديث وقد أصبح يهيمن على Azure في السنوات الأخيرة.

يتيح لك OMI جمع الإحصائيات ومزامنة التكوينات عبر بيئتك. بفضل سهولة الاستخدام والتجريد الذي توفره OMI، يتم استخدامه على نطاق واسع بواسطة خدمات Azure، بما في ذلك Open Management Suite (OMS)، وAzure Insights، وAzure Automation.

كعب أخيل اللازوردي

عندما يقوم المستخدمون بتمكين أي من هذه الخدمات الشائعة، يتم تثبيت OMI بصمت على الجهاز الظاهري الخاص بهم، ويعمل بأعلى الامتيازات الممكنة. ويحدث هذا دون موافقة أو معرفة صريحة من العملاء. يقوم المستخدمون ببساطة بالنقر فوق “الموافقة على جمع السجلات” أثناء الإعداد وقد قاموا بالاشتراك دون علمهم.

نظرًا لأن Azure لا يوفر فعليًا أي وثائق عامة حول OMI، فإن معظم العملاء لم يسمعوا بها مطلقًا ولا يدركون وجود سطح الهجوم هذا في بيئتهم (كما هو موضح في استعلام لوحة المناقشة أدناه).

سطح الهجوم

يعمل وكيل OMI كجذر بأعلى الامتيازات. يمكن لأي مستخدم التواصل معه باستخدام مقبس UNIX أو عبر HTTP API عند تكوينه للسماح بالوصول الخارجي. ونتيجة لذلك، فإن الثغرات الأمنية التي وجدناها ستسمح للمستخدمين الخارجيين أو المستخدمين ذوي الامتيازات المنخفضة بتنفيذ التعليمات البرمجية عن بعد على الأجهزة المستهدفة أو تصعيد الامتيازات.

ثلاثة من أيام الصفر الأربعة التي وجدناها هي ثغرات أمنية في تصعيد الامتيازات. إنها تمكن المهاجمين من الحصول على أعلى الامتيازات على جهاز مثبت عليه OMI. غالبًا ما يستخدم المهاجمون نقاط الضعف هذه كجزء من سلاسل هجمات متطورة، بعد حصولهم على وصول أولي منخفض الامتيازات إلى أهدافهم.

تسمح الثغرة الرابعة والأكثر خطورة (بدرجة خطورة 9.8 من 10) بتنفيذ التعليمات البرمجية عن بعد (RCE). تعرض بعض منتجات Azure، بما في ذلك إدارة التكوين، منفذ HTTPS (المنفذ 5986) للتفاعل مع OMI. وهذا ما يجعل RCE ممكنًا. لاحظ أن معظم خدمات Azure التي تستخدم OMI تنشرها دون الكشف عن منفذ HTTPS.

في الحالات التي يمكن فيها الوصول إلى منافذ OMI عبر الإنترنت (5986/5985/1270) للسماح بالإدارة عن بعد، ويمكن أيضًا للمهاجمين استخدام هذه الثغرة الأمنية للحصول على وصول أولي إلى بيئة Azure المستهدفة ثم التحرك بشكل جانبي داخلها. نحن نتعمق في هذا بمزيد من التفاصيل في القسم أدناه.

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

قم بإزالة رأس المصادقة وأنت الجذر!

هذه هي ثغرة RCE النموذجية التي تتوقع رؤيتها في التسعينيات – ومن غير المعتاد أن يكون هناك محصول واحد في عام 2021 يمكن أن يكشف ملايين نقاط النهاية. باستخدام حزمة واحدة، يمكن للمهاجم أن يصبح جذرًا على جهاز بعيد بمجرد إزالة رأس المصادقة. الأمر بهذه البساطة.

بفضل الجمع بين خطأ بسيط في ترميز العبارة الشرطية وبنية مصادقة غير مهيأة، فإن أي طلب بدون رأس تفويض له امتيازاته الافتراضية uid=0, gid=0، وهو الجذر.

تسمح هذه الثغرة الأمنية بالسيطرة عن بعد عندما يكشف OMI عن منفذ إدارة HTTPS خارجيًا (5986/5985/1270). هذا هو التكوين الافتراضي عند تثبيته بشكل مستقل وفي إدارة تكوين Azure أو System Center Operations Manager (SCOM). لحسن الحظ، لا تكشف خدمات Azure الأخرى (مثل Log Analytics) عن هذا المنفذ، لذا يقتصر النطاق على تصعيد الامتيازات المحلية في تلك المواقف.

يوضح الرسم البياني أدناه السلوك غير المتوقع لـ OMI عندما يتم إصدار طلب تنفيذ أمر بدون رأس ترخيص.

1. التدفق الطبيعي مع كلمة مرور صالحة في رأس المصادقة– يصدر OMICLI طلب HTTP إلى مثيل OMI البعيد، ويمرر معلومات تسجيل الدخول في رأس التفويض.

2. استغلال التدفق عند تمرير أمر بدون رأس المصادقة-مفاجأة! يثق خادم OMI في الطلب حتى بدون رأس مصادقة ويمكّن RCE المثالي: حزمة واحدة لتحكمهم جميعًا.

الوجبات الجاهزة

هل المصدر المفتوح يشكل خطرا على سلسلة التوريد؟

المصدر المفتوح الذي يستخدمه المجتمع ويتم فحصه من قبل الآلاف من الخبراء هو أكثر أمانًا من البرامج الاحتكارية. ومع ذلك، إذا أسيء استخدامها، فمن المؤكد أن المصدر المفتوح يمكن أن يصبح مصدرًا للخطر.

تتمثل إحدى فوائد المصدر المفتوح في أنه من السهل على المطورين الحصول على التعليمات البرمجية من مشاريع مختلفة ومزجها مع البرامج مفتوحة المصدر والبرامج الخاصة الأخرى. ونتيجة لهذا فإن التعليمات البرمجية مفتوحة المصدر الرديئة من الممكن أن تنتهي في نطاق هائل من المنتجات والخدمات ــ فتتحول عن غير قصد إلى “نقطة الفشل الوحيدة”.

نظرًا لأن العملاء لا يعرفون ما هو برنامج Franken-code الذي يتم تشغيله في خلفية الخدمات التي يستخدمونها، فإنهم يظلون معرضين للخطر وغير مدركين.

المزيد من “العملاء السريين” كامنة في السحابة

يعد OMI مجرد مثال واحد لوكيل البرامج “السري” الذي تم تثبيته مسبقًا ونشره بصمت في البيئات السحابية. من المهم ملاحظة أن هؤلاء الوكلاء موجودون ليس فقط في Azure ولكن في AWS وGCP أيضًا.

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

حماية البيئة الخاصة بك

لقد أبلغنا Microsoft بالثغرات الأربع من خلال عملية الكشف المسؤولة وتم تصحيحها اعتبارًا من 14/9/2021. تتم ترقية OMI من خلال خدمة Azure الأصلية التي قامت بتثبيتها. ومع ذلك، فإننا نحث العملاء على التحقق من أن البيئة الخاصة بهم قد تم تصحيحها بالفعل وأنهم يقومون بتشغيل أحدث إصدار من OMI (الإصدار 1.6.8.1).

تكون عمليات نشر System Center لـ OMI معرضة لخطر أكبر لأنه تم إهمال وكلاء Linux. قد يحتاج العملاء الذين ما زالوا يستخدمون System Center مع Linux المستند إلى OMI إلى تحديث وكيل OMI يدويًا. سنقوم بتحديث هذه المشاركة بمزيد من المعلومات عندما تصبح متاحة.

اكتشاف

يمكن لعملاء Wiz استخدام مركز التهديدات لمعرفة ما إذا كان OMIGOD يمثل خطرًا في بيئتهم.

ما عليك سوى النقر فوق “عرض النتائج” لرؤية مثيلات VM مع تثبيت عوامل OMI الضعيفة:

بالنسبة لجميع عملاء Azure الآخرين، يمكنك الاتصال بأجهزة Azure الافتراضية الخاصة بك وتشغيل الأوامر أدناه في المحطة الطرفية الخاصة بك لضمان تحديث OMI إلى الإصدار الأحدث:

• بالنسبة لأنظمة دبيان (مثل Ubuntu): dpkg -l omi

• بالنسبة للنظام المستند إلى Redhat (مثل Fedora وCentOS وRHEL): rpm -qa omi

إذا لم يتم تثبيت OMI، فلن تظهر أي نتائج، ولن يكون جهازك عرضة لـ OMIGOD. إذا ظهرت النتائج، فستتمكن من معرفة إصدار OMI المثبت على أجهزتك. الإصدار 1.6.8.1 هو الإصدار المصحح.

العلاج

في 17 سبتمبر 2021، أعلنت Microsoft عن التحديث التلقائي لوكلاء OMI المثبتين كجزء من خدمات Azure السحابية. وفقًا للإعلان، يجب أن تكتمل عملية التحديث التلقائي بحلول 22 سبتمبر 2021. ولا تزال عمليات التثبيت المستقلة والمحلية، إلى جانب منتجات إضافية محددة، تتطلب تحديثًا يدويًا لحزمة OMI. نوصي باتباع إرشادات Microsoft للحصول على إرشادات التحديث اليدوي والتأكد من تطبيق التحديث التلقائي على أجهزة خدمات Azure الخاصة بك.

إذا كان لديك OMI يستمع على المنافذ 5985، 5986، 1270، فإننا ننصح بتقييد الوصول إلى الشبكة إلى تلك المنافذ على الفور للحماية من ثغرة RCE (CVE-2021-38647).

لمعرفة المزيد حول تحديد ومعالجة OMIGOD، مع إرشادات خطوة بخطوة، قم بتنزيل قائمة المراجعة الخاصة بنا.

كما هو الحال دائمًا، يسعدنا الإجابة على أسئلتك على Research@wiz.io.

نود أن نشكر Sven Spiess وTom Plant على التواصل معنا ولفت انتباهنا إلى أن خدمة Azure Container Insights تتأثر أيضًا بـ OMIGOD