اكتشف فريق أبحاث Wiz سلوكًا افتراضيًا غير آمن في خدمة تطبيقات Azure مما أدى إلى كشف التعليمات البرمجية المصدر لتطبيقات العملاء المكتوبة بلغة PHP أو Python أو Ruby أو Node، والتي تم نشرها باستخدام “Local Git”. الثغرة الأمنية، التي أطلقنا عليها اسم “NotLegit”، موجودة منذ سبتمبر 2017 ومن المحتمل أنه تم استغلالها بشكل مباشر.
أبلغ Wiz Microsoft عن هذا الخلل الأمني في 7 أكتوبر 2021، وقد تم تخفيفه الآن. لا تزال مجموعات صغيرة من العملاء عرضة للخطر ويجب عليهم اتخاذ إجراءات معينة للمستخدم لحماية تطبيقاتهم، كما هو مفصل في العديد من تنبيهات البريد الإلكتروني التي أصدرتها Microsoft في الفترة من 7 إلى 15 ديسمبر 2021.
إعادة تلخيص الأساسيات
ما هي خدمة تطبيق Azure؟
خدمة Azure App (AKA Azure Web Apps) عبارة عن نظام أساسي قائم على الحوسبة السحابية لاستضافة مواقع الويب وتطبيقات الويب. الخدمة سهلة الاستخدام، وبالتالي تحظى بشعبية كبيرة: أولاً، عليك تحديد لغة البرمجة ونظام التشغيل المعتمدين. وبعد ذلك، يمكنك نشر التعليمات البرمجية المصدرية لتطبيقك أو عناصره على خادم مُدار بواسطة Azure باستخدام FTP أو SSH أو عن طريق سحب التعليمات البرمجية المصدر من خدمة Git (مثل GitHub أو مستودعات Git الخاصة). بعد النشر، يصبح التطبيق متاحًا لأي شخص على الإنترنت ضمن نطاق *.azurewebsites.net الخاص به.
ما هي “البوابة المحلية”؟
يدعم Azure طرقًا متعددة لنشر التعليمات البرمجية المصدر والعناصر في خدمة Azure App، أحدها يستخدم “Local Git”. باستخدام “Local Git”، يمكنك إنشاء مستودع Git محلي داخل حاوية Azure App Service التي تمكنك من دفع التعليمات البرمجية الخاصة بك مباشرة إلى الخادم.
العيب الأمني: كان مستودع Git المحلي الخاص بك متاحًا للعامة
كأفضل ممارسة، عند نشر مستودعات git على خوادم الويب ومستودعات التخزين، من المهم دائمًا التأكد من عدم تحميل مجلد .git أيضًا. لماذا؟ لأن المجلد .git يحتوي على الكود المصدري ورسائل البريد الإلكتروني للمطورين والبيانات الحساسة الأخرى. ومع ذلك، عندما تم استخدام طريقة النشر “Local Git” للنشر في خدمة تطبيقات Azure، تم إنشاء مستودع git ضمن الدليل الذي يمكن الوصول إليه بشكل عام (/home/site/wwwroot) والذي يمكن لأي شخص الوصول إليه. كان هذا أمرًا معروفًا لشركة Microsoft. لحماية ملفاتك، أضافت Microsoft ملف “web.config” إلى مجلد .git داخل الدليل العام الذي قيد الوصول العام. ومع ذلك، فإن خادم الويب IIS الخاص بشركة Microsoft فقط هو الذي يتعامل مع ملفات “web.config”. إذا كنت تستخدم C# أو ASP.NET، فسيتم نشر التطبيق مع IIS وهذا التخفيف جيد تمامًا.
ولكن ماذا يحدث عند استخدام PHP أو Ruby أو Python أو Node؟ يتم نشر لغات البرمجة هذه مع خوادم ويب مختلفة (Apache وNginx وFlask وما إلى ذلك)، والتي لا تتعامل مع ملفات “web.config”، مما يجعلها غير متأثرة بالتخفيف وبالتالي عرضة للخطر تمامًا. في الأساس، كل ما كان على أي ممثل خبيث فعله هو جلب الدليل “/.git” من التطبيق المستهدف، واسترداد الكود المصدري الخاص به.
حقيقة ممتعة: يحتوي ملف web.config الخاص بشركة Microsoft على خطأ مطبعي (ملف إعدادات لم يتم إغلاق العلامة بشكل صحيح) مما جعل الملف غير قابل للتحليل بواسطة IIS. لحسن الحظ، أدى الخطأ الناتج عن الخطأ المطبعي إلى منع الوصول إلى الدليل بأكمله… لذلك يمكنك القول أن “web.config” قدم اقتراحه بعد كل شيء 😊
لاحقًا، اكتشفت Microsoft أن المستخدمين الذين استخدموا أدوات نشر Git الأخرى قد يتعرضون أيضًا لما يلي: إذا تم إنشاء ملف أو تعديله في حاوية Azure App Service (باستخدام FTP أو Web Deploy أو SSH) قبل في أي عملية نشر لـ Git، تدخل الخدمة في حالة “النشر الداخلي”. تفرض هذه الحالة بدء أي نشر لـ Git في المستقبل ضمن الدليل الذي يمكن الوصول إليه بشكل عام. لمزيد من التفاصيل، راجع النشر في مكانه وبدون مستودع.
عدم الحصانة غير المشروعة
من المتأثر؟
-
جميع تطبيقات PHP وNode وRuby وPython التي تم نشرها باستخدام “Local Git” على تطبيق افتراضي نظيف في Azure App Service منذ سبتمبر 2017
-
جميع تطبيقات PHP وNode وRuby وPython التي تم نشرها في Azure App Service اعتبارًا من سبتمبر 2017 فصاعدًا باستخدام أي مصدر Git، بعد إنشاء ملف أو تعديله في حاوية التطبيق
التطبيقات الوحيدة التي لم تتأثر بهذا الثغرة الأمنية هي التطبيقات المستندة إلى IIS.
أرسلت Microsoft إشعارات مختلفة عبر البريد الإلكتروني إلى جميع المستخدمين المتأثرين بناءً على التكوين الخاص بهم في الفترة من 7 إلى 15 ديسمبر 2021.
استغلال .git بشكل عام
يعد مجلد .git المكشوف مشكلة أمنية شائعة يقوم بها المستخدمون دون أن يدركوا ذلك. تقوم الجهات الفاعلة الضارة بمسح الإنترنت باستمرار بحثًا عن مجلدات Git المكشوفة التي يمكنهم من خلالها جمع الأسرار والملكية الفكرية. إلى جانب احتمال أن يحتوي المصدر على أسرار مثل كلمات المرور ورموز الوصول، غالبًا ما يتم استخدام كود المصدر المسرب لمزيد من الهجمات المعقدة مثل جمع المعلومات في قسم البحث والتطوير، ومعرفة البنية التحتية الداخلية، والعثور على نقاط ضعف البرامج. يكون العثور على الثغرات الأمنية في البرامج أسهل كثيرًا عندما يكون كود المصدر متاحًا.
يعد الكشف عن مجلد Git عن طريق الخطأ من خلال خطأ المستخدم مشكلة أمنية يمكن أن تؤثر حتى على المؤسسات الكبيرة – سواء وقد تم الكشف عن مواقع الأمم المتحدة وعدد من المواقع الحكومية الهندية بهذه الطريقة في الماضي، على سبيل المثال. ما يبرز في NotLegit هو أن مستخدمي السحابة لم يرتكبوا أي خطأ هنا. لم يكشفوا عن طريق الخطأ مجلد Git الخاص بهم، بل فعلت خدمة Azure ذلك! نظرًا لأن المشكلة الأمنية كانت في إحدى خدمات Azure، فقد تعرض مستخدمو السحابة للخطر على نطاق واسع، ودون علمهم أو السيطرة عليها.
استغلالها في البرية
لتقييم احتمالية التعرض للمشكلة التي اكتشفناها، قمنا بنشر تطبيق Azure App Service الضعيف، وربطناه بمجال غير مستخدم، وانتظرنا بصبر لمعرفة ما إذا كان أي شخص يحاول الوصول إلى ملفات .git. وفي غضون 4 أيام من النشر، لم نتفاجأ برؤية طلبات متعددة لمجلد .git من جهات غير معروفة.
نظرًا لأن طريقة الاستغلال هذه سهلة للغاية وشائعة ويتم استغلالها بشكل نشط، فإننا نشجع جميع المستخدمين المتأثرين على مراجعة الكود المصدري لتطبيقاتهم وتقييم المخاطر المحتملة:
-
المستخدمون الذين نشروا التعليمات البرمجية عبر FTP أو Web Deploy أو Bash/SSH مما أدى إلى تهيئة الملفات في تطبيق الويب قبل أي نشر لـ git.
-
المستخدمون الذين قاموا بتمكين LocalGit على تطبيق الويب
-
المستخدمون الذين يتبعون تسلسل استنساخ/دفع Git لنشر التحديثات
الكشف المسؤول عن Wiz واستجابة Microsoft
بعد الكشف عن ثغرة NotLegit لشركة Microsoft، أدركت Microsoft مدى خطورة هذه المشكلة واتخذت جميع الخطوات اللازمة للتحقيق فيها والتخفيف من حدتها. أجرى MSRC وفريق خدمة تطبيقات Azure تحقيقًا عميقًا وعثروا على سبب المشكلة، وطبقوا إصلاحًا يغطي معظم العملاء المتأثرين، وأرسلوا إشعارات عبر البريد الإلكتروني لتحذير جميع العملاء الذين ما زالوا معرضين للخطر وينتظرون إجراء المستخدم (نأمل أن يتم اتخاذه بالفعل بعد إشعار العميل في 7 ديسمبر).
منحت Microsoft أيضًا Wiz مكافأة قدرها 7500 دولار مقابل هذه النتيجة، والتي نخطط للتبرع بها.
الجدول الزمني للإفصاح
-
12 سبتمبر 2021 – لاحظ فريق أبحاث Wiz لأول مرة السلوك غير الآمن.
-
7 أكتوبر 2021 – تم الإبلاغ عن مشكلة إلى Microsoft.
-
8 أكتوبر 2021 – تلقت Microsoft التقرير.
-
14 أكتوبر 2021 – طلبت شركة Microsoft إجراء مكالمة جماعية لمناقشة المشكلة وفرزها.
-
19 أكتوبر 2021 – مكالمة جماعية مع MSRC وفريق خدمات تطبيقات Azure.
-
22 أكتوبر 2021 – تم الاعتراف بالتقرير وحصل Wiz على مكافأة قدرها 7500 دولار.
-
17 نوفمبر 2021 – تم نشر إصلاح تطبيقات PHP.
-
07 ديسمبر 2021 – بدأت Microsoft في إخطار العملاء المعرضين للخطر عبر البريد الإلكتروني.
معلومات عنا
من الصعب التعامل مع الحاجة إلى معرفة كل خدمة بعمق. وحتى الآن، في عام 2021، أعلنت Azure وحدها عن 402 منتجًا وميزة جديدة، ناهيك عما أعلنته AWS وGoogle Cloud. أخيرًا، يكاد يكون من المستحيل على المستخدم العادي مواكبة ذلك. يعمل فريق بحث Wiz، وهو مجموعة من الخبراء المخضرمين في مجال الأمن السيبراني الذين يعملون في هذا المجال منذ أكثر من 10 سنوات، على مدار الساعة لتحديد المشكلات الأمنية المحتملة مع خدمات CSP ومساعدة عملائنا على تحديدها ومعالجتها. في بعض الأحيان، نجد نقاط ضعف في النظام الأساسي نفسه. في عام 2021 وحده، ساعدنا AWS وAzure وGoogle Cloud على إصلاح 14 ثغرة أمنية عبر خدمات متعددة.
إذا كان لديك أي أسئلة حول أبحاثنا، يرجى التواصل معنا Research@wiz.io
شكر خاص لسيباستيان كورنيجو (@CuriositySec) الذي ساعدنا في جمع النطاقات الفرعية azurewebsites.net لهذا البحث.
