در راستای موضوع آسیبپذیریهای جدی که اخیرا در Microsoft Exchange Server منتشر شده است، در این مقاله یک
آسیب پذیری جدیدی که ProxyToken نامیده میشود، ارائه شده است. این آسیب پذیری در مارس 2021 توسط محققی به نام Le XuanTuyen از VNPT ISC به عنوان Zero Day گزارش شد، و توسط مایکروسافت در به روز رسانی گروهی درجولای 2021 patch شد. شناسه های این آسیب پذیری CVE-2021-33766 و ZDI-CAN-13477 هستند.
یک مهاجم بدون احرازهویت، با استفاده از این آسیب پذیری میتواند پیکربندی صنوق های پستی کاربران دلخواه را تغییر دهند. برای شرح تاثیر این اقدام، می توان از آن برای کپی کردن تمام ایمیل‌های فرستاده شده به هدف و حساب آن و ارسال آنها به حساب کنترل‌شده توسط مهاجم استفاده شود.
The Trigger
ترافیک ضروری HTTP مورد نیاز برای trigger کردن این آسیب پذیری به شرح زیر است :
SecurityToken=X “ ? ” چه چیزی ممکن است باشد؟ کد دسترسی درپشتی[1] مخفی؟
درک علت اصلی
برای درک آنچه که این جا اتفاق افتاده است، لازم است کمی درباره معماری Exchange Server صحبت کنیم. اخیرا یک محقق امنیتی به نام Orange Tsai، محقق امنیتی، کارهای بسیار خوبی در این زمینه انجام داده است، و خوانندگان به خواندن یافته های کامل او در این بخش و همچنین وبلاگ مهمان اخیر او که در این سایت نوشته شده است، تشویق می شوند. با این وجود، برای اهداف این آسیب پذیری خاص، نکات برجسته به صورت زیر خلاصه می شوند:
Microsoft Exchange دو سایت در IIS ایجاد میکند. یکی وبسایت پیش فرض است که روی پورت 80 برای HTTP و 443 برای HTTPS باز است. این سایتی است که همه کلاینتها برای دسترسی وب (OWA، ECP) و رویارویی با سرویس های وب خارجی، به آن متصل میشوند. همچنین این وبسایت به عنوان front end هم شناخته میشود. سایت دیگر Exchange Back End نام دارد و روی پورت 81 برای HTTP و 444 برای HTTPS باز است.
وب سایت front end غالبا فقط یک پروکسی برای back end است. برای دستیابی به دسترسی که نیاز به احراز هویت دارد، front end صفحاتی مانند owa/auth/logon.aspx/ را ارائه میدهد. برای همه درخواستهای بعد از احراز هویت، نقش اصلی front end این است که درخواست ها را مجددا بسته بندی کند و آن ها را برای مکاتبه با نقاط پایانی سایت Exchange Back End پراکسی کند. سپس پاسخ ها را از back end جمع آوری کرده و به مشتری ارسال می کند.
Exchange، یک محصول بسیار پیچیده است، اما این میتواند منجر به ایجاد خلل در جریان معمول شود. به طور خاص، Exchange از ویژگی به نام Delegated Authentication پشتیبانی میکند که این ویژگی از توپولوژی های cross-forest پشتیبانی می کند. در چنین سیاست هایی، front end به تنهایی نمی تواند تصمیمات احراز حویتی را بگیرد. در عوض، front end درخواست ها زا مستقیما به back end میفرستد، back end تعیین میکند که آیا درخواست به درستی احراز هویت شده است یا خیر. این درخواستها که بایستی با استفاده از منطق back end، احراز هویت شوند، با حضور یک کوکی Security Token شناسایی میشوند:
در
Microsoft.Exchange.HttpProxy.ProxyModule.SelectHandlerForUnauthenticatedRequest:
بنابراین، برای درخواستهای داخل /ecp اگر front end یک کوکی غیرخالی به نام Security Token پیدا کند، احراز هویت را به back end واگذار میکند.
کدی که در back end، Security Token را بررسی و اعتبار بخشی میکند در کلاس Microsoft.Exchange.Configuration.DelegatedAuthentication.DelegatedAuthenticationModule یافت میشود. در سمت اعتبار بخشی چه مشکلی پیش میآید؟ برای رسیدن به پاسخ به /ecp/web.config در back end نگاه کنید:
همانطور که میبینید، در پیکربندی پیش فرض محصول، یک المان remove ظاهر میشود، به طوریکه ماژول DelegatedAuthModule برای سایت back end ECP اصلا بارگذاری نمیشود.
به طور خلاصه، وقتی front end، Security Token را میبیند، میداند که back end به تنهایی مسئول احراز هویت این درخواست است. در همین حال، back end کاملا از اینکه باید برخی از درخواست های ورودی را بر اساس کوکی Security Token احراز هویت کند نا آگاه است، از آنجایی که DelegatedAuthModule در نصب هایی که برای استفاده از ویژگی
مخصوص احراز هویت تخصیص داده شده[1] پیکربندی نشده اند، بارگذاری نمیشود. در نتیجه این درخواست ها میتوانند بدون احراز هویت در front end یا back end از طریق آنها عبور کنند.
bagging a Canary
قبل از اینکه بتوان با موفقیت یک درخواست احراز هویت نشده صادر کرد، بایستی یک مانع دیگر نیز برطرف شود، اما به نظر یک مانع جزئی است. هر درخواستی که به صفحه /ecp میرود، نیاز دارد تا یک بلیط داشته باشد که به ECP canary معروف است. بدون یک canary درخواست با یک خطای HTTP 500 بازمیگردد. اگرچه مهاجم همچنان خوش شانس است زیرا پاسخ خطای HTTP 500 با یک canary معتبر همراه است:
این exploit خاص فرض میکند که مهاجم دارای یک حساب کاربری به عنوان قربانی در همان سرور Exchange میباشد. این یک قانون forwarding نصب میکند که به مهاجم اجازه میدهد تمام نامه های دریافتی قربانی را بخواند. یک مدیر سیستم ممکن است در برخی از نصبهای Exchange یک پیکربندی جهانی تنطیم کرده باشد تا مجوز ارسال قوانین دارای مقاصد اینترنتی دلخواه را میدهد و در این حالت، مهاجم به هیچ یک از دسترسی های Exchange نیاز ندارد. علاوه بر این، از آنجایی که کل سایت /ecp به طور بالقوه تاثیر پذیرفته است، ممکن است ابزارهای مختلف دیگری برای exploit کردن نیز موجود باشد.
نتیجه گیری:
Exchange Server همچنان یک منطقه مستعد شگفت انگیر برای تحقیقات آسیبپذیری است. این را میتوان به پیچیدگی زیاد محصول، هم از نظر مجموعه ویژگیها و هم از نظر معماری، نسبت داد. ما در آینده مشتاقانه منتظر دریافت گزارش های آسیبپذیری بیشتر از محققان با استعداد هستیم که در این فضا کار میکنند. تا آن زمان، تیم را برای دریافت جدیدترین تکنیک های exploit و patchهای امنیتی را دنبال کنید.
