ProxyShell، آسیب امنیتی جدید Exchange

در  آوریل 2021، یکی از پژوهشگران امنیتی تیم DEVCORE، خبر از کشف باگ جدیدی تحت عنوان پروکسی شل (ProxyShell) در سرویس مایکروسافت اکسچنج داد که قابلیت “اجرای کد از راه دور” یا RCE را برای مهاجم فراهم می‌کرد. این پژوهشگر تا کنون موفق شده است چندین مشکل امنیتی دیگر را در اکسچنج کشف کند و برخی از یافته‌های خود را در کنفرانس اخیر بلک هت (Black Hat) ارائه دهد.

آسیب‌پذیری‌های ثبت شده پروکسی شل

مشکلات امنیتی در این آسیب که تحت عنوان پروکسی شل شناخته شده است، در چند شناسه جداگانه توسط مایکروسافت ثبت شده است:

شناسه  CVE-2021-34473: آسیب‌پذیری از نوع اجرای کد از راه دور در اکسچنج

شناسه CVE-2021-34523: آسیب‌پذیری از نوع ارتقاء مجوز دسترسی در Back End پاور شل اکسچنج

شناسه CVE-2021-31207: یا  Post-auth Arbitrary-File-Write و اجرای کد از راه دور

آسیب پذیری پروکسی شل به مهاجم احراز هویت نشده اجازه می‌دهد دستورات مورد نظر خود را از طریق پورت 443 در مایکروسافت اکسچنج اجرا کند.

در ادامه این مقاله، هر سه آسیب‌پذیری را با مثال شرح داده‌ایم.

شناسه  CVE-2021-34473 سردرگمی در مسیر پیش از احراز هویت

اولین آسیب‌پذیری پروکسی‌ شل، مشابه حمله SSRF در آسیب‌پذیری ProxyLogon است. این آسیب‌پذیری به مهاجم اجازه می‌دهد درخواست‌هایی با امضاهای جعلی به یک سرور آسیب‌پذیر ارسال کند و این درخواست‌ها در سرور مذکور معتبر شناخته می‌شوند.

برای سواستفاده از این آسیب‌پذیری باید درخواست‌هایی ایجاد شود که بخش Front End (خدمات دسترسی به مشتری یا CAS) پردازش و محاسبه URL برای Back End را انجام می‌هد. به این منظور باید کمی با انواع درخواست ورود در اکسچنج آشنا باشیم.

هنگامی که درخواست ورود یک کلاینت از نوع صریح یا Explicit باشد، اکسچنچ درخواست آدرس وب‌سایت را نرمال‌سازی کرده و بخش آدرس صندوق‌پستی را قبل از هدایت درخواست به بخش Back End حذف می‌کند.

ورود صریح یا Explicit Login یک قابلیت ویژه در اکسچنج است که به مرورگر امکان جاسازی یا نمایش صندوق پستی یا تقویم کاربر  در یک URL واحد را می‌دهد.

برای اجرای این قابلیت، آدرس اینترنتی باید ساده باشد و آدرس صندوق پستی را نیز نمایش دهد. برای مثال:

https://exchange/OWA/user@orange.local/Default.aspx

طی تحقیقات مشخص شد که در کنترل‌کننده‌های خاصی مانند EwsAutodiscoverProxyRequestHandler می‌توان آدرس صندوق‌پستی را از طریق پرس و جوی رشته یا Query string پیدا کرد. از آنجا که اکسچنج، بررسی‌های استانداردی روی آدرس صندوق‌پستی انجام نمی‌دهد، می‌توان در فرایند نرمال‌سازی، بخشی از URL را از طریق Query string برای بدست آوردن یک URL دلخواه در backend حذف کرد:

همانطور که در کد بالا مشاهده می‌شود، اگر URL از کنترل IsAutodiscoverV2PreviewRequest عبور کند، می‌توان آدرس ورود صریح را از طریق پارامتر Email در کوئری استرینگ مشخص کرد. روش کار بسیار ساده است چرا که فقط یک اعتبارسنجی ساده از پسوند URL انجام می‌دهد.

سپس آدرس ورود صریح، به‌عنوان یک پارامتر ورودی برای RemoveExplicitLogonFromUrlAbsoluteUri ارسال می‌شود و این روش فقط از Substring برای پاک کردن الگویی که مشخص می‌کنیم استفاده می‌کند.

حال به آدرس URL زیر دقت کنید. این URL را برای سواستفاده از فرایند نرمال‌سازی آدرس ورود به URL ورود صریح طراحی کرده‌ایم:

https://exchange/autodiscover/autodiscover.json?@foo.com/?&Email=autodiscover/autodiscover.json%3f@foo.com

این نرمال‌سازی دستکاری‌شده URL، به ما اجازه می‌دهد به‌عنوان صاحب یک حساب کاربری اکسچنج به یک URL دلخواه در Backend دسترسی داشته باشیم. اگرچه این مشکل به‌اندازه حمله SSRF در ProxLogon قدرتمند نیست و تنها می‌توانیم قسمت مسیر URL را تغییر دهیم؛ اما هنوز هم می‌توانیم حملاتی را از طریق دسترسی به URL دلخواه در backend انجام دهیم.

شناسه CVE-2021-34523: آسیب‌پذیری از نوع ارتقا مجوز دسترسی در بخش Backend پاورشل اکسچنج

تا اینجا ما توانستیم به URLهای مورد نظرمان در backend دسترسی داشته باشیم. قدم بعدی استفاده از این نفوذ و بهره‌برداری از آن است.

به دلیل وجود سیاست کنترل دسترسی RBAC که به صورت موثری از اکسچنج محافظت می‌کند، اجرای عملیات غیرمجاز ProxyLogon  و ایجاد یک نشست ECP ممنوع است. بنابراین ما باید رویکرد جدیدی برای کدهای مخرب پیدا کنیم.

در اینجا تمرکز ما بر روی قابلیتی بنام دسترسی از راه دور پاورشل اکسچنج یا PowerShell Remoting است.

قابلیت PowerShell Remoting در اکسچنج، امکان ارسال ایمیل، خواندن ایمیل و حتی به‌روزرسانی پیکربندی Command Line را به کاربران می‌دهد. قابلیت دسترسی از راه دور پاورشل اکسچنج براساس WS-Management ساخته شده است و Cmdlets متعددی را برای اتوماسیون پیاده‌سازی می‌کند. با این‌حال بخش‌های احراز هویت و مجوزدهی همچنان برپایه معماری اصلی CAS است.

اگرچه تا اینجا ما توانستیم به پشتیبان backend پاورشل اکسچنج دسترسی داشته باشیم، اما هنوز نمی‌توانیم به‌درستی با آن تعامل داشته باشیم. زیرا صندوق پستی معتبری برای کاربران سیستم NT AUTHORITYSYSTEM وجود ندارد. همچنین ما نمی‌توانیم هدر X-CommonAccessToken ایجاد کنیم که هویت ما را جعل کرده و به‌عنوان یک کاربر دیگر نمایش دهد.

حال باید دید چه کار دیگری می‌توانیم انجام دهیم. با بررسی کامل پیاده‌سازی بخش backend پاورشل اکسچنج،  قطعه کد جالبی پیدا کردیم که می‌تواند برای تعیین هویت کاربر از طریق URL، مورد استفاده قرار بگیرد.

ConfigurationRemotePowershellBackendCmdletProxyModule.cs

از طریق قطعه کد فوق، هنگامی که backend پاورشل، نتواند هدر X-CommonAccessToken را در درخواست جاری پیدا کند سعی می‌کند از پارامتر X-Rps-CAT کوئری استرینگ برای بازیابی هویت کاربر استفاده کند. به‌نظر می‌رسد این قطعه کد برای ارتباط داخلی پاورشل اکسچنج طراحی شده است.

از آنجا که می‌توانیم مستقیما به backend دسترسی داشته باشیم و مقدار دلخواه را در X-Rps-CAT مشخص کنیم، قابلیت جعل هویت هر کاربری را هم خواهیم داشت.

در نتیجه ما از این موضوع برای تغییر حساب کاربری SYSTEM -که صندوق پستی هم ندارد-، به حساب Exchange Admin استفاده می‌کنیم. حالا ما می‌توانیم دستورات دلخواه پاورشل اکسچنج را با سطح دسترسی مدیر اکسچنج اجرا کنیم!

شناسه CVE-2021-31207:یا  Post-auth Arbitrary-File-Write و اجرای کد از راه دور

آخرین بخش از آسیب‌پذیری‌های زنجیروار Exchange، پیدا کردن یک روش برای اجرای کد از راه دور یا RCE با استفاده از دستورات پاورشل اکسچنج است.

برای این کار مشکلی نداریم، چرا که حالا ما مدیر هستیم و صدها دستور وجود دارد که می‌توانیم از آنها استفاده کنیم. در اینجا با استفاده از دستور New-MailboxExportRequest می‌توان صندوق پستی کاربر را به یک مسیر مشخص انتقال داد.

New-MailboxExportRequest -Mailbox orange@orange.local -FilePath \127.0.0.1C$pathtoshell.aspx

این دستور بسیار مفید است، زیرا به ما امکان می‌دهد یک فایل را در یک مسیر دلخواه ایجاد کنیم. این فایل می‌تواند صندوق‌پستی یک کاربر باشد که ایمیل‌های وی را ذخیره می‌کند. بنابراین ما این امکان را داریم که به راحتی یک بسته‌ اطلاعاتی مخرب را از طریق SMTP وارد ایمیل‌های کاربر کنیم. تنها مشکل این است که محتوای ایمیل در قالب متن ساده ذخیره نمی‌شود؛ چون نتوانستیم بسته اطلاعاتی خود را در فایل منتقل شده پیدا کنیم.

ظاهرا خروجی، با فرمت پوشه‌های شخصی (PST) اوت لوک نگه‌داری می‌شود. پس با مطالعه مستندات رسمی مایکروسافت متوجه شدیم که فایل PST از یک رمزگذاری جایگزین ساده برای کدگذاری بسته اطلاعاتی استفاده می‌کند. بنابراین ما می‌توانیم بسته اطلاعاتی را قبل از ارسال رمزگذاری کنیم و هنگامی که سرور سعی در ذخیره و رمزگذاری بسته اطلاعاتی دارد آن‌را به کد مخرب اصلی تبدیل می‌کند.

اجرای کد مخرب

مرحله اول: تحویل بسته اطلاعاتی حاوی کد مخرب

ابتدا از طریق SMTP، وب شل رمزنگاری شده (وب شل یک رابط مبتنی بر shell است که امکان دسترسی و کنترل از راه دور به سرور را فراهم می‌کند) را به صندوق‌پستی موردنظر تحویل می‌دهیم. در صورتی که میل سرور از ارسال ایمیل از طرف کاربر غیرمجاز پشتیبانی نکند، می‌توان از یک حساب Gmail به‌عنوان جایگزین برای تحویل بسته‌های اطلاعاتی مخرب استفاده کرد.

مرحله دوم: تشکیل نشست یا Session پاورشل

از آنجا که PowerShell مبتنی بر پروتکل WinRM است و پیاده‌سازی WinRM کار آسانی نیست، ما از پروکسی سرور برای سرقت اطلاعات اتصال به پاورشل و دستکاری ترافیک استفاده می‌کنیم.

ابتدا URL را در مسیر EwsAutodiscoverProxyRequestHandler بازنویسی می‌کنیم که سبب ایجاد مشکل و سردرگمی در مسیر می‌شود و به ما اجازه می‌دهد که به backend پاورشل دسترسی پیدا کنیم. سپس با واردکردن پارامتر X-Rps-CAT در کوئری استرینگ می‌توانیم هویت کاربران را جعل کنیم. در مثال زیر هویت کاربر به admin تغییر داده شده است:

مرحله سوم: اجرای دستور مخرب پاورشل

در نشست پاورشل، دستورات زیر را اجرا می‌کنیم:

1-دستور New-ManagementRoleAssignment برای واگذاری نقش import  و export کردن صندوق پستی

2- دستور New-MailboxExportRequest برای Export کردن صندوق پستی که حاوی بسته اطلاعاتی مخرب ما به webroot است و به‌عنوان وب شل عمل ما می‌کند.

چند قدم پایانی

پس از کشف آسیب‌پذیری ProxyLogon، نرم‌افزار Windows Defender فرایندهای خطرناکی که توسط webroot اکسچنچ سرور انجام می‌شد را مسدود کرد. بنابراین، ما برای ایجاد شل در Pwn2Own زمانی را صرف دور زدن Defender کردیم. متوجه شدیم که اگر مستقیما cmd.exe را فراخوانی کنیم دیفندر ما را مسدود می‌کند. اما در صورتی که توسط Scripting.FileSystemObjec فایل cmd.exe را توسط webroot به هر نامی مانند random.exe کپی کرده واجرا کنیم، Defender جلوی ما را نخواهد گرفت!

همچنین، در برخی از سازمان‌ها که از اکسچنچ سرور کلاستر (خوشه‌ایی) استفاده می‌کند، گاهی اوقات یک اکسپشن InvalidShellID رخ می‌دهد.

دلیل مشکل این است که در اینجا با Load Balancer سر و کار داریم و برای موفق شدن به کمی شانس نیاز داریم. بهتر است اینجا اکسپشن را دریافت کرده و مجدد درخواست را برای رفع شدن آن ارسال کنیم.

انتشار پچ یا افزونه امنیتی توسط مایکروسافت برای پروکسی شل

مایکروسافت با انتشار وصله‌هایی در ماه آوریل هر سه آسیب‌پذیری پروکسی شل را برطرف کرد. با اینکه وصله‌های امنیتی را اطلاع رسانی کرد ولی سه ماه بعد شناسه‌ها را برای این افزونه‌ها در سایت خود معرفی کرد.

در مورد وصله منتشر شده برای شناسه CVE-2021-31207، مایکروسافت امکان نوشتن فایل دلخواه را رفع نکرد اما از یک لیست فایلهای مجاز برای محدود کردن فایل‌هایی با پسوند .pst, .eml, .ost. استفاده کرد.

اکسچنج به منظور جلوگیری از دور زدن احراز هویت،حالا مقدار IsAuthenticated را هم بررسی می‌کند تا مطمئن شود تمامی درخواست‌های frontend  قبل از اینکه تیکت‌های  Kerberos برای دسترسی به backend دریافت کنند، احراز هویت شوند.

نتیجه‌گیری

اگرچه پچ‌های امنیتی منتشر شده در ماه آوریل بخش سواستفاده از آسیب‌پذیری احراز هویت را کاهش داد، اما CAS همچنان مستعد مشکلات امنیتی بسیاری است.

تنها کاری که کاربران اکسچنج باید بطور مداوم انجام دهند، این است که مایکروسافت اکسچنج خود را به‌روزرسانی کرده و از قرار گرفتن آن در معرض اینترنت جلوگیری کنند.

منبع