در هفته ای که گذشت، مایکروسافت برای چهار آسیب پذیری روز صفرم سرورهای Exchange خود که در ژانویه 2021 توسط محققان امنیتی شناسایی شدند، وصله های امنیتی ارائه کرد که به گفته مایکروسافت در اسرع وقت می بایست بر روی سرورهای آسیب پذیر Exchange اعمال شوند.
در حملات صورت گرفته بر روی سرورهای Exchange، مهاجمان با موفقیت inbox ایمیل قربانیان خود را استخراج می کنند و سپس shell هایی را بر روی سرورهای آسیب پذیر قرار می دهند تا نفوذ خود را در حد استخراج حساب های کاربری شبکه قربانی، اضافه کردن حساب کاربری به شبکه قربانی و یا حتی به دست آوردن پایگاه داده ActiveDirectory (فایل NTDS.dit) گسترش دهند.
این سری از حملات، همان طور که در تصویر زیر مشاهده می شود، اروپا، آسیا ، خاورمیانه و به صورت گسترده آمریکا را مورد هدف قرار داده است:
چهار آسیب پذیری روز صفرمی که مایکروسافت به آنها اشاره کرده، با شناسه های آسیب پذیری زیر نام گذاری شده‌اند که در ادامه نقش هر یک به همراه جزئیات شرح داده می شود:
CVE-2021-26855: آسیب پذیری از نوع SSRF است و از درجه حسیاست 9.1 برخوردار است. از این آسیب پذیری برای به دست آوردن محتوای inbox قربانی استفاده می شود.
CVE-2021-26857: آسیب پذیری از نوع RCE و با درجه حساسیت 7.8 است که امکان اجرای دستورات را با دسترسی SYSTEM برای مهاجم فراهم می کند (در فاز post-exploit).
CVE-2021-26858 و CVE-2021-27065: هر دو آسیب پذیری های از نوع RCE هستند (درجه حساسیت 7.8) که به عنوان post-exploit در سری حملات صورت گرفته بر روی سرورهای آسیب پذیر Exchange مورد استفاده قرار گرفتند.
در بررسی های صورت گرفته توسط مایکروسافت، نسخه های 2013، 2016 و 2019 سرورهای Exchange نسبت به حمله شناسایی شده، که آنها را با اطمینان به گروه APT تحت حمایت کشور چین با عنوان “HAFNIUM” نسبت می دهد، آسیب پذیر می داند. البته Exchange Online و Office 365 از این قاعده مستثنی هستند!
اطلاعات دقیق نسخه های آسیب پذیر:
- Exchange Server 2019 < 15.02.0792.010
- Exchange Server 2019 < 15.02.0721.013
- Exchange Server 2016 < 15.01.2106.013
- Exchange Server 2013 < 15.00.1497.012
جزئیات حمله صورت گرفته:
فاز اول: دور زدن احراز هویت سرور Exchange
محققان امنیتی شرکت Volexity با مشاهده رفتارهای مشکوکی از چندین سرور Exchange مشتریان خود، فاز بررسی امنیتی دقیق رخدادهای شناسایی شده را در ژانویه 2021 آغاز نمودند. نتایج به دست آمده از بررسی های انجام شده بر روی RAM سیستم های مورد حمله قرار گرفته، نشان داد که مهاجمان از یک آسیب پذیری روز صفرم (CVE-2021-26855) که اکنون با نام Proxylogon شناخته می شود، بهره برده‌اند و تمام inbox حساب های ایمیل قربانیان خود را استخراج کرده‌اند! این آسیب پذیری که از نوع SSRF است، می تواند از راه دور و بدون نیاز به احراز هویت مورد استفاده قرار بگیرد. تنها اطلاعاتی که مهاجم برای به دست آوردن محتوای inbox قربانیان خود نیاز دارد، آگاهی از بهره مندی از سرویس Exchange و آدرس ایمیل قربانی است.
برای استخراج محتوای inbox ایمیل قربانیان از طریق آسیب پذیری proxylogon، دو روش توسط محققان امنیتی Volexity شناسایی شده است که بسته به نحوه راه اندازی و تنظیم سرویس Exchange، توسط مهاجمان مورد استفاده قرار گرفته است.
- حالت اول: چنان چه برای راه اندازی سرویس Exchange، تنها از یک سرور در شبکه استفاده شده باشد، مهاجم می بایست مقدار SID حساب های دامنه قربانیان خود را در اختیار داشته باشد تا بتواند محتویات درون inbox ایمیل آنان را به دست آورد.
- حالت دوم: چنان چه سرویس Exchange با بهره گیری از چندین سرور راه اندازی شده باشد (که عمدتاً در شرکت های بزرگ با هدف load balancing یا تخصیص هدفمند منابع سخت افزاری به این صورت پیاده سازی می شود)، دیگر مهاجم نیازی به دانستن مقدار SID حساب قربانیان خود نخواهد داشت و تنها با دانستن آدرس ایمیل آنان، به هدف خود خواهد رسید.
آسیب پذیری SSRF موجود در سرورهای Exchange، این امکان را برای مهاجم فراهم می کند تا با ارسال یک درخواست آلوده HTTP POST (شامل کد مخرب XML SOAP) برای API وب سرویس Exchange (مختصراً EWS API) هر گونه دستور دلخواهی را بر روی inbox حساب های ایمیل قربانی به اجرا درآورد! درخواست SOAP ارسالی، با دستکاری مقدار cookie قادر است فرآیند احراز هویت را دور بزند و سپس دستور قرار گرفته در XML را اجرا نماید.
یک نمونه از نحوه اجرای آسیب پذیری SSRF مذکور در آزمایشگاه امنیتی شرکت Volexity بررسی شده است که در تصویر زیر نتیجه اجرای آن آورده شده است:
همان طور که ملاحظه شد، مهاجم محتویات پیام ارسالی/دریافتی قربانی را به دست آورده است.
ساختار درخواست SOAP مخربی که برای دور زدن احراز هویت سرور در اجرای این حمله مورد استفاده قرار گرفته است، مشابه دستورات تصویر زیر است که در آن کافی است مهاجم، آدرس ایمیل قربانی خود را در قسمت <Email Identifier> قرار دهد:
فاز دوم: اجرای کد از راه دور
در این مرحله، بعد از این که مهاجم توانست محتویات inbox قربانیان خود را به دست آورد، از سه آسیب پذیری روز صفرم دیگر (CVE-2021-27065 , CVE-2021-26858 , CVE-2021-26857) برای اجرای حمله RCE بر روی سرور آسیب پذیر بهره می برد. البته نکته مهمی که در این قسمت وجود دارد، این است که هر سه آسیب پذیری مذکور، برای اجرای موفق نیاز به احراز هویت دارند، اما در زنجیره حملات صورت گرفته، ابتدا مهاجم از آسیب پذیری SSRF فاز اول استفاده می کند تا احراز هویت را دور بزند و سپس از این سه استفاده می کند.
تقریباً در تمامی نمونه های شناسایی شده، مهاجم یک shell با پسوند aspx (یا php) بر روی سرور آسیب پذیر قرار داده تا دسترسی خود را برای مدت زمان بیشتری حفظ بکند. البته در سناریوهای مختلف شناسایی شده، shell های قرار گرفته بر روی سرور، اسامی متفاوتی مثل help.aspx، shell.aspx ، errorEE.aspx یا ... داشته اند. مایکروسافت در تاریخ 8 مارس یک لیست از IOC های شناسایی شده از این shell ها را در دو قالب CSV و JSON ارائه داده است که می توانید از آنها برای تشخیص هر چه بهتر بهره ببرید. نمونه ای از انواع shell های مشاهده شده در سراسر جهان در تصویر زیر آورده شده است:
فاز سوم: فعالیت های post-exploit
در مجموع فعالیت های post-exploit زیر برای سری حملات انجام شده توسط HAFNIUM شناسایی شده است، البته که بنا بر هدف مهاجم، post-exploit های صورت گرفته می تواند از تنوع بسیاری برخوردار باشد و این موارد تنها نمونه هایی هستند که به صورت گسترده مورد استفاده قرار گرفته اند:
1- استفاده از procdump برای استخراج محتویات LSASS درون حافظه
2- استفاده از 7zip برای فشرده کردن اطلاعات استخراج شده جهت ارسال برای مهاجم
3- استفاده از ابزارهای Nishang و PowerCat به منظور راه اندازی دسترسی reverse shell
4- ساخت حساب های کاربری بر روی Active Directory
5- استفاده از PsExec برای اجرای دستورات remote بر روی سایر سیستم های موجود در شبکه قربانی
چگونه می توان فهمید که آیا سرور Exchange ای آسیب پذیر است و یا مورد حمله قرار گرفته؟
1- می توان از script ارائه شده توسط مایکروسافت برای ابزار Nmap جهت شناسایی آسیب پذیری PostLogon بهره برد.
2- می توان از script موجود در اینجا برای شناسایی آسیب پذیری بهره برد.
3- می توان از scanner ارائه شده در اینجا بهره برد.
4- با توجه به این که هر یک از رفتارهای غیرمجاز صورت گرفته در این زنجیره حمله، از الگوی خاصی برخوردار هستند، شرکت مایکروسافت در آدرس زیر، تعدادی ابزار جهت سهولت کاربران برای شناسایی این که آیا سرورهایشان تحت تاثیر این حملات قرار گرفته است یا خیر ارائه داده است:
https://github.com/microsoft/CSS-Exchange/tree/main/Security
به عنوان نمونه، در صورتی که ابزار Test-ProxyLogon.ps1 رفتار مشکوکی را بر روی سیستم شناسایی کند، خروجی زیر نمایش داده خواهد شد:
5- می توان از لیست IOC ارائه شده توسط مایکروسافت بهره برد که در دو فرمت CSV و JSON وجود دارد.
فرمت CSV:
فرمت JSON:
6- استفاده از Hash مربوط به shell های قرار گرفته بر روی سرورهای آسیب پذیر:
- b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
- 097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e
- 2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1
- 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
- 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
- 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
- 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
- 1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944
- ....
7- بررسی مسیرهای زیر برای وجود shell :
- C:\inetpub\wwwroot\aspnet_client\ (any .aspx file under this folder or sub folders)
- C:\<exchange install path>\FrontEnd\HttpProxy\ecp\auth\ (any file besides TimeoutLogoff.aspx)
- C:\<exchange install path>\FrontEnd\HttpProxy\owa\auth\ (any file or modified file that is not part of a standard install)
- C:\<exchange install path>\FrontEnd\HttpProxy\owa\auth\Current\<any aspx file in this folder or subfolders>
- C:\<exchange install path>\FrontEnd\HttpProxy\owa\auth\<folder with version number>\<any aspx file in this folder or subfolders>
8- بررسی های صورت گرفته حاکی از آن است که درخواست های POST ارسال شده برای فایل های مسیرowa/auth/Current از User-Agent های زیر بهره برده اند، بنابراین بررسی User-Agent درخواست های ارسالی برای مسیر نام برده می تواند موثر باشد:
DuckDuckBot/1.0;+(+http://duckduckgo.com/duckduckbot.html)
facebookexternalhit/1.1+(+http://www.facebook.com/externalhit_uatext.php)
Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)
Mozilla/5.0+(compatible;+Bingbot/2.0;++http://www.bing.com/bingbot.htm)
Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html
Mozilla/5.0+(compatible;+Konqueror/3.5;+Linux)+KHTML/3.5.5+(like+Gecko)+(Exabot-Thumbnails)
Mozilla/5.0+(compatible;+Yahoo!+Slurp;+http://help.yahoo.com/help/us/ysearch/slurp)
Mozilla/5.0+(compatible;+YandexBot/3.0;++http://yandex.com/bots)
Mozilla/5.0+(X11;+Linux+x86_64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.103+Safari/537.36
هم چنین User-Agent های شناسایی شده برای مسیر /ecp/ نیز عبارتند از:
ExchangeServicesClient/0.0.0.0
python-requests/2.19.1
python-requests/2.25.1
9- در بررسی های به عمل آمده، مشاهده شده است که اغلب، آدرس IP های زیر توسط مهاجمان استفاده شده اند، بنابراین می توان ارتباطات شبکه را با آدرس های زیر بررسی نمود:
103.77.192.219
104.140.114.110
104.250.191.110
108.61.246.56
149.28.14.163
157.230.221.198
167.99.168.251
185.250.151.72
192.81.208.169
203.160.69.66
211.56.98.146
5.254.43.18
80.92.205.81
راه حل رفع آسیب پذیری:
بر اساس نسخه سرور Exchange آسیب پذیر می توان وصله های امنیتی ارائه شده توسط مایکروسافت را نصب نمود. در زیر آدرس هر یک از وصله های ارائه شده آورده شده است.
- نسخه Exchange Server 2010 Service pack 3:
- برای تمامی نسخه های زیر، می توان از این لینک بهره برد:
Exchange Server 2013 Cumulative Update 23
Exchange Server 2016 Cumulative Update 18
Exchange Server 2016 Cumulative Update 19
Exchange Server 2019 Cumulative Update 7
Exchange Server 2019 Cumulative Update 8