S3 Ep102.5: أخطاء تبادل "ProxyNotShell" - أحد الخبراء يتحدث [صوت + نص]

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

[مودم موسيقي]

---

بطة.  مرحبا بالجميع.

مرحبًا بكم في حلقة صغيرة خاصة أخرى من بودكاست Naked Security.

أنا بول دوكلين ، انضم إلينا مرة أخرى صديقي وزميلي تشيستر ويسنيفسكي.

مرحبا شيت.

---

الشيت.  [لهجة أسترالية مزيفة] جي يوم ، بطة.

---

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

ويجب أن تكون ذات ماسورة مزدوجة يوم الصفر في Microsoft Exchange التي تم طرحها في الغسيل إلى حد كبير في اليوم الأخير من سبتمبر 2022:

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

لن يكون الأمر على هذا النحو في نهاية هذا الأسبوع لمسؤولي النظام ومديري تكنولوجيا المعلومات!

---

الشيت.  البطة ، على ما أعتقد ، في الكلمات الخالدة للمغادر دوغلاس آدامز ، "لا تُصب بالذعر" قد يكون بالترتيب.

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

ولكن إذا كنت تقوم بتشغيل Exchange داخل المؤسسة ...

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

---

بطة.  إذن كذلك CVE-2022-41040 و CVE-2022-41042... هذا شيء ممتع للغاية.

لقد رأيت أنه يشار إليه على Twitter كـ ProxyNotShell، لأنه يحتوي على بعض أوجه التشابه مع بروكسيشيل الضعف الذي كان يمثل القصة الكبيرة منذ أكثر من عام بقليل ،

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

---

الشيت.  هذا ما يبدو عليه الأمر.

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

يبدو أنهم كشفوا بمسؤولية تلك نقاط الضعف لمبادرة Zero Day [ZDI] التي تديرها Trend Micro للإبلاغ عن ثغرات يوم الصفر بشكل مسؤول.

وبالطبع ، قامت ZDI بدورها بمشاركة كل تلك المعلومات الاستخباراتية مع Microsoft ، منذ ما يزيد قليلاً عن ثلاثة أسابيع.

والسبب في طرحه اليوم هو أنني أعتقد أن المجموعة الفيتنامية ...

... يبدو أنهم بدأوا ينفد صبرهم قليلاً ويخشون أن مرت ثلاثة أسابيع وأنه لم يتم إرسال أي تنبيهات أو نصائح للمساعدة في حماية الناس من هؤلاء الممثلين المزعومين للدولة القومية.

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

---

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

يبدو كما لو أن أيًا من الاستغلال بمفرده ليس خطيرًا بشكل خاص ...

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

---

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

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

---

بطة.  الآن ، لا نعرف بالضبط نوع أوراق الاعتماد التي يحتاجون إليها ، لأنه في الوقت الذي نسجل فيه هذا [2022-09-30T23: 00: 00Z] ، لا يزال كل شيء سرًا إلى حد كبير.

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

بعد تقديم كلمة المرور ، ومع ذلك ، إذا كانت هناك مصادقة ثنائية [2FA] ، يتم تشغيل الخطأ الأول (الذي يفتح الباب) * بين النقطة التي يتم فيها توفير كلمة المرور والنقطة التي ستكون عندها رموز 2FA طلب*.

إذن أنت بحاجة إلى كلمة المرور ، لكنك لست بحاجة إلى رمز 2FA ...

---

الشيت.  يبدو أنها "ثغرة أمنية متوسطة المصادقة" ، إذا كنت تريد تسميتها كذلك.

هذه نعمة مختلطة.

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

لقد رأينا عودة الديدان في الأشهر الثمانية عشر الماضية على حساب العديد من المنظمات.

---

بطة.  "دودة"؟

---

الشيت.  Wormage ، نعم! [يضحك]

---

بطة.  هل هذه كلمة؟

حسنًا ، إذا لم يكن كذلك ، فهو الآن!

يعجبني ذلك ... قد أقترضه ، تشيستر. [يضحك]

---

الشيت.  أعتقد أن هذا قابل للديدان بشكل معتدل ، أليس كذلك؟

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

عندما تتحدث عن مئات أو آلاف المستخدمين ... في العديد من المؤسسات ، فمن المحتمل أن يكون لدى واحد أو اثنين منهم كلمات مرور سيئة.

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

لكن هذا الهجوم لا يتطلب العامل الثاني.

لذا ، فإن مجرد الحصول على تركيبة اسم مستخدم وكلمة مرور يعد عائقًا منخفضًا جدًا…

---

بطة.  الآن هناك تعقيد آخر هنا ، أليس كذلك؟

وهي على الرغم من ذلك دليل مايكروسوفت يقول رسميًا أن عملاء Microsoft Exchange عبر الإنترنت يمكنهم التخلي عن Blue Alert ، فهذا أمر خطير فقط إذا كان لديك Exchange داخل الشركة ...

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

---

الشيت.  على وجه التحديد!

لقد رأينا هذا يعود إلى ProxyLogin و ProxyShell.

في كثير من الحالات ، دخل المجرمون إلى شبكتهم من خلال خوادم Exchange التي ظنوا أنهم لا يمتلكونها.

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

... كانت لا تزال ، في الواقع ، قيد التشغيل وممكّنة ومعرضة للإنترنت.

والأسوأ من ذلك ، عندما لا يُعرف وجودهم هناك ، تقل احتمالية حصولهم على التصحيح.

أعني ، المنظمات التي لديها Exchange على الأقل ربما تبذل قصارى جهدها لجدولة الصيانة عليها على أساس منتظم.

ولكن عندما لا تعرف أن لديك شيئًا ما على شبكتك "لأنك نسيت" ، وهو أمر سهل حقًا مع الأجهزة الافتراضية ، فأنت في وضع أسوأ ، لأنك ربما لم تقم بتطبيق تحديثات Windows أو تحديثات Exchange.

---

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

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

---

الشيت.  نعم ، للأسف ، كانت هذه بالتأكيد تجربتي!

يبدو الأمر سخيفًا ، ولكن فحص الشبكة الخاصة بك لمعرفة ما لديك هو شيء نوصيك بفعله بشكل منتظم على أي حال.

لكن بالتأكيد ، عندما تسمع عن نشرة مثل هذه ، إذا كانت منتجًا تعرف أنك استخدمته في الماضي ، مثل Microsoft Exchange ، فهذا هو الوقت المناسب لتشغيل ذلك الداخلي مسح Nmap...

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

---

بطة.  نحن نعلم الآن من استجابة Microsoft الخاصة أنها تتفادى بجنون لإخراج التصحيحات.

عندما تظهر هذه التصحيحات ، من الأفضل أن تقوم بتطبيقها بسرعة كبيرة ، أليس كذلك؟

لأنه إذا كان سيتم استهداف أي رقعة للهندسة العكسية لاكتشاف الاستغلال ، فسيكون شيئًا من هذا النوع.

---

الشيت.  نعم ، بالتأكيد يا بطة!

حتى عندما تقوم بالتصحيح ، ستكون هناك نافذة للوقت ، أليس كذلك؟

أعني ، عادةً Microsoft ، لـ Patch Tuesdaydays على أي حال ، قم بتحرير تصحيحاتها في الساعة 10.00 صباحًا بتوقيت المحيط الهادئ.

نحن في الوقت الحالي في التوقيت الصيفي ، لذا فهذا هو UTC-7 ... لذلك ، في حوالي الساعة 17:00 بالتوقيت العالمي المنسق ، عادةً ما تصدر Microsoft تصحيحات ، بحيث يكون لدى معظم موظفيها يوم كامل للرد على الاستفسارات الواردة في سياتل. [مقر مايكروسوفت في بيلفيو ، سياتل ، واشنطن].

المفتاح هنا هو نوع من "السباق" لساعات ، وربما دقائق ، اعتمادًا على مدى سهولة استغلال هذا ، قبل أن يبدأ في الحدوث.

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

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

كان هذا وقتًا كافيًا للحصول على هذه الخوادم قشور الويب, cryptominers، كل أنواع خلفي مثبتة عليها.

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

... * بعد * التصرف ، من المفيد الرجوع والتحقق بدقة من تلك الأنظمة بحثًا عن أدلة على أنها ربما تعرضت للهجوم في الفجوة بين الوقت الذي أصبح فيه التصحيح متاحًا والوقت الذي تمكنت فيه من تطبيقه.

أنا متأكد من أنه سيكون هناك الكثير من المحادثات على Naked Security وما بعده تويتر وأماكن أخرى ، نتحدث عن أنواع الهجمات التي نراها حتى تعرف ما الذي تبحث عنه.

---

بطة.  بينما يمكنك البحث عن مجموعة من تجزئات البرامج الضارة المعروفة التي تم توزيعها بالفعل في عدد محدود من الهجمات ...

... خلاصة القول هي أن جميع أنواع البرامج الضارة هي احتمالات.

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

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

---

الشيت.  لذلك أعتقد أن هذا يقودنا نحو ، "ماذا سنفعل الآن بينما ننتظر التصحيح؟"

تم إصدار مدونة Microsoft Security Research Center (MSRC) بعض نصائح التخفيف والتفاصيل ... بقدر ما ترغب Microsoft في الكشف عنه في هذا الوقت.

أود أن أقول ، إذا كنت نقيًا Microsoft Exchange عبر الإنترنت العميل ، أنت في وضع واضح تمامًا ويجب عليك فقط الانتباه في حالة تغير الأمور.

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

بالطبع ، في وقت التسجيل ، هذا هو ظهر يوم الجمعة ... لذلك ، حقًا ، عندما تستمع إلى هذا ، "على الفور ، كلما سمعت ذلك ، إذا لم تكن قد فعلت ذلك بالفعل."

ما هي أفضل الممارسات هنا ، بطة؟

من الواضح أن أحد الأشياء التي يمكنك القيام بها هو إيقاف تشغيل الوصول إلى الويب الخارجي حتى يتوفر التصحيح.

يمكنك فقط إيقاف تشغيل خادم IIS الخاص بك وبعد ذلك سيفعل ذلك!

---

بطة.  أظن أن العديد من الشركات لن تكون في هذا الموقف.

وتسرد Microsoft شيئين يقولون ... حسنًا ، لا يقولون ، "هذا سيعمل بالتأكيد."

يقترحون أنه سيحد بشكل كبير من المخاطر الخاصة بك.

إحداها أن هناك قاعدة لإعادة كتابة عنوان URL يمكنك تطبيقها على خادم IIS الخاص بك. (ما أفهمه هو أن IIS هو الذي يقبل الاتصال الوارد الذي يتحول إلى الوصول إلى خدمات Exchange عبر الويب [EWS].)

لذلك ، هناك إعداد IIS يمكنك إجراؤه يبحث عن عمليات الاستغلال المحتملة للفتحة الأولى ، والتي ستمنع بدء تشغيل PowerShell.

وهناك بعض منافذ TCP التي يمكنك حظرها على خادم Exchange.

أعتقد أنه المنفذ 5985 و 5986 ، الذي سيوقف ما يسمى PowerShell عن بُعد... سيوقف هذا الأمر أوامر التنفيذ عن بُعد الخاصة بـ PowerShell المارقة في خادم Exchange.

لاحظ ، مع ذلك ، أن Microsoft تقول أن هذا "سيحد" من تعرضك ، بدلاً من الوعد بأنهم يعرفون أنه يصلح كل شيء.

وقد يكون ذلك لأنهم يشكون في وجود طرق أخرى يمكن أن يحدث بها ذلك ، لكنهم لم يكتشفوا ما هي عليه بعد. [يضحك]

لا يعد أي من الإعدادين شيئًا تفعله في Exchange نفسه.

أحدهما موجود في IIS ، والآخر هو نوع من قواعد تصفية الشبكة.

---

الشيت.  حسنًا ، هذا مفيد لنا خلال الأيام القليلة المقبلة بينما تقدم لنا Microsoft إصلاحًا دائمًا.

النبأ السار هو أنني أعتقد أن الكثير من برامج الأمان ، سواء كانت IPS يمكن دمجها في جدار الحماية الخاص بك ، أو منتجات أمان نقطة النهاية التي تحمي بنية Microsoft Windows Server الأساسية الخاصة بك ...

... الهجمات لهذا الغرض ، في كثير من الحالات (على الأقل التقارير المبكرة) ، تبدو مشابهة جدًا لـ ProxyLogon ، ونتيجة لذلك ، ليس من الواضح ما إذا كانت القواعد الحالية ستحمي من هذه الهجمات.

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

---

بطة.  هذا صحيح ، تشيستر.

والخبر السار لعملاء Sophos هو أنه يمكنك تتبع الاكتشافات الخاصة بـ Sophos إذا كنت تريد الذهاب والبحث في سجلاتك.

ليس فقط لـ IPS ، سواء كانت IPS على جدار الحماية أو نقطة النهاية ، ولكن لدينا أيضًا مجموعة من القواعد السلوكية.

يمكنك تتبع أسماء الكشف هذه إذا كنت تريد البحث عنها ... اتبع ذلك على تضمين التغريدة تويتر تغذية.

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

أضاف Sophos X-Ops الاكتشافات التالية:

يقوم Troj / WebShel-EC و Troj / WebShel-ED بالكشف عن قشور الويب التي تمت مناقشتها في الهجمات.

IPS signature sid: 2307757 استنادًا إلى المعلومات التي نشرتها Microsoft لكل من Sophos XG Firewall وكذلك Sophos Endpoint IPS.

- Sophos X-Ops (SophosXOps) 30 سبتمبر 2022

---

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

لكنني على ثقة تامة من أننا لن نكون قادرين على وضع هذا في الفراش لفترة طويلة الآن….

---

بطة.  أعتقد ، مثل ProxyShell ، مثل Log4Shell ، سيكون هناك صدى يتردد صداها لبعض الوقت.

لذلك ربما كان من الأفضل أن نقول ، كما نفعل دائمًا ، تشيستر:

حتى المرة القادمة ...

---

على حد سواء.  ابق آمنًا.

[مودم موسيقي]