به دنبال آسیب‌پذیری‌های بحرانی که اخیرا در سرورهای مایکروسافت اکسچنج آشکار شده‌اند، در این مقاله به معرفی یک آسیب‌پذیری جدید با عنوان پروکسی توکن می‌پردازیم.
این آسیب‌پذیری در مارس 2021 توسط یک محقق ویتنامی به سایت طرح روز صفر (ZDI) گزارش شد و در بروزرسانی‌های جامع مایکروسافت در جولای 2021 گنجانده و با شناسه آسیب پذیری CVE-2021-33766 و ZDI-CAN-13477 ثبت شد.
با استفاده از آسیب‌پذیری پروکسی توکن یک مهاجم احرازهویت نشده می‌تواند تنظیمات صندوق‌های پستی را که متعلق به کاربران دلخواه است تغییر بدهد. همچنین مهاجم می‌تواند از این آسیب‌پذیری برای کپی کردن تمام ایمیل‌های ارسال شده قربانی و ارسال رونوشت آن ایمیل‌ها به حساب دلخواه خود استفاده کند.
نحوه اجرای پروکسی توکن
ترافیک موردنیاز HTTP برای فعال شدن آسیب‌پذیری پروکسی توکن به شرح زیر است:
ریشه‌یابی علت
برای اینکه درک واضح‌تری از صورت مسئله آسیب پذیری پروکسی توکن داشته باشیم بهتر است کمی در مورد معماری سرورهای اکسچنج صحبت کنیم. یکی از محققان امنیتی کارهای بسیار خوبی در این زمینه انجام داده است و خوانندگان مشتاق هستند که یافته‌های کامل او را در اینجا و همچنین در پستی که اخیرا به‌عنوان پست مهمان در همین سایت نوشته است مطالعه کنند. به هرحال نکات برجسته مربوط به این آسیب‌پذیری بصورت خلاصه در ادامه بیان شده است:
مایکروسافت اکسچنج دو سایت در وب سرور IIS ایجاد می‌کند یکی وبسایت پیش‌فرض که روی درگاه 80 برای HTTP و درگاه 443 برای HTTPs باز است. این همان سایتی است که تمامی کاربران برای دسترسی به وب(OWA, ECP) و ارتباط از خارج برای دریافت سرویس های وب به آن متصل می‌شوند که با عنوان front end یا سمت کاربر شناخته می‌شود. سایت دیگر اکسچنج Back End است که روی درگاه 81، برای HTTP ودرگاه 444 برای HTTPS باز است.
وبسایت front end (سمت کاربر) عمدتا یک پروکسی برای back end (سمت سرور) است. برای دسترسی به سرویس‌هایی که به احراز هویت نیاز دارد، باید به صفحات Front End کاربر مانند /owa/auth/logon.aspx دسترسی داشت. نقش اصلی Front End این است که همه درخواست‌ها را پس از احراز هویت، مجددا دسته‌بندی کرده و آنها را به سمت مقصد متناظر در بخش Back End اکسچنج هدایت کند. سپس پاسخ‌ها را از سمت سرور جمع‌آوری کرده و به مشتری ارسال نماید.
اکسچنج یک محصول بسیار پیچیده است و همین پیچیدگی گاهی می‌تواند منجر به ایجاد اختلال و مشکلات کوچک در جریان عادی فرایندهای آن شود. اکسچنج از قابلیتی بنام “اعطای احراز هویت نیابتی” پشتیبانی می‌کند که این در شناسایی‌های بین جنگلی یا cross-forest مورد استفاده قرار می‌گیرد. در چنین مواردی، Front end به تنهایی قادر نیست تصمیمات مربوط به احراز هویت را انجام دهد. در عوض، Front End درخواست‌ها را مستقیما به Back End منتقل کرده و برای تعیین صحت احراز هویت‌ها به Back End متکی می شود. این درخواست‌ها که باید با استفاده از منطق Back End احراز هویت شوند، به واسطه‌ی حضور یک کوکی بنام توکن امنیتی یا Security Token شناسایی می‌شوند.
Microsoft.Exchange.HttpProxy.ProxyModule.SelectHandlerForUnauthenticatedRequest
بنابراین برای درخواست‌های موجود در کنترل پنل اکسچنج یا ecp ، اگر بخش front end یک کوکی غیرتهی بنام توکن امنیتی پیدا کند احراز هویت را به back end محول می‌کند.
کدی که در قسمت Back End، مسئول بررسی و اعتبارسنجی کوکی توکن امنیتی است در کلاس زیر یافت می‌شود:
Microsoft.Exchange.Configuration.DelegatedAuthentication.DelegatedAuthenticationModule.
برای اینکه متوجه مشکل در بخش اعتبارسنجی شوید نگاهی به /ecp/web.config در بخش Back End بیاندازید:
همانطور که در کد بالا هم مشاهده می‌کنید، در تنظیمات پیش‌فرض اکسچنج، عبارت <remove> ظاهر شده است در نتیجه ماژول DelegatedAuthModule (ماژول احراز هویت نیابتی) به‌هیچ عنوان برای سایت Back End ECP بارگذاری نمی‌شود.
بطور خلاصه هنگامی که Front End، کوکی توکن امنیتی را می‌بیند، می‌داند که Back End به‌تنهایی مسئولیت احراز هویت این درخواست را به‌عهده دارد. در حالیکه Back End از این موضوع که باید برخی از درخواست‌های ورود حاوی کوکی توکن امنیتی را احراز هویت کند، کاملا بی‌اطلاع است زیرا ماژول احرازهویت نیابتی در سیستم هایی که برای بکارگیری این قابلیت ویژه (احراز هویت نیابتی) تنظیم نشده‌اند بارگذاری نمی شود.
نتیجه نهایی چنین وضعیتی این است که درخواست‌ها می‌توانند بدون اینکه توسط هیچ‌یک از Front End یا Back End مورد احراز هویت قرار گرفته باشند از این مرحله عبور کنند.
بدست آوردن Canary معتبر در پروکسی توکن
برای اینکه بتوان یک درخواست احراز هویت نشده را با موفقیت ثبت کرد، یک مانع جزئی دیگر هم وجود دارد. هر درخواست به صفحه /ecp نیاز به یک برچسب ECP canary دارد. بدون برچسب canary، درخواست با خطای HTTP 500 مواجه می‌شود. با این‌حال بخت با مهاجم یار است، زیرا پاسخ خطای 500 یک canary معتبر به همراه دارد.
در این نوع خاص از سوء استفاده، فرض بر این قرار می‌گیرد که مهاجم در همان سرور اکسچنج قربانی دارای یک حساب کاربری می‌باشد. در این وضعیت، یک قانون رونوشت نصب می‌شود که به مهاجم اجازه می‌دهد تمامی ایمیل‌های دریافتی قربانی را بخواند.
همچنین، در هنگام نصب برخی اکسچنج‌ها، مجری طرح ممکن است یکسری تنظیمات جهانی در اکسچنج تعبیه نماید که ارسال قوانین رونوشت به مقاصد دلخواه اینترنتی را مجاز می‌کند و در چنین حالتی، مهاجم نیازی به هیچگونه اثبات هویت خود نخواهد داشت.
مضافا اینکه چون تمامی سایت ECP بطور بالقوه تحت چنین تاثیری قرار می‌گیرد، ابزارهای گوناگون دیگری نیز می توانند برای سوء‌استفاده در دسترس قرار گیرند.
نتیجه‌گیری
سرور اکسچنج کماکان فضای بسیار مستعدی برای تحقیقات آسیب‌پذیری است، که این وضعیت را می‌توان به پیچیدگی خارق العاده محصول چه از نظر مجموعه‌ی قابلیت‌ها و چه از نظر معماری نسبت داد. ما در آینده مشتاقانه منتظر دریافت گزارش‌های آسیب‌پذیری بیشتر از جانب محققان با استعداد خود که در این حوزه مشغول به فعالیت هستند می‌باشیم. تا آن زمان، برای آگاهی از جدیدترین روشهای سوء استفاده گزارش‌های امنیتی تیم ما را دنبال کنید.
