برچسب: CVE-2021-27065

ProxyLogon 僅僅只是冰山一角,一個針對 Microsoft Exchange Server 的全新攻擊面!

ProxyLogon فقط نوک کوه یخ است ، یک سطح حمله جدید علیه سرور Microsoft Exchange!

به عنوان رایج ترین راه حل پست الکترونیکی در جهان امروز ، Microsoft Exchange Server تقریباً به بخش ضروری کار و امنیت روزانه شرکتها و دولتها تبدیل شده است! در ژانویه سال جاری ، ما یک سری آسیب پذیری های Exchange Server را به مایکروسافت گزارش دادیم و نام این آسیب پذیری را ProxyLogon گذاشتیم. من معتقدم که اگر اخبار صنعت را دنبال می کنید ، حتماً این نام را نیز شنیده اید! شاید ProxyLogon جدی ترین و تأثیرگذارترین آسیب پذیری در تاریخ Exchange باشد!

با تحقیقات عمیق تر در مورد ProxyLogon از سطح معماری ، متوجه شدیم که این فقط یک آسیب پذیری نیست ، بلکه یک سطح حمله کاملاً جدید است که هیچکس به آن اشاره نکرده است که به هکرها یا محققان امنیتی اجازه می دهد تا حفره های بیشتری را حفر کنند. بنابراین ، ما روی مطالعه این سطح حمله متمرکز شدیم و حداقل هشت آسیب پذیری را پیدا کردیم. این آسیب پذیری ها آسیب پذیری های سمت سرور ، سمت کلاینت و حتی رمزنگاری را پوشش می دهند. ما این آسیب پذیری ها را در سه زنجیره حمله ترکیب کردیم:

  1. ProxyLogon: بهترین شناخته شده ترین و تاثیرگذارترین زنجیره حمله Exchange
  2. ProxyOracle: یک زنجیره حمله که می تواند رمز عبور ساده هر کاربر Exchange را بازیابی کند
  3. ProxyShell: ما زنجیره حمله ای را که Exchange را در Pwn2Own 2021 نابود می کند ، نشان می دهیم

همه آسیب پذیری هایی که ما پیدا کردیم ، آسیب پذیری های منطقی هستند ، به این معنی که در مقایسه با آسیب پذیری های خرابی حافظه ، این آسیب پذیری ها به راحتی تکثیر و بهره برداری می شوند. ما همچنین نتایج را در Black Hat USA And DEFCON منتشر کردیم ، همچنین برنده شد جایزه Pwnie 2021 بهترین باگ سرور سال. در صورت علاقه ، می توانید اسلایدشو این کنفرانس را از اینجا بارگیری کنید! 19659008] آسیب پذیری های ذکر شده این بار از طریق روش افشای آسیب پذیری مسئول به مایکروسافت گزارش شده و برطرف شده است. شما می توانید شماره آسیب پذیری دقیق و برنامه گزارش دهی را در تصویر زیر مشاهده کنید.

زمان گزارش نام CVE زمان پچ CAS [1] گزارش شده توسط
05 ژانویه 2021 ProxyLogon CVE-2021-26855 مارس 02 ، 2021 بله Orange Tsai ، Volexity and MSTIC
05 ژانویه 2021 ProxyLogon CVE-2021-27065 مارس 02 ، 2021 نارنجی Tsai ، Volexity و MSTIC
17 ژانویه 2021 ProxyOracle CVE-2021-31196 13 ژوئیه 2021 بله نارنجی Tsai [19659021] 17 ژانویه 2021 ProxyOracle CVE-2021-31195 11 مه 2021 نارنجی تسای
02 آوریل 2021 ProxyShell [2] ] CVE-2021-34473 13 آوریل 2021 بله Orange Tsai در حال کار با ZDI
02 آوریل 2021 ProxyShell [2] ] CVE-2021-34523 13 آوریل 2021 بله Orange Tsai در حال کار با ZDI [19659021] 02 آوریل 2021 ProxyShell [2] CVE-2021-31207 11 مه 2021 Orange Tsai در حال کار با ZDI
ژوئن 02 ، 2021 بله نارنجی تسای
02 ژوئن 2021 CVE-2021-33768 13 ژوئیه 2021 Orange Tsai و Dlive


[1] اشکالات مربوط به این وضعیت ناگهانی سطح حمله جدید
[2] Pwn2Own 2021 اشکالات

ما جزئیات فنی بیشتری را اعلام کرده ایم و پیوندهای پیگیری همچنان در این مقاله به روز می شوند ، بنابراین با ما همراه باشید:

.

A New Attack Surface on MS Exchange Part 1 - ProxyLogon!

سطح حمله جدید در MS Exchange قسمت 1 – ProxyLogon!

سری A New Attack Surface در MS Exchange:

Microsoft Exchange ، به عنوان یکی از رایج ترین راه حل های ایمیل در جهان ، به بخشی از عملیات و امنیت روزانه برای دولت ها و شرکت ها تبدیل شده است. در ماه ژانویه ، ما مجموعه ای از آسیب پذیری های Exchange Server را به مایکروسافت گزارش کردیم و آن را ProxyLogon نامگذاری کردیم. ProxyLogon ممکن است شدیدترین و تأثیرگذارترین آسیب پذیری در تاریخ Exchange باشد. اگر به اخبار صنعت توجه داشتید ، حتماً آن را شنیده اید. قبلاً ذکر شد این سطح حمله می تواند هکرها یا محققان امنیتی را به آسیب پذیری های بیشتری سوق دهد. بنابراین ، ما تصمیم گرفتیم روی این سطح حمله تمرکز کنیم و در نهایت حداقل 8 آسیب پذیری را پیدا کردیم. این آسیب پذیری ها از سمت سرور ، سمت کلاینت و حتی اشکالات رمزنگاری پوشش می دهند. ما این آسیب پذیری ها را به 3 حمله تقسیم کردیم:

  1. ProxyLogon: معروف ترین و تاثیرگذارترین زنجیره سوء استفاده از Exchange
  2. ProxyOracle: حمله ای که می تواند هرگونه رمز عبور را در قالب متن ساده کاربران Exchange بازیابی کند
  3. PrxoyShell: زنجیره سوء استفاده ما در Pwn2Own 2021 برای تصاحب Exchange و کسب 200،000 دلار پاداش

نشان داده شد من می خواهم برجسته کنم که همه آسیب پذیری هایی که ما در اینجا معرفی کردیم اشکالات منطقی هستند ، به این معنی که می توان آنها را راحت تر از هرگونه خرابی حافظه بازتولید و مورد سوء استفاده قرار داد. اشکالات ما تحقیقات خود را در Black Hat USA و DEFCON ارائه کرده ایم و برنده بهترین اشکال Pwnie Awards 2021 در سمت سرور شده ایم. شما می توانید مطالب ارائه شده ما را در اینجا بررسی کنید: Microsoft Exchange Server! [Slides] [Video]

با درک اصول اولیه این سطح حمله جدید ، شگفت زده نخواهید شد که چرا ما می توانیم 0 روز به راحتی ظاهر شویم!

من می خواهم بیان کنم که تمام آسیب پذیری های ذکر شده از طریق فرآیند افشای آسیب پذیری مسئول گزارش شده اند و وصله شده توسط مایکروسافت می توانید جزئیات بیشتری از CVE ها و جدول زمانی گزارش را در جدول زیر بیابید.

زمان گزارش نام CVE زمان پچ CAS [1] [19659012] گزارش شده توسط
05 ژانویه 2021 ProxyLogon CVE-2021-26855 مارس 02 ، 2021 بله نارنجی تسای ، Volexity و MSTIC
05 ژانویه 2021 [19659018] ProxyLogon CVE-2021-27065 02 مارس 2021 Orange Tsai ، Volexity and MSTIC
17 ژانویه 2021 ProxyOracle CVE-2021-3119 13 ژوئیه 2021 بله نارنجی تسای
17 ژانویه 2021 ProxyOracle CVE-2021-31195 11 مه 2021 نارنجی Tsai
02 آوریل 2021 ProxyShell [2] CVE-2021-34473 13 آوریل 2021 بله نارنجی Tsai در حال کار با ZDI [19659023] 02 آوریل 2021 ProxyShell [2] CVE -2021-34523 13 آوریل 2021 بله Orange Tsai در حال کار با ZDI
02 آوریل 2021 ProxyShell [2] CVE-2021- 31207 11 مه 2021 نارنجی تسای با ZDI
02 ژوئن 2021 بله نارنجی تسای [19659023] 02 ژوئن 2021 CVE-2021-33768 13 ژوئیه 2021 نارنجی تسای و دلیو


[1] اشکالات مربوط به این وضعیت ناگهانی سطح حمله جدید
[2] Pwn2Own اشکالات 2021

چرا Exchange Server تبدیل به یک موضوع داغ شد؟ از نظر من ، کل سطح حمله ProxyLogon در واقع در مراحل اولیه پردازش درخواست Exchange قرار دارد. به عنوان مثال ، اگر ورودی Exchange 0 باشد ، و 100 منطق اصلی کسب و کار است ، ProxyLogon جایی در حدود 10 است. باز هم ، از آنجا که این آسیب پذیری در ابتدا قرار دارد ، من معتقدم هرکسی که امنیت Exchange را با دقت بررسی کرده باشد ، متوجه خواهد شد سطح حمله این دلیل نیز بود که من پس از گزارش به مایکروسافت نگرانی خود را در مورد برخورد اشکال توییت کردم. این آسیب پذیری بسیار تأثیرگذار بود ، اما ساده است و در چنین مراحل اولیه ای قرار دارد.

همه می دانید که بعد چه اتفاقی افتاد ، Volexity دریافت که یک گروه APT از SSRF یکسان (CVE-2021-26855) برای دسترسی به کاربران استفاده می کند 'ایمیل در اوایل ژانویه 2021 و گزارش به مایکروسافت. مایکروسافت همچنین وصله های فوری را در ماه مارس منتشر کرد. از اطلاعات عمومی منتشر شده پس از آن ، متوجه شدیم که حتی اگر از SSRF یکسانی استفاده می کردند ، گروه APT از آن بسیار متفاوت از ما سوء استفاده می کرد. ما زنجیره حمله ProxyLogon را از طریق CVE-2021-27065 تکمیل کردیم ، در حالی که گروه APT از EWS و دو آسیب پذیری ناشناخته در حمله خود استفاده کردند. این ما را متقاعد کرده است که یک آسیب در آسیب پذیری SSRF وجود دارد. MSRC در اواخر فوریه در طبیعت ظاهر شد ، ما نیز پس از حذف احتمال نشت از طریق تحقیقات کامل ، مانند همه کنجکاو بودیم. با ظاهر شدن زمان بندی واضح تر و بحث بیشتر ، به نظر می رسد این اولین بار نیست که چنین چیزی برای مایکروسافت اتفاق می افتد. شاید شما علاقه مند باشید که داستانهای جالبی را از اینجا بیاموزید. به عبارت دیگر ، کنترل سرور ایمیل به معنای کنترل خط نجات یک شرکت است. Exchange Server به عنوان رایج ترین راه حل ایمیل ، مدتهاست که هدف اصلی هکرها بوده است. بر اساس تحقیقات ما ، بیش از چهارصد هزار سرور تبادل در اینترنت وجود دارد. هر سرور نماینده یک شرکت است ، و شما می توانید تصور کنید که چقدر وحشتناک است در حالی که یک آسیب پذیری شدید در Exchange Server ظاهر شد.

به طور معمول ، من قبل از شروع تحقیق ، مقالات و اشکالات موجود را مرور می کنم. در بین کل سابقه Exchange ، مورد جالبی وجود دارد؟ البته. اگرچه بیشتر آسیب پذیری ها بر اساس بردارهای حمله شناخته شده ، مانند ضد آب زدایی یا تأیید ورودی نامناسب ، هنوز چندین اشکال وجود دارد که ذکر آنها ضروری است.

خاص ترین

خاص ترین آنها زرادخانه گروه معادله در 2017 است این تنها RCE عملی و عمومی پیش نویس در تاریخ Exchange است. متأسفانه ، زرادخانه فقط بر روی یک Exchange Server 2003 قدیمی کار می کند. اگر نشت زرادخانه زودتر اتفاق بیفتد ، ممکن است با یک بحران دیگر در سطح هسته ای خاتمه یابد.

جالب ترین

جالب ترین آن CVE-2018-8581 است افشا شده توسط شخصی که با ZDI همکاری کرده است. اگرچه این فقط یک SSRF بود ، اما با این ویژگی می توان آن را با NTLM Relay ترکیب کرد ، اما مهاجم می تواند یک SSRF خسته کننده را به چیزی واقعاً فانتزی تبدیل کند. به عنوان مثال ، می تواند به طور مستقیم کل Domain Controller را از طریق یک حساب کم امتیاز کنترل کند. علت اصلی این اشکال به دلیل یک کلید رمزنگاری سخت در Microsoft Exchange است. با استفاده از این کلید سخت کد ، مهاجمی با امتیاز کم می تواند کل سرور Exchange را تحت کنترل خود درآورد. و همانطور که می بینید ، حتی در سال 2020 ، یک کلید رمزنگاری احمقانه و سخت رمزنگاری شده هنوز در یک نرم افزار ضروری مانند Exchange یافت می شود. این نشان می دهد که Exchange فاقد بررسی های امنیتی است ، همین امر باعث شد من بیشتر در مورد امنیت Exchange تحقیق کنم.

Exchange یک برنامه بسیار پیچیده است. از سال 2000 ، Exchange هر 3 سال یک نسخه جدید منتشر می کند. هر زمان که Exchange نسخه جدیدی را منتشر می کند ، معماری آن بسیار تغییر کرده و متفاوت می شود. تغییرات معماری و تکرارها ، ارتقای سرور Exchange را مشکل می کند. به منظور اطمینان از سازگاری بین معماری جدید و معماری قدیمی ، چندین بدهی طراحی به Exchange Server وارد شد و منجر به سطح جدیدی از حمله شد که ما پیدا کردیم. ما بر سرویس دسترسی مشتری ، CAS تمرکز کردیم. CAS جزء اساسی Exchange است. بازگشت به نسخه 2000/2003 ، CAS یک سرور مستقل Frontend بود که مسئول تمام منطق های ارائه وب Frontend بود. پس از چندین تغییر نام ، ادغام و تفاوت نسخه ، CAS به یک سرویس تحت نقش صندوق پستی تنزل یافته است. مستندات رسمی مایکروسافت نشان می دهد که:

سرورهای صندوق پستی شامل خدمات دسترسی به مشتری است که اتصالات سرویس گیرنده را برای همه پروتکل ها می پذیرد . این سرویس های جلو مسئول مسیریابی یا پراکسی اتصالات به خدمات پشتیبان مربوطه در سرور صندوق پستی

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

CAS م componentلفه اصلی مسئول پذیرش همه اتصالات از طرف کلاینت است ، فرقی نمی کند که HTTP ، POP3 ، IMAP یا SMTP باشد و اتصالات را پروکسی می کند. به سرویس Backend مربوطه به عنوان یک محقق امنیت وب ، روی پیاده سازی CAS در وب تمرکز کردم.

وب CAS بر اساس IIS مایکروسافت ساخته شده است. همانطور که می بینید ، دو وب سایت در داخل IIS وجود دارد. "وب سایت پیش فرض" Frontend است که قبلاً ذکر کردیم ، و "Exchange Backend" جایی است که منطق تجارت در آن قرار دارد. پس از بررسی دقیق پیکربندی ، متوجه می شویم که Frontend با پورت های 80 و 443 متصل است و Backend به پورت های 81 و 444 گوش می دهد. همه پورت ها با 0.0.0.0 ، به معنی هر کسی می تواند مستقیماً به Frontend و Backend of Exchange دسترسی داشته باشد. آیا خطرناک نیست؟ لطفاً این سال را در نظر داشته باشید و ما بعداً به آن پاسخ خواهیم داد.

Exchange منطق Frontend و Backend را از طریق ماژول IIS پیاده سازی می کند. چندین ماژول در Frontend و Backend برای انجام کارهای مختلف مانند فیلتر ، تأیید اعتبار و ورود به سیستم وجود دارد. Frontend باید دارای یک ماژول پروکسی باشد. ماژول پروکسی درخواست HTTP را از طرف سرویس گیرنده دریافت می کند و برخی تنظیمات داخلی را اضافه می کند ، سپس درخواست را به Backend ارسال می کند. در مورد Backend ، همه برنامه ها شامل Rehydration Module است که وظیفه تجزیه درخواست های Frontend ، پر کردن اطلاعات مشتری و ادامه پردازش منطق کسب و کار را بر عهده دارد. بعداً نحوه عملکرد ماژول پروکسی و ماژول آب رسانی را توضیح خواهیم داد.

Frontend Proxy Module

Proxy Module یک کنترل کننده را بر اساس ApplicationPath کنونی برای پردازش درخواست HTTP از طرف سرویس گیرنده انتخاب می کند. به عنوان مثال ، برای بازدید از /EWS از EwsProxyRequestHandler استفاده می شود ، در مورد /OWA باعث OwaProxyRequestHandler می شود. همه کنترل کننده ها در Exchange این کلاس را از ProxyRequestHandler به ارث برده و منطق اصلی آن را پیاده سازی می کنند ، مانند نحوه برخورد با درخواست HTTP از کاربر ، آدرس URL از Backend به proxy و نحوه همگام سازی اطلاعات با پس زمینه این کلاس همچنین مرکزیترین قسمت کل ماژول پروکسی است ، ما ProxyRequestHandler را به 3 بخش تقسیم می کنیم:

Frontend Reqeust Section

بخش Request درخواست HTTP از سرویس گیرنده را تجزیه و تعیین می کند که کدام کوکی و سرصفحه می تواند در Backend پروکسی شود. Frontend و Backend برای هماهنگ سازی اطلاعات و وضعیت داخلی پروکسی به HTTP Headers تکیه کردند. بنابراین ، Exchange یک لیست سیاه برای جلوگیری از سوء استفاده از برخی سرصفحه های داخلی تعریف کرده است. headerName ) {
return ! string . برابر ( headerName ]، CommonAccessToken " ، OrdinalIgnoreCase )
&& ! رشته . برابر ([196591] 1965 X-IsFromCafe " ، OrdinalIgnoreCase )
&& ! string . برابر [1965911] [1965911] ] "X-SourceCafeServer" ، OrdinalIgnoreCase )
&& ! رشته . برابر "msExchProxyUri" [19659101] ، OrdinalIgnoreCase )
&& ! رشته . برابر ( headerName 19659101] " ، OrdinalIgnoreCase )
&& ! رشته . برابر ( سربرگ 1965] 19659 -client-request-id " ، OrdinalIgnoreCase )
&& ! string . برابر [1965911] ، "X-Forwarded-For" ، OrdinalIgnoreCase )
&& (! headerName . 1965996 ] "X-Backend-Diag-" ، OrdinalIgnoreCase )
|| این . ClientRequest . . 19659110] ). IsProbeRequest ()) ؛
}

در آخرین مرحله درخواست ، ماژول پروکسی با t تماس می گیرد روش AddProtocolSpecificHeadersToServerRequest توسط کنترل کننده برای افزودن اطلاعاتی که باید با Backend در سرصفحه HTTP ارتباط برقرار شود ، اجرا می شود. این بخش همچنین اطلاعات کاربر ورود به سیستم را سریال می کند و در یک عنوان HTTP جدید X-CommonAccessToken قرار می دهد که بعداً به Backend ارسال می شود.

به عنوان مثال ، اگر به Outlook وارد شوم Web Access (OWA) با نام نارنجی ، X-CommonAccessToken که پروکسی Frontend به Backend خواهد بود:

بخش پروکسی Frontend

بخش پروکسی ابتدا از روش GetTargetBackendServerURL برای محاسبه نشانی وب پشتیبان باید درخواست HTTP به آن ارسال شود. سپس یک درخواست HTTP Client جدید با روش CreateServerRequest .

HttpProxy ProxyRequestHandler.cs

 محافظت شده   HttpWebRequest  1965911] 1965911] 1965911] 19659103] targetUrl )   {
     HttpWebRequest   httpWebRequest   =   ( HttpWebRequest  1965911] 19659101] 19659101] 19659101  19659101] 19659101] 19659101] 19659101] 1965911] 19659101] 1965911] 1965911] 1965911] 1965911] 1965911] 1965911] 1965911] 1965911] 1965911] 1965911] 1965911 وارد  196591] وارد] 19659101 وارد  وارد آورد  ( targetUrl ) ؛ 
     اگر   (!  HttpProxySettings .  UseDefaultWebProxy . [19659511965] 1965 httpWebRequest .  پروکسی   =   NullWebProxy .  Instance ؛ 
    } 
     httpWebRequest . 19659112] ConnectionLimit   =   HttpProxySettings .  ServicePointConnectionLimit .  ارزش  ؛ 
     httpWebR 01].  روش   =   این .  ClientRequest .  HttpMethod ؛ 
     httpWebRequest  19651101 [ "X-FE-ClientIP" ]   =   ClientEndpointResolver .  GetClientIP  ( SharedHttpp1010 [196591110] 1965 ( این .  HttpContext ))؛ 
     httpWebRequest .  سرصفحه  [ "X-Forwarded-For" 19659105] =   ClientEndpointResolver .  GetClientProxyChainIPs  ( SharedHttpContextWrapper .  19659155955955955955915] 1961 )) ؛ 
     httpWebRequest .  سرصفحه ها  [ "بندر X-Forwarded" ]   =   ClientEndpointResolver  19659101] ( SharedHttpContextWrapper [1 9659101].  GetWrapper  ( این .  HttpContext ))؛ 
     httpWebRequest .  1965 [196591] 1965 -MS-EdgeIP "]   =   برنامه های کاربردی .  GetEdgeServerIpAsProxyHeader  ( SharedHttpContextWrapper [1965911] 1965991 [1965911] 1965911 [19659101[1965911] 1965991 [1965911] 1965991 [1965911] 1965911 [19659101[1965911] 1965991  19659101].  HttpContext ).  درخواست ) ؛ 
    
     // ... 
    
     بازگشت   httpWebRequest  ؛ ] همچنین یک بلیط Kerberos از طریق سرویس HTTP-Class of the Backend تهیه کرده و آن را در سرصفحه  مجوز  قرار دهید. این سربرگ برای جلوگیری از دسترسی مستقیم کاربران ناشناس به Backend طراحی شده است. با استفاده از Kerberos Ticket ، Backend می تواند دسترسی Frontend را تأیید کند. 

HttpProxy ProxyRequestHandler.cs

 if   ( this .   {
     serverRequest .  ConnectionGroupName   =   this .  ClientRequest .  User [Host] 1965955  +  GccUtils .  GetClientPort  ( SharedHttpContextWrapper .  GetWrapper  19659101  19659101 ]))؛ 
}   دیگری   اگر   ( این .  AuthBehavior .  AuthState   =]   =] 19659101].  BackEndFullAuth   ||   این . 
     ShouldBackendRequestBeAnonymous  ()   ||   [196591p5] ortEnabled .  ارزش   
     &&  !  رشته .  IsNullOrEmpty  ( این     19659112] عناوین  [ "TestBackEndUrl") ]))   {
     serverRequest   ConnectionGroupName   =   "غیرمجاز" . 
}   دیگری   {
     serverRequest .  سرصفحه ها  [ "مجوز" ]   =   =   Kerberos  GenerateKerberosAuthHeader  (
         serverRequest .  آدرس .  میزبان  ،   این    ] ref   this .  authenticationContext ،   ref   this .  kerberosChallenge 
] [196p9402]  KerberosUtilities.cs 

 داخلی   ثابت [19659099] string   GenerateKerberosAuthHeader  ( string   host ،   int   traceContext ،   ref   aut   ،   ref   رشته   kerberosChallenge )   {
     بایت  []   آرایه   =   نول [1965] 1965 بایت  []   بایت   =   null  ؛ 
     // ... 
     احراز هویتمحتوی   =   جدید [196591100] احراز هویت () ؛ 
     رشته   متن   =   "HTTP/"  +  میزبان  ؛ 
     احراز هویت زمینه .  InitializeFor10  AuthenticationMechanism .  Kerberos  ،   متن  ،   null  ،   null  19659 19659105] = [19659103] authenticationContext .  NegotiateSecurityContext  ( inputBuffer ،   out   بایت 
     // ... [1965994] رشته   =   رمزگذاری .  ASCII .  GetString  ( بایت ) ؛ 
     بازگشت [19659114»19659105]+ string  ؛ 
} 

بنابراین ، یک درخواست مشتری که به Backend پروکسی شده است ، با چندین عنوان HTTP برای استفاده داخلی اضافه می شود. دو سرصفحه اصلی عبارتند از X-CommonAccessToken ، که نشان دهنده ورود کاربران به ایمیل است ، و Kerberos Ticket ، که نشان دهنده دسترسی قانونی Frontend است.

بخش Frontend Response

آخرین بخش Response است. این پاسخ را از Backend دریافت می کند و تصمیم می گیرد که کدام سرصفحه ها یا کوکی ها مجاز به ارسال مجدد به Frontend هستند. Backend ابتدا از روش IsAuthenticated برای بررسی اینکه درخواست ورودی تأیید شده است یا نه استفاده می کند. سپس Backend تأیید می کند که آیا درخواست مجهز به یک حق توسعه یافته به نام ms-Exch-EPI-Token-Serialization است. با تنظیم پیش فرض ، فقط Exchange Machine Account دارای چنین مجوزی است. به همین دلیل است که بلیط Kerberos ایجاد شده توسط Frontend می تواند از نقطه بازرسی عبور کند اما شما نمی توانید مستقیماً با حساب مجاز کم به Backend دسترسی پیدا کنید.

پس از گذراندن چک ، Exchange هویت ورود به سیستم مورد استفاده در Frontend را از طریق ضدعفونی کردن سربرگ X-CommonAccessToken به رمز اصلی دسترسی ، و سپس آن را در شی httpContext قرار دهید تا به منطق تجارت در Backend پیشرفت کنید.

احراز هویت BackendRehydrationModule.cs

 خصوصی   void   OnAuthenticateRequest  ( object   منبع  ،   EventArgs [196591055] if   ( httpContext .  درخواست .  IsAuthenticated )   {
         این     httpContext ) ؛ 
    } 
} 

 خصوصی   void   Pro cessRequest  ( HttpContext   httpContext )   {
     CommonAccessToken   توکن  ؛ 
     اگر [1965910] 1962 19659110] TryGetCommonAccessToken  ( httpContext  ،   خارج   توکن ))   {
         // ... 
     95} 1965920 ] خصوصی   bool   TryGetCommonAccessToken  ( HttpContext   httpContext ،   out   CommonAccessToken   1965910   1965993] 1965993   متن   =   httpContext .  درخواست .  سرصفحه ها  [ "X-CommonAccessToken"  ]؛ 19659105] ( رشته .  IsNullOrEmpty  ( متن ))   {
         بازگشت   غلط  1965951 1965 ] bool   پرچم  ؛ 
     سعی کنید   {
         پرچم   = [19659098] این .  IsTokenSerializationAllowed  ( httpContext .  User .  Identity   as   }   سرانجام   {
         httpContext .  موارد  [ "BEValidateCATRightsLatency" ]   = 1965910] 19651 ElapsedMilliseconds  -  سپری شده میلی ثانیه  ؛ 
    } 

     توکن   =   CommonAccessToken .  1965] 1965] 1965] 1965 
     httpContext .  موارد  [ "Item-CommonAccessToken" ]   =   توکن  ؛ 
    
     // ... 
    
     // [... []  AllowsTokenSerializationBy [19659101] ( clientSecurityContext ) ؛ 
    بازگشت   flag2  ؛ 
} 

 خصوصی   استاتیک   bool [196591[196591] 1965 ] ClientSecurityContext   clientContext )   {
     بازگشت   LocalServer .  HasExtendedRightOnServer  [196591] 1965] 19651  TokenSerializationRightGuid ) ؛    // ms-Exch-EPI-Token-Serialization 

} 

پس از آشنایی مختصر با معماری CAS ، اکنون متوجه می شویم که CAS فقط یک خوب است پروکسی HTTP (یا مشتری) نوشته شده است ، و ما می دانیم که پیاده سازی پروکسی آسان نیست. بنابراین من می پرسیدم:

آیا می توانم از یک درخواست HTTP برای دسترسی به زمینه های مختلف به ترتیب در Frontend و Backend به منظور ایجاد سردرگمی استفاده کنم؟ سوء استفاده از برخی از API های داخلی یا ، ما می توانیم زمینه را اشتباه بگیریم تا از ناهماهنگی تعریف هدرهای HTTP خطرناک بین Frontend و Backend برای انجام حملات جالب دیگر استفاده کنیم.

با این افکار در ذهن ، بیایید شکار را شروع کنیم!

پروکسی لوگون همانطور که قبلاً معرفی شد ، این ممکن است شدیدترین آسیب پذیری تاریخ Exchange باشد. ProxyLogon دارای 2 اشکال است:

CVE-2021-26855-SSRF پیش نویس

بیش از 20 کنترل کننده مربوط به مسیرهای مختلف برنامه در Frontend وجود دارد. در حین بررسی پیاده سازی ها ، ما روش GetTargetBackEndServerUrl را که مسئول محاسبه URL Backend در کنترل کننده منابع استاتیک است ، پیدا کردیم ، هدف Backend را مستقیماً توسط کوکی ها تعیین می کند.

حالا می فهمید که این آسیب پذیری چقدر ساده است پس از یادگیری معماری است! LogElapsedTime ( "E_TargetBEUrl"
Uri نتیجه ؛
try 1965955 = این . AnchoredRoutingTarget . AnchorMailbox به عنوان UrlAnchorMailbox ؛ 1965555955 null ) {
نتیجه = urlAnchorMailb ox . Url ؛
} else {
UriBuilder clientUrlForProxy = [19659098]1 [19659098]1 [19659098]1 [19659098]1 19659101] () ؛
clientUrlForProxy . طرح = Uri . UriSchemeHttps 1965911 19659105] = این . AnchoredRoutingTarget . BackEndServer . Fqdn ؛ [196591] 196599] = 444 ؛
اگر ( این . AnchoredRoutingTarget . BackEndServer 19659101 19659103] سرور . E15MinVersion ) {
این . ProxyToDownLevel = [196590985] 196 < RequestDetailsLogger >. [19659110] SafeAppendGenericInfo ( این . Logger ، "ProxyToDownLevel" ، درست [1965911] 196591 بندر = 443 ؛
}
نتیجه = clientUrlForProxy . Uri [1965910]}
در نهایت {
این . LogElapsedTime ( "L_TargetBEUrl" ) ؛
} [196592] 19659101] ؛
}

از قطعه کد ، می توانید ویژگی BackEndServer.Fqdn AnchoredRoutingTarget را مستقیماً از کوکی اختصاص دهید.

HttpProxy OwaResourceProxyRequestHandler.cs

 محافظت شده   نادیده گرفتن   AnchorMailbox   ResolveAnchorMailbox  ()    کلی ntRequest .  کوکی ها  [ "X-AnonResource-Backend" 
     if   ( httpCookie   =] 19659101])   {
         این .  saveBackendServer   =   httpCookie .  ارزش ؛ 1965959] 1965959 رشته! لاگر .  مجموعه  ( 3  ،   "X-AnonResource-Backend-Cookie" 
         if   (  .  VerboseTracer .  IsTraceEnabled  ( 1 ))   {
             ExTraceGlobals . 19659101] 19659101] 19659112] TraceDebug  < HttpCookie  ،   int > (([ طولانی )  این . [19659110] GetHashCode  () ،   "[OwaResourceProxyRequestHandler::ResolveAnchorMailbox]: کوکی AnonResourceBackend مورد استفاده: {0}؛ زمینه {1} ". ServerInfoAnchorMailbox(BackEndServer.FromString(this.savedBackendServer), this);
     }
    return new AnonymousAnchorMailbox(this);
}

Though we can only control the Host part of the URL , but hang on, isn't manipulating a URL Parser exactly what I am good at? Exchange builds the Backend URL by built-in UriBuilder. However, since C# didn't verify the Hostso we can enclose the whole URL with some special characters to access arbitrary servers and ports.

https://[foo]@example.com:443/path#]:444/owa/auth/x. js

So far we have a super SSRF that ca n control almost all the HTTP requests and get all the replies. The most impressive thing is that the Frontend of Exchange will generate a Kerberos Ticket for us, which means even when we are attacking a protected and domain-joined HTTP service, we can still hack with the authentication of Exchange Machine Account.

So, what is the root cause of this arbitrary Backend assignment? As mentioned, the Exchange Server changes its architecture while releasing new versions. It might have different functions in different versions even with the same component under the same name. Microsoft has put great effort into ensuring the architectural capability between new and old versions. This cookie is a quick solution and the design debt of Exchange making the Frontend in the new architecture could identify where the old Backend is.

CVE-2021-27065 - Post-auth Arbitrary-File-Write

Thanks to the super SSRF allowing us to access the Backend without restriction. The next is to find a RCE bug to chain together. Here we leverage a Backend internal API /proxyLogon.ecp to become the admin. The API is also the reason why we called it ProxyLogon.

Because we leverage the Frontend handler of static resources to access the ECExchange Control Panel (ECP) Backend, the header msExchLogonMailboxwhich is a special HTTP header in the ECP Backend, will not be blocked by the Frontend. By leveraging this minor inconsistency, we can specify ourselves as the SYSTEM user and generate a valid ECP session with the internal API.

With the inconsistency between the Frontend and Backend, we can access all the functions on ECP by Header forgery and internal Backend API abuse. Next, we have to find an RCE bug on the ECP interface to chain them together. The ECP wraps the Exchange PowerShell commands as an abstract interface by /ecp/DDI/DDIService.svc. The DDIService defines several PowerShell executing pipelines by XAML so that it can be accessed by Web. While verifying the DDI implementation, we found the tag of WriteFileActivity did not check the file path properly and led to an arbitrary-file-write.

DDIServiceWriteFileActivity.cs

public override RunResult Run(DataRow input, DataTable dataTable, DataObjectStore store, Type codeBehind, Workflow.UpdateTableDelegate updateTableDelegate) {
    DataRow dataRow = dataTable.Rows[0];
    string value = (string)input[this.InputVariable];
    string path = (string)input[this.[19659112]OutputFileNameVariable];
    RunResult runResult = new RunResult();
    try {
        runResult.ErrorOccur = true;
        using (StreamWriter streamWriter = new StreamWriter(File.Open(path, FileMode.CreateNew)))
        {
            streamWriter.WriteLine(value);
        }
        runResult.ErrorOccur = false;
    }
    
    // ...
}

There are several paths to trigger the vulnerability of arbitrary-file-write. Here we use ResetOABVirtualDirectory.xaml as an example and write the result of Set-OABVirtualDirectory to the webroot to be our Webshell.

Now we have a working pre-auth RCE exploit chain. An unauthenticated attacker can execute arbitrary commands on Microsoft Exchange Server through an exposed 443 port. Here is an demonstration video:

As the first blog of this series, ProxyLogon perfectly shows how severe this attack surface could be. We will have more examples to come. Stay tuned!

.