افشای آسیب‌پذیری دیگری در سرورهای Exchange
اخیراً جزئیات فنی آسیب‌پذیری خطرناکی در سرورهای Exchange با نام ProxyToken منتشر شده که سوءاستفاده از آن، دستیابی به ایمیل‌های حساب کاربری سازمان را بدون احراز هویت امکان‌پذیر می‌سازد.
در این گزارش که با همکاری شرکت مهندسی شبکه گستر و مرکز مدیریت راهبردی افتای ریاست جمهوری تهیه گردیده، جزئیات آسیب‌پذیری مذکور و نحوه سوءاستفاده از آن ارائه شده است.
مهاجم می‌تواند با ارسال درخواستی به سرویس‌های وب موجود از طریق Exchange Control Panel – به اختصار ECP – اقدام به سوءاستفاده از این آسیب‌پذیری نموده و پیام‌های موجود در صندوق دریافتی (Inbox) کاربران را سرقت کند.
ProxyToken که با شناسه CVE-2021-33766 شناخته می‌شود، بدون احراز هویت، امکان دسترسی به تنظیمات پیکربندی صندوق‌های پستی کاربران را برای مهاجم فراهم می‌کند. جایی که می‌تواند قواعد Email Forwarding را نیز تعریف کند و در جریان آن پیام‌های ارسالی به ایمیل کاربران مورد نظر نیز به حسابی که تحت کنترل مهاجم است، ارسال می‌شود.
این باگ توسط یک محقق ویتنامی کشف شده و از طریق Zero-Day Initiative – به اختصار ZDI – در ماه مارس گزارش شده است. بخش‌های Front End سرور Exchange شامل Outlook Web Access و Exchange Control Panel، عمدتاً به عنوان یک پروکسی برای Back End سرور (Exchange Back End) عمل می‌کند و درخواست‌های احراز هویت را به آن ارسال می‌کند.
در زمان استقرار Exchange، اگر قابلیت “Delegated Authentication” (احراز هویت تفویض شده) فعال شده باشد، Front End درخواست‌هایی را که نیاز به احراز هویت دارند به Back End ارسال می‌کند و آنها را با یک کوکی از نوع توکن امنیتی (SecurityToken) مشخص می‌کند.
وقتی در درخواست کوکی مذکور که از نوع توکن امنیتی (SecurityToken) است، “ecp/” وجود داشته باشد، Front End فرآیند احراز هویت را به Back End واگذار می‌کند. با این حال، پیکربندی پیش فرض Exchange در ECP و ماژولی که مسئول واگذاری اعتبارسنجی (DelegatedAuthModule) است، بارگذاری نمی‌شود.
سوءاستفاده از آسیب‌پذیری ProxyToken در این مرحله انجام نمی‌شود و به اقدام دیگری نیاز دارد: ارسال درخواست به صفحه ecp/ مستلزم تیکتی به نام “ECP canary” است که هنگام فعال کردن خطای HTTP 500 قابل دریافت است. بررسی بیشتر نشان می‌دهد اگر درخواستی فاقد تیکت مذکور که منجر به خطای HTTP 500 می‌شود، باشد، رشته معتبر لازم را برای اجرای موفقیت‌آمیز یک درخواست احراز هویت نشده ندارد.
به طور خلاصه، هنگامی که Front End یک کوکی از نوع توکن امنیتی (SecurityToken) را مشاهده می‌کند، می‌داند که تنها Back End مسئول احراز هویت درخواست است. با توجه به توکن امنیتی دریافتی، Back End کاملاً از احراز هویت درخواست‌های ورودی بی‌اطلاع است، زیرا هنوز DelegatedAuthModule، که قابلیت واگذاری اعتبارسنجی را پیکربندی می‌کند، بارگذاری نشده است.
بر اساس توصیه‌نامه امنیتی منتشر شده توسط شرکت مایکروسافت (Microsoft Corp)، یک وصله در این خصوص در ماه ژوئیه در دسترس عموم قرار گرفته است. آسیب‌پذیری مذکور “حیاتی” (critical) نیست و شدت این ضعف امنیتی 7.5 از 10 گزارش شده است، زیرا مهاجم نیاز به یک حساب کاربری در همان سرور Exchange قربانی دارد. تصویر زیر نمونه‌ای از درخواست یک مهاجم جهت سوءاستفاده از این ضعف امنیتی را نمایش می‌دهد:
در یکی از پست‌های وبلاگ Zero-Day Initiative اشاره شده است که برخی از راهبران یک پیکربندی سراسری (Global) برای سرور Exchange تعیین می‌کنند که منجر به ایجاد قواعد ارسال ایمیل به مقاصد دلخواه می‌شود. در چنین مواردی، مهاجم نیازی به اعتبارسنجی و احراز هویت ندارد.
اگرچه اخیراً جزئیات فنی ProxyToken به صورت عمومی منتشر شده، اما تلاش‌هایی جهت سوءاستفاده از این ضعف امنیتی از سه هفته گذشته گزارش شده است. به گونه‌ای که به نقل از یکی از محققان امنیتی، در 28 مرداد ماه، تلاش‌های فراوانی جهت سوءاستفاده از این ضعف امنیتی مشاهده شده است.
توصیه می‌شود راهبران سرورهای Exchange، نصب آخرین اصلاحیه‌های امنیتی و به‌روزرسانی‌های موسوم به Cumulative Update – به اختصار CU – را جهت ایمن ماندن از گزند حملات مبتنی بر ضعف‌های امنیتی Exchange نظیر ProxyShell و ProxyToken در اولویت خود قرار دهند.
