كيفية اختراق خادم Exchange غير مسبوق برمز PowerShell خادع

عقدة المصدر: 1760191

قبل أقل من شهرين بقليل ، اندلعت بعض أخبار الأخطاء المقلقة: تم الإعلان عن زوج من ثغرات يوم الصفر في Microsoft Exchange.

ونحن نصحت في ذلك الوقت، هذه الثغرات الأمنية المعينة رسميًا CVE-2022-41040 و CVE-2022-41082:

[كان] يومين من الصفر [يمكن] أن يتم ربطهما معًا ، مع استخدام الخطأ الأول عن بُعد لفتح ما يكفي من الثقب لتشغيل الخطأ الثاني ، والذي من المحتمل أن يسمح بتنفيذ التعليمات البرمجية عن بُعد (RCE) على خادم Exchange نفسه.

كانت نقطة الضعف الأولى تذكرنا بالثغرة المزعجة والمُسيئة على نطاق واسع ثقب أمان ProxyShell من أغسطس 2021 ، لأنها اعتمدت على السلوك الخطير في ميزة الاكتشاف التلقائي في Exchange ، وصفتها Microsoft كبروتوكول "مستخدم بواسطة عملاء Outlook و EAS [Exchange ActiveSync] للبحث عن علب البريد في Exchange والاتصال بها".

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

لسوء الحظ ، لم تفعل تصحيحات ProxyShell ما يكفي لإغلاق الاستغلال للمستخدمين المصادق عليهم ، مما أدى إلى CVE-2022-40140 Zero-day الجديد ، والذي سرعان ما كان مقتضبًا ، إذا كان مضللًا ، يطلق عليها اسم ProxyNotShell.

ليست خطيرة ، لكنها خطيرة مع ذلك

من الواضح أن ProxyNotShell لم يكن قريبًا من خطورة ProxyShell الأصلي ، نظرًا لأنه يتطلب ما يُعرف باسم الوصول المعتمد ، لذلك لم يكن عرضة للإساءة من قبل أي شخص من أي مكان.

ولكن سرعان ما تبين أنه على العديد من خوادم Exchange ، فإن معرفة اسم تسجيل الدخول وكلمة المرور لأي مستخدم سيكونان كافيين لتمرير هذا الهجوم كمصادق عليهما وشن هذا الهجوم ، حتى لو كان هذا المستخدم نفسه بحاجة إلى استخدام المصادقة الثنائية (2FA) لتسجيل الدخول بشكل صحيح للوصول إلى بريدهم الإلكتروني.

بصفته خبير سوفوس ، تشيستر ويسنيفسكي وضعه في الموعد:

إنها "ثغرة أمنية متوسطة المصادقة" ، إذا كنت تريد تسميتها كذلك. هذه نعمة مختلطة. هذا يعني أن برنامج Python النصي الآلي لا يمكنه فقط فحص الإنترنت بالكامل وربما استغلال كل خادم Exchange في العالم في غضون دقائق أو ساعات ، كما رأينا يحدث مع ProxyLogon و ProxyShell في عام 2021. [...]

أنت بحاجة إلى كلمة مرور ، ولكن العثور على مجموعة عنوان بريد إلكتروني وكلمة مرور واحدة صالحة في أي خادم Exchange قد لا يكون صعبًا للغاية ، لسوء الحظ. وربما لم يتم استغلالك حتى الآن ، لأن تسجيل الدخول بنجاح إلى Outlook Web Access [OWA] يتطلب رمز FIDO المميز ، أو المصادقة الخاصة بهم ، أو أي عامل ثان قد تستخدمه.

لكن هذا الهجوم لا يتطلب العامل الثاني. […] مجرد الحصول على تركيبة اسم مستخدم وكلمة مرور يعد عائقًا منخفضًا جدًا.

كما تتذكر على الأرجح ، افترض الكثير منا (أو كان يأمل على الأقل) أن تسرع Microsoft في الحصول على إصلاح لثغرات ProxyNotShell ، نظرًا لأنه لا يزال هناك أسبوعان حتى يوم الثلاثاء في أكتوبر.

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

حتى يوم الثلاثاء في تشرين الثاني (نوفمبر) لم يقدم بشكل مباشر الإصلاحات المطلوبة ، على الرغم من التصحيحات مع ذلك خرج في نفس اليوم كجزء من تحديث أمني خاص بـ Exchange يمكن جلبه وتثبيته بشكل منفصل:

تم الكشف عن إثبات المفهوم

الآن بعد أن تلاشى الغبار وأصبح لدى الجميع الوقت لإصلاح خوادم Exchange الخاصة بهم (تلك التي لم ينسوها ، على الأقل) ، الباحثون في Zero Day Initiative (ZDI) ، والتي تم الكشف عن هذه الثغرات الأمنية بشكل مسؤول لتقديمها إلى مايكروسوفت، قد أوضح كيف يمكن استغلال الخلل.

الأخبار السيئة ، اعتمادًا على رأيك في الكشف العلني عن عمليات الاستغلال ، هي أن فريق ZDI قد قدم الآن بشكل فعال إثباتًا للمفهوم (PoC) يشرح كيفية مهاجمة خوادم Exchange.

الخبر السار بالطبع هو أن:

  • يمكننا الآن دراسة وفهم الأخطاء بأنفسنا. هذا لا يساعدنا جميعًا فقط على ضمان أن الاحتياطات العامة التي اتخذناها (لا تقتصر فقط على الترقيع) من المرجح أن توفر الحماية التي نتوقعها ، ولكنها تُعلمنا أيضًا بممارسات البرمجة التي نرغب في تجنبها في المستقبل ، لذلك نحن لا نفعل ذلك. لن يتم الوقوع في فخ فتح أخطاء من هذا النوع في التعليمات البرمجية من جانب الخادم الخاصة بنا.
  • ليس لدينا الآن أعذار لعدم تطبيق الرقع. إذا تأخرنا في التحديث ، فإن شرح ZDI لسبب نجاح الهجوم يوضح أن العلاج هو بالتأكيد أفضل من المرض.

كيف يعمل

ZDI's تفسير تُشكل هذه الثغرة حكاية رائعة عن مدى تعقيد تجميع جميع الأجزاء التي تحتاجها معًا لتحويل الثغرة إلى برمجيات إكسبلويت قابلة للتطبيق.

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

يعتبر التفسير ، بالضرورة ، معقدًا وتقنيًا تمامًا ، ويقودك إلى الأمام عبر سلسلة طويلة من الخطوات لتحقيق تنفيذ التعليمات البرمجية عن بُعد (RCE) في النهاية.

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

... لذلك ستعرف مسبقًا سبب اتخاذ القصة للاتجاهات التي تتبعها:

  • الخطوة 4. خدعة Exchange عن بُعد لإنشاء مثيل كائن .NET من اختيارك ، مع معلمة تهيئة من اختيارك.

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

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

تحتوي الكائنات بشكل عام على وظيفة برمجية مرتبطة بها تسمى a منشئ، والتي يتم تنفيذها تلقائيًا عند إنشاء كائن جديد لتخصيص المقدار الصحيح من الذاكرة والمجموعة الصحيحة من موارد النظام.

عادة ، تحتاج إلى تمرير معلمة أو أكثر كوسيطات إلى المُنشئ ، للإشارة إلى الطريقة التي تريد أن يتم تكوين الكائن بها عند بدء تشغيله.

ببساطة ، إذا قمت بإنشاء مثيل ، فلنقل ، ملف TextString كائن (نحن نصنع هذه الأسماء ، لكنك حصلت على الفكرة) باستخدام معلمة تكون بحد ذاتها سلسلة نصية مثل example.com:8888...

... من المحتمل أن ينتهي بك الأمر بمخزن ذاكرة مخصص للاحتفاظ بالنص ، مهيأ بحيث يحمل نفس القيمة التي مررتها ، أي النص الخام example.com:8888.

في هذا السياق ، فإن السلسلة النصية التي يتم تمريرها كبيانات إلى مُنشئ الكائن لا تشكل على الفور أي تهديد واضح للأمن السيبراني عندما تقوم بتشغيل المُنشئ عن بُعد ، بخلاف رفض محتمل للخدمة (DoS) من خلال المطالبة بشكل متكرر بسلاسل أكبر وأكبر إلى حاول استنفاد الذاكرة.

ولكن إذا كنت تريد إنشاء مثيل ، على سبيل المثال ، ملف ConnectedTCPClient باستخدام نفس معلمة السلسلة النصية الخاصة بـ example.com:8888، قد ينتهي بك الأمر مع مخزن مؤقت للذاكرة جاهز للاحتفاظ بالبيانات المؤقتة ، إلى جانب مقبس الشبكة المخصص بواسطة نظام التشغيل والذي يكون جاهزًا لتبادل البيانات مع الخادم example.com عبر منفذ TCP 8888.

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

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

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

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

من الناحية النظرية ، يمكن فقط إنشاء كائنات آمنة أو منخفضة الخطورة عن بُعد عبر PowerShell ، بحيث يتم إنشاء مثيلنا الخيالي TextString أعلاه ، أو أ SimpleIntegerValue، يمكن اعتباره مقبولاً ، بينما أ ConnectedTCPClient أو RunCmdAndReadOutput بالتأكيد لن يكون.

لكن باحثي ZDI لاحظوا أنه قبل بدء الخطوة الأخيرة ، يمكنهم القيام بذلك:

  • الخطوة 3. خدعة Exchange عن بعد ليعتقد أن الجسم منخفض الخطورة الذي اجتاز اختبار الأمان هو ، في الواقع ، كائن آخر من اختيارك.

ومع ذلك ، قد تتوقع أن يقوم Exchange بمنع الإنشاء عن بُعد حتى للكائنات منخفضة الخطورة ، لتقليل التهديد بشكل أكبر.

لكن الباحثين وجدوا أن بإمكانهم:

  • الخطوة 2. خدعة الصرف عن بعد لاستخدامها PowerShell عن بُعد ميزة لإنشاء كائن بناءً على معلمات التهيئة التي يتم التحكم فيها خارجيًا.

وكان ذلك ممكنًا بسبب الفتحة التي تشبه ProxyShell والتي كانت شبه مرقعة فقط:

  • الخطوة 1. خدعة Exchange عن بُعد لقبول طلب ويب ومعالجته برمز عن طريق تعبئة ملف صالح username:password الحقل في الطلب أيضًا.

حتى إذا لم يكن المستخدم المذكور اسمه في الطلب مسجلاً الدخول فعليًا ، وسيحتاج إلى إجراء نوع من عملية المصادقة الثنائية (2FA) للوصول إلى صندوق البريد الخاص به ، وهو مهاجم يعرف username:password قد تحتوي المجموعة على معلومات مصادقة كافية لخداع Exchange لقبول اتصال ويب يمكن استخدامه لبدء سلسلة الهجوم الموضحة في الخطوات من 2 إلى 4 أعلاه.

يتحدث فضفاضة ، أي صالح username:password قد تفي بالغرض ، نظرًا لأن "المصادقة" كانت مطلوبة ببساطة لمنع Exchange من رفض طلب HTTP مقدمًا.

ماذا ستفعلين.. إذًا؟

لاحظ أن هذا الهجوم يعمل فقط:

  • إذا كان لديك خوادم Exchange داخلية. تدعي Microsoft أنها أغلقت خدماتها السحابية بسرعة ، لذلك لم يتأثر Exchange Online. تأكد أنك تعرف على مكان وجود خوادم Exchange الخاصة بك. حتى إذا كنت تستخدم Exchange Online الآن ، فقد تظل لديك خوادم محلية قيد التشغيل ، وربما تم تركها عن طريق الخطأ من عملية الترحيل.
  • إذا كانت الخوادم الخاصة بك غير مصححة. تأكد أن لديك طبق تحديث برنامج Exchange 2022-11-08 إلى أغلق نقاط الضعف الذي يتطلبه الاستغلال.
  • إذا كانت الخوادم الخاصة بك لا تزال تقبل المصادقة الأساسية ، والمعروفة أيضًا باسم المصادقة القديمة. تأكد أن لديك حظر جميع جوانب المصادقة القديمة لذلك لن تقبل الخوادم الخاصة بك username:password الرؤوس المذكورة أعلاه ، ولن تقبل طلبات بروتوكول الاكتشاف التلقائي المحفوفة بالمخاطر في المقام الأول. هذه توقف المهاجمين خداع خادم لقبول حيل إنشاء كائن مفخخة ، حتى لو لم يتم تصحيح هذا الخادم.

اطلع على استمر بالمتابعة لنصائح الوقاية والمعالجة والاستجابة الرسمية الخاصة بنا ، ويمكن لعملاء Sophos تتبع أسماء اكتشاف التهديدات التي تستخدمها منتجاتنا ، عبر موجز Sophos X-Ops Twitter (تضمين التغريدة).


تعرف على المزيد حول مصادقة التبادل و OAUTH2

انقر واسحب على الموجات الصوتية أدناه للتخطي إلى أي نقطة. يمكنك أيضا استمع مباشرة على Soundcloud.

مع بول دوكلين وتشيستر ويسنيفسكي
موسيقى مقدمة وخاتمة بواسطة إديث مودج.


الطابع الزمني:

اكثر من الأمن عارية