CVE-2020-0688: اجرای کد به صورت از راه دور^[۱] روی Microsoft Exchange Server با استفاده از کلیدهای رمزنگاشتی ثابت

در آخرین اصلاحیه[۲] انتشاریافته، مایکروسافت، برای رسیدگی به یک باگ “اجرای کد به صورت از راه دور” در Microsoft Exchange Server، یک اصلاحیه با درجه شدت “با اهمیت”[۳] منتشر کرد. این آسیب‌پذیری توسط یک پژوهشگر ناشناس گزارش شده و روی همه نسخه‌های پشتیبانی شده از Microsoft Exchange تا زمان انتشار اصلاحیه اخیر تاثیرگذار است.

در ابتدا، مایکروسافت، دلیل این باگ را یک آسیب‌پذیری “خرابی حافظه”[۴] ذکر و بیان کرد که با ارسال یک “ایمیل به طور خاص ساخته شده” به یک سرور Exchange آسیب‌پذیر، امکان بهره‌برداری از این باگ وجود دارد. در ادامه، مایکروسافت در بیانیه خود تجدیدنظر کرده و (به درستی) بیان کرد که این آسیب‌پذیری از ناتوانی سرور Exchange در تولید مناسب کلیدهای یکتا در زمان نصب ناشی می‌شود.

به طور مشخص، این باگ در مولفه Exchange Control Panel (ECP) یافته شده است. ماهیت این باگ کاملا ساده است. به جای داشتن کلیدهای تولید شده به صورت تصادفی در هر نصب، تمام نصب‌های Microsoft Exchange Server دارای مقادیر یکسان validationKey و decryptionKey در web.config هستند. این کلیدها برای تامین امنیت ViewState استفاده می‌شوند. ViewState داده سمت سروری است که برنامه‌های کاربردی تحت وب ASP.NET در قالب سریال‌شده[۵] در سمت کارخواه[۶] ذخیره می‌کنند. کارخواه این داده‌ها را از طریق پارامتر درخواست __VIEWSTATE به سمت سرور بازمی‌گرداند.

شکل ۱. قسمتی از فایل web.config شامل validationKey ثابت

به دلیل استفاده از کلیدهای ثابت، یک مهاجم احراز هویت‌شده می‌تواند سرور را به deserialize کردن داده‌های ViewState ساخته شده به طور بدخواهانه فریب دهد. با کمک YSoSerial.net، یک مهاجم می‌تواند به اجرای کدهای .NET دلخواه در چارچوب برنامه‌ی تحت وب Exchange Control Panel که به عنوان SYSTEM اجرا می‌شود، بپردازد.

برای بهره‌برداری از این آسیب‌پذیری لازم است تا مقادیر ViewStateUserKey و VIEWSTATEGENERATOR را از یک نشست احراز هویت‌شده جمع‌آوری کنیم. ViewStateUserKey را می‌توان از کوکی SessionID به دست آورد درحالیکه __VIEWSTATEGENERATOR را می‌توان در یک فیلد مخفی یافت.

تمام این مقادیر را می‌توان به سادگی و با استفاده از ابزارهای استاندارد توسعه‌دهندگان در مرورگر به دست آورد.

برای شروع، به صفحه “/ecp/default.aspx” رفته و وارد سیستم شوید. حساب کاربری استفاده شده نیازی به داشتن هیچ امتیاز[۱] خاصی ندارد. در این مثال، از یک حساب کاربری با نام user استفاده می‌کنیم:

[۱] Privilege

برای ادامه، لازم است تا اطلاعاتی را جمع‌آوری کنیم. تا بدین‌جا، با ارزش‌ترین قسمت را به دست آورده‌ایم:

validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF

validationalg = SHA1

برای به دست آوردن ViewStateUserKey و  __VIEWSTATEGENERATOR، تب Network از Dev Tools (F12) را باز کرده و درخواست را با فشردن F5 مجددا ارسال کنید. حال به پاسخ خام[۸] درخواست ارسال شده به “/ecp/default.aspx”، درحالیکه در سیستم هستیم، نیاز داریم.

همانطور که مشاهده می‌کنید مقدار __VIEWSTATEGENERATOR در Source صفحه قابل‌رویت است. در این مثال، مقدار آن برابر با B97B4E27 است. به احتمال زیاد، مقدار شما نیز همین خواهد بود. در ادامه، تب Headers را باز کرده و کوکی ASP.NET_SessionId را در سرآیندهای[۹] درخواست بیابید:

در این مثال، این مقدار برابر با ۰۵ae4b41-51e1-4c3a-9241-6b87b169d663 است.

حال، تمام اطلاعات موردنیاز برای پیش بردن یک حمله را در اختیار داریم:

–validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF

–validationalg = SHA1

–generator = B97B4E27

–viewstateuserkey = 05ae4b41-51e1-4c3a-9241-6b87b169d663

گام بعد عبارت است از ایجاد یک Payload با استفاده از ysoserial.net. یک Payload تولید می‌کنیم که با ایجاد فایل “C:\Vuln_Server.txt” نشان‌دهنده اجرای کد باشد:

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c “echo OOOPS!!! > c:/Vuln_Server.txt” –validationalg=”SHA1″ –validationkey=”CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF” –generator=”B97B4E27″ –viewstateuserkey=”05ae4b41-51e1-4c3a-9241-6b87b169d663″ –isdebug –islegacy

در نهایت، نیاز داریم تا Payload (ViewState) را به صورت URL کدگذاری کرده و با جایگزینی generator و ViewState کدگذاری شده به صورت URL به دست آمده در بالا، یک URL به صورت زیر ایجاد کنیم:

/ecp/default.aspx?__VIEWSTATEGENERATOR=<generator>&__VIEWSTATE=<ViewState>

در ادامه، URL به دست آمده را به سادگی با قرار دادن آن در نوار آدرس مرورگر به سرور Exchange ارسال می‌کنیم:

سرور یک ۵۰۰ Unexpected Error بازمی‌گرداند اما حمله به طور موفقیت‌آمیز به اتمام می‌رسد. برای بررسی تاثیر بر روی سرور هدف:

مطمئنا، اکنون فایل “Vuln_Server.txt” موجود است. بررسی اطلاعات مربوط به مالکیت در فایل تایید‌کننده این مهم است که این فایل توسط فرایندی با توکن SYSTEM ایجاد شده است.

این مساله نشان‌دهنده این است که یک مهاجم قادر است به عنوان SYSTEM به اجرای کدهای دلخواه بپردازد و به طور کامل سرور Exchange هدف را Compromise کند.

نتیجه

مایکروسافت این آسیب‌پذیری را به عنوان CVE-2020-0688 در فوریه ۲۰۲۰ Patch کرد. بر اساس بیانیه نوشته شده توسط آن‌ها، این آسیب‌پذیری با اصلاح نحوه تولید کلیدها توسط Microsoft Exchange در فرایند نصب برطرف شده است. به بیان دیگر، اکنون آن‌ها کلیدهای رمزنگاشتی را در زمان نصب به صورت تصادفی انتخاب می‌کنند. مایکروسافت این آسیب‌پذیری را به عنوان یک آسیب‌پذیری با شدت مهم درجه‌بندی کرده است. احتمالا، دلیل اعطا این درجه به این آسیب‌پذیری این است که یک مهاجم باید در ابتدا احراز هویت شود. با این حال، باید ذکر شود که در یک شرکت، به هر کاربری اجازه داده می‌شود تا به سرور Exchange احراز هویت شود. به طور مشابه، هر مهاجم بیرونی که دستگاه یا Credentialهای یک کاربر شرکت را Compromise کرده باشد می‌تواند کنترل سرور Exchange را به دست گیرد. پس از تحقق این امر، مهاجم در موقعیتی قرار می‌گیرد که می‌تواند ارتباطات ایمیلی شرکت را افشا یا تحریف کند. بر این اساس، اگر مدیر یک سرور Exchange هستید، باید این Patch را از درجه اهمیت “حیاتی”[۱۰] در نظر گرفته و در اولین فرصت ممکن آن را به کار گیرید. مایکروسافت درجه Exploit Index این آسیب‌پذیری را ۱ بیان کرده که این بدین معنی است که آن‌ها انتظار دارند تا تنها در بازه‌ای۳۰ روزه از انتشار Patch مربوطه، شاهد بهره‌برداری از این باگ باشند. همانطور که نشان داده شده، این قطعیت محتمل به نظر می‌رسد.

[۱] Remote code execution

[۲] Patch

[۳] Important

[۴] Memory corruption

[۵] Serialized

[۶] Client

[۷] Privilege

[۸] Raw

[۹] Headers

[۱۰] Critical