ProxyToken: دورزدن احراز هویت در Microsoft Exchange

ProxyToken: دورزدن احراز هویت در Microsoft Exchange

ProxyToken: دورزدن احراز هویت در Microsoft Exchange

در راستای موضوع آسیب­پذیری­های جدی که اخیرا در 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های امنیتی را دنبال کنید.

اشتراک گذاری این مقاله