به تازگی جزئیات فنی آسیب‌پذیری خطرناکی در Exchange با نام ProxyToken منتشر شده است که سوءاستفاده از آن، دستیابی به ایمیل‌های حساب کاربری سازمان را بدون احراز هویت امکان‌پذیر می‌سازد.
به گزارش مرکز مدیریت راهبردی افتا، مهاجم می‌تواند با ارسال درخواستی به سرویس‌های وب موجود از طریق Exchange Control Panel به‌اختصار ECP اقدام به سوءاستفاده از این آسیب‌پذیری کرده و پیام‌های موجود در صندوق دریافتی (Inbox) کاربران را سرقت کند.
ProxyToken که با شناسه CVE-۲۰۲۱-۳۳۷۶۶ شناخته می‌شود، بدون احراز هویت، امکان دسترسی به تنظیمات پیکربندی صندوق‌های پستی کاربران را برای مهاجم فراهم می‌کند. جایی که می‌تواند قواعد 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 ۵۰۰ قابل دریافت است. بررسی بیشتر نشان می‌دهد اگر درخواستی فاقد این تیکت که منجر به خطای HTTP ۵۰۰ می‌شود، باشد، رشته اعتبار لازم را برای اجرای موفقیت‌آمیز یک درخواست احراز هویت نشده ندارد.
به طور خلاصه، هنگامی که Front End یک کوکی از نوع توکن امنیتی (SecurityToken) را مشاهده می‌کند، می‌داند که تنها Back End مسئول احراز هویت درخواست است. باتوجه‌به توکن امنیتی دریافتی، Back End کاملاً از احراز هویت درخواست‌های ورودی بی‌اطلاع است، زیرا هنوز (DelegatedAuthModule) که قابلیت واگذاری اعتبارسنجی را تنظیم (پیکربندی) می‌کند بارگذاری نشده است.
بر اساس توصیه‌نامه امنیتی منتشر شده توسط شرکت مایکروسافت (Microsoft Corp)، یک وصله دراین‌خصوص در ماه ژوئیه در دسترس عموم قرار گرفته است. این آسیب‌پذیری “حیاتی” (Critical) نیست و شدت این ضعف امنیتی ۷,۵ از ۱۰ گزارش شده است، زیرا مهاجم نیاز به یک حساب کاربری در همان سرور Exchange قربانی دارد. تصویر زیر نمونه‌ای از درخواست یک مهاجم جهت سوءاستفاده از این ضعف امنیتی را نمایش می‌دهد:
در یکی از پست‌های وبلاگ Zero-Day Initiative اشاره شده است که برخی از راهبران یک پیکربندی سراسری (Global) برای سرور Exchange تعیین می‌کنند که منجر به ایجاد قواعد ارسال ایمیل به مقاصد دلخواه می‌شود. در چنین مواردی، مهاجم نیازی به اعتبارسنجی و احراز هویت ندارد.
اگرچه اخیراً جزئیات فنی ProxyToken به‌صورت عمومی منتشر شده، اما تلاش‌هایی برای سوءاستفاده از این ضعف امنیتی از سه هفته گذشته گزارش شده است. به‌گونه‌ای که به نقل از یکی از محققان امنیتی، در ۲۸ مردادماه، تلاش‌های فراوانی جهت سوءاستفاده از این ضعف امنیتی مشاهده شده است.
توصیه می‌شود راهبران سرورهای Exchange، نصب آخرین اصلاحیه‌های امنیتی و به‌روزرسانی‌های موسوم به Cumulative Update به‌اختصار CU را جهت ایمن ماندن از گزند حملات مبتنی بر ضعف‌های امنیتی Exchange نظیر ProxyShell و ProxyToken در اولویت خود قرار دهند.
منبع:
دیدگاه شما