چگونه یک سرور Exchange وصله نشده را با کد پاورشل تقلبی هک کنیم

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

همانطور که ما در آن زمان توصیه شد، این آسیب پذیری ها، به طور رسمی تعیین شده است CVE-2022-41040 و CVE-2022-41082:

دو روز صفر بود که [می‌توانستند] به هم زنجیر شوند، با اولین باگ از راه دور برای باز کردن حفره کافی برای راه‌اندازی باگ دوم استفاده می‌شد، که به طور بالقوه امکان اجرای کد از راه دور (RCE) را در خود سرور Exchange می‌دهد.

اولین آسیب‌پذیری یادآور دردسرساز بود و به‌طور گسترده مورد سوء استفاده قرار گرفت حفره امنیتی ProxyShell از آگوست 2021، زیرا بر رفتار خطرناک در ویژگی کشف خودکار Exchange متکی بود، توصیف شده توسط مایکروسافت به عنوان یک پروتکل که است «استفاده شده توسط مشتریان Outlook و EAS [Exchange ActiveSync] برای یافتن و اتصال به صندوق‌های پستی در Exchange».

خوشبختانه، ویژگی نادرست Autodiscover که می‌توانست در حمله ProxyShell توسط هر کاربر راه دور، خواه وارد سیستم شده باشد یا نه، مورد سوء استفاده قرار گیرد. بیش از یک سال پیش وصله شده است.

متأسفانه، وصله‌های ProxyShell به اندازه کافی برای بستن اکسپلویت به روی کاربران احراز هویت شده، انجام ندادند، که منجر به روز صفر جدید CVE-2022-40140 شد، که به‌زودی به‌طور غیرمعمول، اگر گمراه‌کننده بود. دوبله شده ProxyNotShell.

نه به همان اندازه خطرناک، اما خطرناک است

واضح است که ProxyNotShell به اندازه ProxyShell اصلی خطرناک نبود، با توجه به اینکه به چیزی که به عنوان دسترسی تأیید شده نیاز داشت، بنابراین برای هیچکس از هرجایی قابل سوء استفاده نبود.

اما به سرعت مشخص شد که در بسیاری از سرورهای Exchange، دانستن نام ورود و رمز عبور هر کاربر برای تأیید اعتبار و نصب این حمله کافی است، حتی اگر آن کاربر خودش نیاز به استفاده از احراز هویت دو مرحله‌ای (2FA) داشته باشد تا به درستی وارد سیستم شود و دسترسی داشته باشد. ایمیل آنها.

به عنوان کارشناس سوفوس چستر ویسنیفسکی آن را بگذار به هنگام:

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

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

اما این حمله به آن عامل دوم نیاز ندارد. […] فقط به دست آوردن نام کاربری و رمز عبور یک مانع بسیار کم است.

همانطور که احتمالاً به خاطر دارید، بسیاری از ما تصور می‌کردیم (یا حداقل امیدوار بودیم) که مایکروسافت برای رفع حفره‌های ProxyNotShell عجله کند، با توجه به اینکه هنوز دو هفته تا سه‌شنبه پچ اکتبر باقی مانده است.

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

حتی پچ سه‌شنبه نوامبر به‌طور مستقیم اصلاحات مورد نیاز را ارائه نکرد، هرچند وصله‌ها با این حال بیرون آمد در همان روز به عنوان بخشی از یک به‌روزرسانی امنیتی خاص Exchange که می‌توان به‌طور جداگانه واکشی و نصب کرد:

اثبات مفهوم فاش شد

اکنون که گرد و غبار فروکش کرده است و همه فرصت دارند تا سرورهای Exchange خود را وصله کنند (سرورهایی که حداقل آنها را فراموش نکرده اند)، محققان Zero Day Initiative (ZDI)، که این آسیب پذیری ها در ابتدا به طور مسئولانه برای ارائه به آن افشا شده بودند. مایکروسافت، توضیح داده شده اند چگونه می توان از اشکالات سوء استفاده کرد.

خبر بد، بسته به نظر شما در مورد افشای سوء استفاده آشکار، این است که تیم ZDI اکنون به طور موثر یک اثبات مفهوم (PoC) ارائه کرده است که نحوه حمله به سرورهای Exchange را توضیح می دهد.

البته خبر خوب این است که:

• ما اکنون می توانیم خودمان باگ ها را مطالعه و درک کنیم. این نه تنها به همه ما کمک می‌کند تا اطمینان حاصل کنیم که اقدامات احتیاطی کلی که انجام داده‌ایم (نه فقط محدود به وصله کردن) احتمالاً محافظتی را که انتظار داریم ارائه می‌کند، بلکه به ما در مورد شیوه‌های برنامه‌نویسی که می‌خواهیم در آینده اجتناب کنیم، اطلاع می‌دهد، بنابراین ما انجام نمی‌دهیم. به دام باز کردن باگ هایی از این نوع در کد سمت سرور خودمان نمی افتیم.
• در حال حاضر هیچ بهانه ای برای عدم استفاده از پچ ها باقی نمانده است. اگر برای به‌روزرسانی تلاش کرده‌ایم، توضیح ZDI در مورد اینکه چرا حمله کار می‌کند، روشن می‌کند که درمان قطعاً بر بیماری ارجحیت دارد.

چگونه کار می کند

ZDI ها توضیح این آسیب‌پذیری، داستانی جذاب را به وجود می‌آورد که نشان می‌دهد چقدر پیچیده است که تمام بخش‌هایی را که برای تبدیل یک آسیب‌پذیری به یک اکسپلویت قابل دوام به آن نیاز دارید، به هم متصل کنید.

همچنین ارزش خواندن دارد تا به شما کمک کند بفهمید چرا کاوش در یک اکسپلویت موجود می‌تواند به کشف راه‌های دیگری که از یک آسیب‌پذیری ممکن است سوء استفاده شود کمک کند، به‌طور بالقوه باعث ایجاد وصله‌های اضافی، اصرار به تغییرات پیکربندی، و ترویج شیوه‌های برنامه‌نویسی جدید که ممکن است صرفاً از رفع آن آشکار نبوده باشند. سوراخ اصلی

توضیح لزوماً پیچیده و کاملاً فنی است و شما را از طریق یک سری مراحل طولانی برای دستیابی به اجرای کد از راه دور (RCE) در پایان راهنمایی می کند.

به امید اینکه اگر تصمیم دارید گزارش ZDI را بخوانید، به شما کمک کند جزئیات سطح بالا را راحت‌تر دنبال کنید، در اینجا یک خلاصه نه چندان ساده با مراحل ذکر شده در معکوس آمده است…

بنابراین شما از قبل می دانید که چرا داستان مسیرهایی را که انجام می دهد دنبال می کند:

• مرحله 4. Exchange را از راه دور فریب دهید تا یک شی دات نت مورد نظر شما را با یک پارامتر مقداردهی اولیه به انتخاب شما نمونه سازی کند.

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

اشیا ممکن است توسط خود سیستم عامل مدیریت و کنترل شوند تا از انواع خطاهای سوء مدیریت حافظه رایج در زبانی مانند C جلوگیری شود، جایی که معمولاً باید خودتان حافظه را تخصیص دهید، فیلدهای داده مربوطه را با دست پر کنید، و به یاد داشته باشید که پس از اتمام کار، حافظه و منابعی که استفاده می کنید، مانند سوکت های شبکه یا فایل های دیسک را آزاد کنید.

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

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

به بیان ساده، اگر شما مثال می زنید، بگویید، 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. از راه دور Exchange را فریب دهید تا از آن استفاده کند PowerShell از راه دور ویژگی برای ایجاد یک شی بر اساس پارامترهای مقداردهی اولیه کنترل شده خارجی.

و این به دلیل حفره ProxyShell مانند که فقط نیمه وصله شده بود امکان پذیر بود:

• مرحله 1. از راه دور Exchange را فریب دهید تا با بسته بندی یک درخواست معتبر، یک درخواست وب با کد را بپذیرد و پردازش کند. username:password را نیز وارد درخواست کنید.

حتی اگر کاربر نام‌گذاری شده در درخواست واقعاً وارد نشده باشد و برای دسترسی به صندوق پستی خود باید نوعی فرآیند 2FA را طی کند، مهاجمی که می‌داند username:password این ترکیب دارای اطلاعات احراز هویت کافی برای فریب Exchange برای پذیرش یک اتصال وب است که می تواند برای شروع زنجیره حمله شرح داده شده در مراحل 2 تا 4 در بالا استفاده شود.

به زبان ساده، هر یک معتبر است username:password با توجه به اینکه "احراز هویت" صرفاً برای جلوگیری از رد درخواست HTTP توسط Exchange مورد نیاز بود.

چه کاری انجام دهید؟

توجه داشته باشید که این حمله فقط کار می کند:

• اگر سرورهای Exchange درون محل دارید. مایکروسافت ادعا می کند که سرویس های ابری خود را به سرعت قفل کرده است، بنابراین Exchange Online تحت تأثیر قرار نمی گیرد. مطمئن شوید که شما بدانید سرورهای Exchange شما کجا هستند. حتی اگر اکنون از Exchange Online استفاده می کنید، ممکن است همچنان سرورهای داخلی در حال اجرا داشته باشید که شاید به اشتباه از فرآیند مهاجرت شما باقی مانده باشد.
• اگر سرورهای شما بدون وصله هستند. مطمئن شوید که به روز رسانی نرم افزار Exchange در 2022-11-08 را اعمال کرد به آسیب پذیری ها را ببندید که بهره برداری مستلزم آن است.
• اگر سرورهای شما هنوز احراز هویت اولیه را می‌پذیرند که به عنوان احراز هویت قدیمی نیز شناخته می‌شود. مطمئن شوید که تمام جنبه های احراز هویت قدیمی را مسدود کرد بنابراین سرورهای شما آن را نمی پذیرند username:password سرصفحه های ذکر شده در بالا، و در وهله اول درخواست های پرخطر پروتکل Autodiscover را نمی پذیرند. این مهاجمان را متوقف می کند فریب دادن سرور برای پذیرش ترفندهای نمونه سازی اشیاء به دام افتاده آنها، حتی اگر آن سرور وصله نشده باشد.

تو می توانی پیگیری کنید از توصیه‌های رسمی پیشگیری، اصلاح و پاسخ ما، و مشتریان Sophos می‌توانند نام‌های تشخیص تهدید استفاده شده توسط محصولات ما را از طریق فید توییتر Sophos X-Ops پیگیری کنند.@SophosXOps).

اطلاعات جدیدی در مورد CVE-2022-41040 و CVE-2022-41082 منتشر شده است: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) نوامبر 21، 2022

---

درباره احراز هویت EXCHANGE و OAUTH2 بیشتر بیاموزید

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

---