S3 Ep102.5: "ProxyNotShell" اشکالات تبادل - یک متخصص صحبت می کند [صوت + متن]

تمبر زمان: 1 اکتبر 2022، 10:05 صبح
گره منبع: 1712650

by
پل داکلین

نترسید... اما برای اقدام آماده باشید

با پل داکلین و چستر ویسنیفسکی

موسیقی مقدماتی و بیرونی توسط ادیت ماج.

برای پرش به هر نقطه، روی امواج صوتی زیر کلیک کنید و بکشید. شما همچنین می توانید مستقیم گوش کن در Soundcloud

شما می توانید به ما گوش دهید Soundcloud, پادکست های اپل, پادکست های Google, Spotify, Stitcher به و هر جایی که پادکست های خوب پیدا می شود. یا فقط رها کنید URL فید RSS ما به پادکچر مورد علاقه شما

رونوشت را بخوانید

[مودم موزیکال]

اردک.  سلام به همه.

به یکی دیگر از مینی اپیزود ویژه پادکست Naked Security خوش آمدید.

من پل داکلین هستم که دوباره دوست و همکارم چستر ویسنیفسکی به او پیوست.

سلام، چت.

CHET.  [لهجه جعلی AUSSIE] G’day، Duck.

اردک.  خوب، چت، من مطمئن هستم که همه گوش می دهند. اگر مدت کوتاهی پس از انتشار پادکست در حال گوش دادن باشند، می‌داند که در مورد چه چیزی صحبت خواهیم کرد!

و باید این دو لول باشد مایکروسافت اکسچنج روز صفر که تقریباً در آخرین روز سپتامبر 2022 در شستشو بیرون آمد:

علاقه‌مندان فروش ما می‌گویند: «اوه، آخر ماه است، آخر یک چهارم است، یک زمان دیوانه‌وار است… اما فردا همه به 0 دلار بازنشانی می‌شوند.»

این آخر هفته برای Sysadmins و مدیران IT اینطور نخواهد بود!

CHET.  اردک، فکر می کنم، به قول جاودانه مرحوم داگلاس آدامز، "وحشت نکنید" ممکن است درست باشد

بسیاری از سازمان‌ها دیگر ایمیل خود را در سرورهای Exchange میزبانی نمی‌کنند، بنابراین تعداد زیادی از افراد می‌توانند نفس عمیقی بکشند و اجازه دهند زمان کمی در این آخر هفته بگذرد، بدون اینکه زیاد در مورد آن استرس داشته باشند.

اما اگر Exchange on-premise را اجرا می کنید…

...اگر من بودم، ممکن بود چند ساعت اضافه کار کنم تا بتوانم چند مورد تخفیف را اعمال کنم، تا مطمئن شوم که در روز دوشنبه یا سه شنبه که به احتمال زیاد این اتفاق به چیزی بیشتر تبدیل می شود، غافلگیری ناخوشایندی نداشته باشم. نمایشی.

اردک.  که اینطور CVE-2022-41040 و CVE-2022-41042... این کاملاً لقمه است.

من دیده ام که در توییتر به آن اشاره شده است ProxyNotShell، زیرا شباهت هایی به آن دارد پروکسی شل آسیب پذیری که یک سال پیش داستان بزرگ بود،

اما اگرچه این شباهت‌ها را دارد، اما یک جفت اکسپلویت کاملاً جدید است که با هم زنجیره می‌شوند و به طور بالقوه اجرای کد از راه دور را می‌دهند – آیا این درست است؟

CHET.  این چیزی است که به نظر می رسد.

این آسیب‌پذیری‌ها در طی یک حمله فعال علیه قربانی کشف شدند، و یک سازمان ویتنامی به نام GTSC این دو آسیب‌پذیری جدید را که به دشمنان اجازه می‌داد به برخی از مشتریان خود دسترسی پیدا کنند، کشف کرد.

به نظر می رسد که آنها مسئولانه فاش کرده اند آن آسیب پذیری ها به Zero Day Initiative [ZDI] که توسط Trend Micro برای گزارش مسئولانه آسیب‌پذیری‌های روز صفر اجرا می‌شود.

و البته، ZDI نیز به نوبه خود، کمی بیش از سه هفته پیش، تمام این اطلاعات را با مایکروسافت به اشتراک گذاشت.

و دلیل اینکه امروز منتشر می شود این است که فکر می کنم گروه ویتنامی…

... به نظر می رسد که آنها کمی بی تاب شده و نگران هستند که سه هفته گذشته است و هیچ هشدار یا توصیه ای برای کمک به محافظت از مردم در برابر این بازیگران ادعایی دولت-ملت منتشر نشده است.

بنابراین آنها تصمیم گرفتند که زنگ خطر را به صدا درآورند و به همه اطلاع دهند که باید کاری برای محافظت از خود انجام دهند.

اردک.  و انصافاً با دقت گفتند: ما قصد نداریم دقیقاً نحوه استفاده از این آسیب‌پذیری‌ها را فاش کنیم، اما می‌خواهیم اقدامات کاهشی را به شما ارائه دهیم که به نظر ما مؤثر است.»

به نظر می رسد که هر کدام از این اکسپلویت ها به تنهایی خطرناک نیستند…

... اما با هم زنجیر شده اند، به این معنی است که شخصی خارج از سازمان که توانایی خواندن ایمیل از روی سرور شما را دارد، می تواند در واقع از اولین باگ برای باز کردن درب، و باگ دوم برای نصب بدافزار در سرور Exchange شما استفاده کند.

CHET.  و این نکته بسیار مهمی است که شما گفتید، اردک، "کسی که می تواند ایمیل را در سرور شما بخواند."

این یک حمله *غیر احراز هویت* نیست، بنابراین مهاجمان برای اجرای موفقیت آمیز این حملات باید اطلاعاتی در مورد سازمان شما داشته باشند.

اردک.  اکنون، ما دقیقاً نمی دانیم که آنها به چه نوع اعتبارنامه ای نیاز دارند، زیرا در زمانی که ما این [2022-09-30T23:00:00Z] را ضبط می کنیم، همه چیز هنوز تا حد زیادی مخفی است.

اما از آنچه خوانده‌ام (از افرادی که تمایل به باور آنها دارم)، به نظر می‌رسد که کوکی‌های جلسه یا نشانه‌های احراز هویت به اندازه کافی خوب نیستند و در واقع به رمز عبور کاربر نیاز دارید.

پس از ارائه رمز عبور، اما اگر احراز هویت دو مرحله ای [2FA] وجود داشت، اولین باگ (مشکلی که در را باز می کند) * بین نقطه ای که رمز عبور ارائه می شود و نقطه ای که کدهای 2FA در آن قرار می گیرند ایجاد می شود. درخواست شده*.

بنابراین شما به رمز عبور نیاز دارید، اما به کد 2FA نیاز ندارید…

CHET.  به نظر می رسد که این یک "آسیب پذیری احراز هویت میانی" است، اگر می خواهید آن را اینطور بنامید.

این یک نعمت مختلط است.

این بدان معنی است که یک اسکریپت خودکار پایتون نمی‌تواند کل اینترنت را اسکن کند و به طور بالقوه از هر سرور Exchange در جهان در عرض چند دقیقه یا چند ساعت سوء استفاده کند، همانطور که در سال 2021 با ProxyLogon و ProxyShell شاهد بودیم.

ما شاهد بازگشت کرم در 18 ماه گذشته بودیم که به ضرر بسیاری از سازمان ها بود.

اردک.  "ورماژ"؟

CHET.  ورماژ، بله! [می خندد]

اردک.  این یک کلمه است؟

خوب، اگر نیست، الان هست!

من آن را دوست دارم... ممکن است آن را قرض بگیرم، چستر. [می خندد]

CHET.  فکر می‌کنم این حالت خفیف کرم‌دار است، درست است؟

شما به یک رمز عبور نیاز دارید، اما متأسفانه یافتن یک آدرس ایمیل و ترکیب رمز عبور معتبر در هر سرور Exchange معین، احتمالاً چندان دشوار نیست.

وقتی در مورد صدها یا هزاران کاربر صحبت می کنید ... در بسیاری از سازمان ها، احتمالاً یک یا دو نفر از آنها رمز عبور ضعیفی دارند.

و ممکن است تا به امروز مورد سوء استفاده قرار نگرفته باشید، زیرا برای ورود موفقیت آمیز به Outlook Web Access [OWA] به نشانه FIDO، یا احراز هویت آنها، یا هر عامل دومی که ممکن است استفاده کنید، نیاز است.

اما این حمله به آن عامل دوم نیاز ندارد.

بنابراین، فقط به دست آوردن یک ترکیب نام کاربری و رمز عبور یک مانع بسیار کم است…

اردک.  اکنون پیچیدگی دیگری در اینجا وجود دارد، اینطور نیست؟

یعنی اینکه اگرچه دستورالعمل مایکروسافت رسماً می‌گوید که مشتریان Microsoft Exchange Online می‌توانند از Blue Alert کنار بیایند، این فقط در صورتی خطرناک است که تبادل داخلی داشته باشید…

... تعداد شگفت انگیزی از افرادی وجود دارند که احتمالاً چندین سال پیش به cloud تغییر مکان داده اند و در حین تغییر هم زمان در محل خود و هم سرویس ابری خود را اجرا می کردند، که هرگز موفق به خاموش کردن داخلی نشدند. سرور تبادل.

CHET.  دقیقا!

دیدیم که این به ProxyLogin و ProxyShell برمی گردد.

در بسیاری از موارد، مجرمان از طریق سرورهای Exchange که فکر می‌کردند نداشتند، وارد شبکه خود شدند.

مثلاً، کسی لیست ماشین‌های مجازی در حال اجرا بر روی سرور VMware خود را بررسی نکرد تا متوجه شود که سرورهای Exchange مهاجرتی آن‌ها که در حین انتقال داده‌ها بین شبکه داخلی و شبکه ابری به آنها کمک می‌کنند…

… در واقع هنوز روشن و فعال و در معرض اینترنت بودند.

و بدتر از آن، وقتی مشخص نیست که آنجا هستند، حتی کمتر احتمال دارد که وصله شده باشند.

منظورم این است که سازمان‌هایی که Exchange دارند حداقل احتمالاً برای برنامه‌ریزی منظم تعمیر و نگهداری آنها تلاش می‌کنند.

اما وقتی نمی‌دانید چیزی در شبکه خود دارید «به دلیل اینکه فراموش کرده‌اید»، که واقعاً با ماشین‌های مجازی آسان است، در وضعیت بدتری قرار می‌گیرید، زیرا احتمالاً به‌روزرسانی‌های ویندوز یا به‌روزرسانی‌های Exchange را اعمال نکرده‌اید.

اردک.  و قانون مورفی می گوید که اگر واقعاً به آن سرور متکی باشید و به درستی از آن مراقبت نکنید، درست یک روز قبل از اینکه واقعاً به آن نیاز داشته باشید از کار می افتد.

اما اگر نمی‌دانید وجود دارد و می‌توان از آن برای بد استفاده کرد، احتمالاً این احتمال وجود دارد که سال‌ها و سال‌ها و سال‌ها بدون هیچ مشکلی اجرا شود. [می خندد]

CHET.  بله، متأسفانه، مطمئناً این تجربه من بوده است!

احمقانه به نظر می رسد، اما اسکن شبکه خود برای یافتن آنچه دارید چیزی است که به هر حال توصیه می کنیم به طور منظم انجام دهید.

اما مطمئناً، وقتی در مورد بولتنی مانند این می شنوید، اگر محصولی است که می دانید در گذشته از آن استفاده کرده اید، مانند Microsoft Exchange، زمان خوبی برای اجرای آن داخلی است. اسکن Nmap...

... و حتی شاید وارد شوید shodan.io و سرویس های خارجی خود را بررسی کنید، فقط برای اینکه مطمئن شوید همه چیز خاموش شده است.

اردک.  ما اکنون از پاسخ خود مایکروسافت می دانیم که آنها دیوانه وار در حال تلاش برای بیرون آوردن وصله ها هستند.

وقتی آن تکه‌ها ظاهر می‌شوند، بهتر است آن‌ها را خیلی سریع اعمال کنید، اینطور نیست؟

زیرا اگر قرار باشد هر وصله ای برای مهندسی معکوس برای کشف اکسپلویت هدف قرار گیرد، چیزی از این دست خواهد بود.

CHET.  بله، قطعا، اردک!

حتی زمانی که وصله کنید، یک پنجره زمانی وجود خواهد داشت، درست است؟

منظورم این است که مایکروسافت معمولاً برای سه شنبه های پچ، پچ های خود را در ساعت 10.00 صبح به وقت اقیانوس آرام منتشر می کند.

در حال حاضر ما در زمان نور روز هستیم، بنابراین UTC-7 است… بنابراین، حدود ساعت 17:00 UTC معمولاً زمانی است که مایکروسافت وصله‌ها را منتشر می‌کند، به طوری که اکثر کارکنان آن تمام روز را فرصت دارند تا سپس به درخواست‌های دریافتی در سیاتل پاسخ دهند. [مرکز مایکروسافت در بلوو، سیاتل، WA است.]

نکته کلیدی در اینجا این است که نوعی «مسابقه» از ساعت‌ها، شاید دقیقه‌ها وجود دارد، بسته به اینکه چقدر می‌توان از آن بهره‌برداری کرد، قبل از شروع آن.

و دوباره، با بازگشت به آن سوء استفاده‌های قبلی Exchange با ProxyShell و ProxyLogon، اغلب متوجه شدیم که حتی مشتریانی که ظرف سه، چهار، پنج روز وصله کرده‌اند…

... که صادقانه بگویم، برای یک سرور Exchange تا حدودی سریع است، وصله کردن آنها بسیار دشوار است، با آزمایش های زیادی برای اطمینان از قابل اعتماد بودن آن قبل از اینکه سرورهای ایمیل خود را مختل کنید، بسیار دشوار است.

این زمان برای دریافت آن سرورها کافی بود پوسته های وب, رمزگشایی، انواع درب پشتی روی آنها نصب شده است.

و بنابراین، وقتی پچ رسمی منتشر شد، نه تنها باید سریع عمل کنید…

…*بعد از* اقدام، ارزش این را دارد که به عقب برگردید و آن سیستم ها را برای شواهدی مبنی بر اینکه ممکن است در فاصله زمانی که پچ در دسترس قرار گرفت و زمانی که شما قادر به اعمال آن هستید مورد حمله قرار گرفته اند، بررسی کنید.

من مطمئن هستم که گفتگوهای زیادی در مورد امنیت برهنه و همینطور ادامه خواهد داشت توییتر و جاهای دیگر، در مورد انواع حملاتی که می بینیم صحبت می کنیم تا بدانید به دنبال چه چیزی باشید.

اردک.  در حالی که می توانید بروید و به دنبال دسته ای از هش های بدافزار شناخته شده بگردید که قبلاً در تعداد محدودی از حملات توزیع شده اند…

... واقعاً، نکته اصلی این است که همه انواع بدافزارها احتمالاتی هستند.

و بنابراین، همانطور که من فکر می کنم شما در آن گفتید آخرین مینی اپیزود که ما انجام دادیم، دیگر فقط منتظر ماندن برای هشدارهای اتفاق بدی که در داشبورد شما ظاهر شده است کافی نیست:

شما باید فعالانه بیرون بروید و نگاه کنید، در صورتی که کلاهبرداران قبلاً در شبکه شما بوده اند و چیزی را پشت سر گذاشته اند (که ممکن است برای سال ها وجود داشته باشد!) که هنوز متوجه آن نشده اید.

CHET.  بنابراین فکر می کنم این ما را به سمتی هدایت می کند، "حالا در حالی که منتظر پچ هستیم، چه کنیم؟"

وبلاگ مرکز تحقیقات امنیتی مایکروسافت (MSRC) منتشر شد برخی توصیه های کاهش و جزئیات… به همان اندازه که مایکروسافت در حال حاضر مایل به افشای آن است.

من می گویم، اگر شما خالص هستید Microsoft Exchange Online مشتری، شما تقریباً واضح هستید و فقط باید در صورت تغییر شرایط توجه کنید.

اما اگر در یک موقعیت ترکیبی هستید، یا هنوز Microsoft Exchange را به صورت داخلی اجرا می‌کنید، فکر می‌کنم احتمالاً کارهایی وجود دارد که ارزش انجام آن را امروز بعدازظهر یا فردا صبح دارد.

البته، در زمان ضبط، امروز بعد از ظهر جمعه است… بنابراین، واقعاً، وقتی به این گوش می‌دهید، «فوراً، هر زمان که آن را می‌شنوید، اگر قبلاً آن را انجام نداده‌اید».

بهترین شیوه ها در اینجا چیست، اردک؟

بدیهی است که یک کاری که می توانید انجام دهید این است که دسترسی به وب خارجی را تا زمانی که یک پچ در دسترس قرار گیرد، خاموش کنید.

شما فقط می توانید سرور IIS خود را خاموش کنید و سپس این کار را انجام دهید!

اردک.  من گمان می کنم که بسیاری از شرکت ها در آن موقعیت قرار نخواهند داشت.

و مایکروسافت دو چیز را لیست می کند که آنها می گویند ... خوب، آنها نمی گویند، "این قطعا کار خواهد کرد."

آنها پیشنهاد می کنند که خطر شما را تا حد زیادی محدود می کند.

یکی این است که یک قانون بازنویسی URL وجود دارد که می توانید آن را روی سرور IIS خود اعمال کنید. (درک من این است که این IIS است که اتصال ورودی را می پذیرد که به دسترسی به خدمات وب Exchange [EWS] تبدیل می شود.)

بنابراین یک تنظیم IIS وجود دارد که می توانید ایجاد کنید که به دنبال سوء استفاده های احتمالی از اولین سوراخ است، که از راه اندازی PowerShell جلوگیری می کند.

و برخی از پورت های TCP وجود دارد که می توانید آنها را در سرور Exchange خود مسدود کنید.

من معتقدم این پورت 5985 و 5986 است که چیزی را که نامیده می شود متوقف می کند PowerShell از راه دور... این دستورات اجرای از راه دور PowerShell سرکش را به سرور Exchange منتقل نمی کند.

با این حال، توجه داشته باشید که مایکروسافت می‌گوید این قرار گرفتن در معرض شما را «محدود» می‌کند، نه اینکه قول دهد که می‌داند همه چیز را برطرف می‌کند.

و این ممکن است به این دلیل باشد که آنها گمان می‌کنند راه‌های دیگری نیز وجود دارد که می‌تواند باعث این شود، اما هنوز کاملاً متوجه نشده‌اند که چه هستند. [می خندد]

هیچ کدام از این تنظیمات کاری نیست که شما در خود Exchange انجام دهید.

یکی از آنها در IIS است و دیگری نوعی قانون فیلتر شبکه است.

CHET.  خوب، این برای ما مفید است تا چند روز آینده را طی کنیم، در حالی که مایکروسافت به ما یک تعمیر دائمی ارائه می دهد.

خبر خوب این است که من فکر می‌کنم بسیاری از نرم‌افزارهای امنیتی، چه یک IPS باشد که ممکن است در فایروال شما یکپارچه شده باشد، چه محصولات امنیتی نقطه پایانی که از زیرساخت‌های مایکروسافت ویندوز سرور محافظت می‌کنند…

... حملات برای این، در بسیاری از موارد (حداقل گزارش های اولیه)، بسیار شبیه به ProxyLogon هستند، و در نتیجه، مشخص نیست که آیا قوانین موجود در برابر این حملات محافظت می کنند یا خیر.

آنها ممکن است، اما علاوه بر آن، به نظر می‌رسد که اکثر فروشندگان سعی می‌کنند آن‌ها را کمی سخت‌تر کنند تا اطمینان حاصل کنند که تا حد ممکن آماده هستند، بر اساس همه شاخص‌هایی که در حال حاضر به‌طور عمومی به اشتراک گذاشته شده‌اند، بنابراین آنها را شناسایی می‌کنند و اگر این هشدارها در سرورهای Exchange شما رخ دهد، به شما هشدار می دهد.

اردک.  درست است، چستر.

و خبر خوب برای مشتریان Sophos این است که اگر می‌خواهید بروید و لاگ‌های خود را بررسی کنید، می‌توانید شناسایی‌های خاص Sophos را ردیابی کنید.

نه فقط برای IPS، چه IPS روی دیوار آتش یا نقطه پایانی، بلکه ما همچنین یک سری قوانین رفتاری داریم.

اگر می‌خواهید به دنبال آن‌ها بگردید، می‌توانید آن نام‌های شناسایی را ردیابی کنید… آن را در قسمت دنبال کنید @SophosXops فید توییتر

با دریافت نام‌های شناسایی جدید که می‌توانید از آنها برای شکار تهدید استفاده کنید، آنها را در آنجا منتشر می‌کنیم تا بتوانید به راحتی آنها را جستجو کنید:

CHET.  مطمئنم در پادکست هفته آینده چیزهای بیشتری برای گفتن خواهیم داشت، چه داگ دوباره به شما بپیوندد یا اینکه من بار دیگر در صندلی مهمان باشم.

اما من کاملاً مطمئن هستم که ما نمی‌توانیم این را برای مدتی طولانی بخوابانیم….

اردک.  من فکر می کنم، مانند ProxyShell، مانند Log4Shell، یک پژواک برای مدتی طولانی طنین انداز خواهد شد.

پس شاید بهتر است مثل همیشه چستر بگوییم:

تا دفعه بعد…

هر دو.  ایمن بمان

[مودم موزیکال]

تمبر زمان:

بیشتر از امنیت برهنه