اخیرا مایکروسافت و CISA یه حادثه امنیتی رو افشاء کردن که روی چندین مشتری Exchange Online و Outlook.com تاثیر گذاشته. مایکروسافت که این حادثه رو به یه گروه چینی بنام Storm-0558 نسب داده، گفته که هکرها یه کلید خصوصی رمزنگاری (MSA key) رو بدست آوردن و از اون برای جعل توکن های Outlook Web Access (OWA) و Outlook.com استفاده کردن. همچنین بازیگر تهدید از دو مشکل امنیتی در فرایند تایید توکن ها سوء استفاده کرده.
نکته ای که هست اینه که هنوز مشخص نیست این کلید سرقت شده رو چطوری بدست آوردن.
مایکروسافت گفته که Outlook.com و Exchange Online تنها برنامه‌های شناخته شده‌ای هستن که از طریق تکنیک جعل توکن تحت تأثیر قرار گرفتن، اما محققای Wiz Research دریافتن که کلید امضای به خطر افتاده قوی‌تر از اون چیزیه که به نظر میرسه و فقط به این دو سرویس محدود نمیشه.
محققان به این نتیجه رسیدن که کلید MSA سرقت شده میتونه به عامل تهدید اجازه بده تا توکنهای دسترسی رو برای انواع مختلف برنامه‌های Azure Active Directory، از جمله هر برنامه‌ای که از احراز هویت حساب شخصی پشتیبانی میکنه، مانند SharePoint، Teams، OneDrive، برنامه‌های مشتریانی که از عملکرد «login with Microsoft» پشتیبانی میکنن و برنامه‌های multi-tenant در شرایط خاص، جعل کنه.
مایکروسافت برای کاهش خطر اومده این کلیدها رو باطل کرده و یسری IOC هم منتشر کرده. اما محققا متوجه شدن که تشخیص استفاده از توکن های جعلی برای مشتریان به دلیل عدم وجود لاگ مرتبط با فرآیند تأیید توکن ممکنه دشوار باشه.
کلیدهای امضای ارائه دهنده هویت (Identity provider signing keys) ، احتمالا قدرتمندترین اسرار در دنیای مدرن هستن. اونا حتی از کلیدهای TLS هم قوی تر هستن. اگه یه هکری به کلیدهای TLS گوگل دسترسی داشته باشه، بازم باید به نوعی خودش رو در سرور google.com جعل کنه تا بتونه تاثیر قابل توجهی داشته باشه. با identity provider key میشه به هر چیزی ، صندوقهای ایمیل ، سرویس فایل و اکانتهای ابری به سادگی دسترسی داشت.
البته این فقط مختص مایکروسافت نیست، چنین مشکلی میتونه برای گوگل ، فیسبوک و Okta اتفاق بیافته و صنعت بخصوص ارائه دهندگان سرویس های ابری، باید در حفط و نگهداری کلیدهای حیاتی بخصوص این کلید ، دقت کنن.
در این پست به بررسی این حادثه، کلیدهای سرقت شده و اقدامات کاهشی پرداختیم.
ماجرای هک شدن:
قصه این هک اینجوری بوده که اواسط ژوئن یه سازمان Federal Civilian Executive Branch (FCEB) یسری فعالیت مشکوک در محیط ابری Microsoft 365 (M365) خودش مشاهده کرده. این فعالیت مشکوک هم اینجوری بوده که یسری رویداد MailItemsAccessed با ClientAppID و AppID مشکوک در لاگهای M365 Audit مشاهده کردن. این رویداد زمانی ایجاد میشه که ،کاربران دارای مجوز ،به موارد موجود در صندوقهای پستی Exchange Online با استفاده از هر پروتکل اتصالی از هر کلاینتی دسترسی داشته باشن. آژانس FCEB به قضیه مشکوک میشه چون AppID نباید به صندوق پستیه دسترسی داشته باشه، بنابراین این فعالیت رو به مایکروسافت و CISA گزارش میده و در نتیجه تحقیقات مایکروسافت در این خصوص شروع میشه.
آشنایی با گروه هکری Storm-0558 :
طبق گزارش مایکروسافت این حمله توسط گروه هکری چینی Storm-0558 انجام شده. این نسبت دادن براساس ساعات کاری فعالیت بازیگر تهدید و TTPهای حمله بوده . همونطور که در Heatmap زیر مشاهده میکنید، فعالیت بازیگر از دوشنبه تا جمعه ، بین ساعت 12:00 صبح UTC (8:00 صبح به وقت چین) تا 09:00 صبح UTC (5:00 بعد از ظهر به وقت چین) بوده.
این گروه چینی در زمینه جاسوسی سایبری فعالیت داره و عمدتا روی شرکتهای رسانه‌ای، اتاق‌های فکر، تجهیزات و ارائه‌دهندگان خدمات مخابراتی فعالیت میکنه. عمدتاً نهادهای دیپلماتیک، اقتصادی، قانون‌گذاری ایالات متحده و اروپا و افراد مرتبط با منافع ژئوپلیتیکی تایوان و اویغور رو هدف قرار میده. در اغلب کمپینها هدفشون دسترسی به ایمیلهای قربانی بوده. از آگوست سال 2021 علاقه به کار روی برنامه های OAuth در اکانتهای مایکروسافتی بوده.
این گروه از دانش فنی و OPSEC بالایی برخودار هستش و اطلاعات کاملی از مباحث فنی که روش کار میکنه دارن.
این گروه در گذشته بعد از دسترسی به هدف ، از یه وب شل بنام China Chopper استفاده میکرده و یه بدافزار هم بنام Cigril دارن.
در کمپین اخیرشون مشخص شده که از طریق توکن های جعلی ، از 15 مه تونستن به یسری ایمیل از 25 سازمان مختلف از جمله وزارت بازرگانی و خارجه آمریکا دسترسی پیدا کردن.
کلیدهای امضای سرقت شده:
بعد از گزارش مایکروسافت در 11 جولای ، محققایwiz هم تحقیقاتی رو در این زمینه شروع کردن.
در ابتدا بررسی کردن که کدوم کلیدها میتونن توکن های OpenID رو برای اکانتهای مایکروسافت و برنامه های Azure Active Directory امضاء کنن. برای اینکار رفتن سراغ داکیومنتهای مایکروسافت. محققا متوجه شدن که همه برنامه های اکانتهای شخصی Azure نسخه 2.0 به 8 کلید عمومی و همه برنامه های Azure multi-tenant v2.0 با فعال بودن اکانت مایروسافت براشون به 7 کلید عمومی وابسته هستن.
با استفاده از سرویس Wayback Machine ، محققا متوجه شدن که یکی از کلیدهای عمومی که حداقل از سال 2016 وجود داشته، بین 27 ژوئن و 5 جولای 2023 جایگزین شده، که مطابق با بازه زمانی هستش که مایکروسافت کلید سرقت شده رو طبق پست وبلاگ خودش جایگزین کرده. که در زیر متادیتای اونو مشاهده میکنید :
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "kty":"RSA", "use":"sig", "kid":"1LTMzakihiRla_8z2BEJVXeWMqo", "x5t":"1LTMzakihiRla_8z2BEJVXeWMqo", "n":"3sKcJSD4cHwTY5jYm5lNEzqk3wON1CaARO5EoWIQt5u-X-…", "e":"AQAB", "x5c":[ "MIIDYDCCAkigAwIBAgIJAIB4jVVJ3BeuMA0GCSqGSIb3DQEBCwUA…" ], "issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0" } |
گواهینامه کلید عمومی قدیمی نشون میده که در 5 آوریل 2016 صادر شده و در 4 آوریل 2021 منقضی شده و thumbprint اون با thumbprint کلیدی که مایکروسافت در گزارش خودش بیان کرده، مطابقت داره:
محققا در این نقطه به این باور رسیدن که اگرچه کلید خصوصی که توسط هکرها بدست اومده برای Microsoft MSA tenant در Azure بوده، اما میتونستن توکن های OpenID v2.0 رو برای انواع برنامه های Azure Active Directory امضاء کنن.
اهمیت OpenID signing key سرقت شده:
پلتفرم Azure identity لیست های متعددی از کلیدهای قابل اعتماد رو منتشر میکنه که در انواع مختلف برنامه ها استفاده میشن. اینا برای تایید یکپارچگی توکن هایی که توسط Azure Active Directory (AAD) صادر میشن، مورد استفاده قرار میگیرن . در طول فرآیند احراز هویت یه برنامه AAD، برنامه باید صحت توکن رو با تأیید امضای اون از طریق لیست کلید عمومی قابل اعتماد صحیح تأیید کنه. این راستی‌آزمایی تعیین میکنه که آیا توکن باید قابل اعتماد باشه یا خیر.
در زیر لیستی از گواهی های عمومی Azure Active Directory رو مشاهده میکنید:
|
1 2 3 4 5 6 7 8 9 10 |
# Azure Active Directory multi-tenant applications: https://login.microsoftonline.com/organizations/discovery/v2.0/keys # Azure Active Directory Multi-Tenant & Personal Account Applications (mixed audience): https://login.microsoftonline.com/common/discovery/v2.0/keyshttps://login.microsoftonline.com/common/discovery/v2.0/keys # Azure Active Directory Personal Account (MSA) Applications: https://login.microsoftonline.com/consumers/discovery/v2.0/keyshttps://login.microsoftonline.com/consumers/discovery/v2.0/keys https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/discovery/v2.0/keyshttps://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/discovery/v2.0/keys # Azure Active Directory Single-Tenant Applications: https://login.microsoftonline.com/${tenantId}/discovery/v2.0/keys https://login.microsoftonline.com/${tenantId}/discovery/v2.0/keys?appid=${AppId} |
اگه هر یک از کلیدهای موجود در لیست بالا، به خطر بیافته، خطر قابل توجهی برای برنامه هایی که از کلیدها برای اعتبارسنجی استفاده میکنن، می افته و این امکان رو به بازیگران تهدید میده تا بتونن توکن های دسترسی معتبر که وابسته به پلتفرم Azure identity هستش رو جعل کنه.
شکل زیر ریسکهایی که با هک شدن OpenID signing key میشه اتفاق بیافته رو نشون میده :
بر اساس گزارش مایکروسافت ، ظاهراً Storm-0558 تونسته به یکی از چندین کلیدی که برای امضا و تأیید توکنهای دسترسی AAD در نظر گرفته شده ، دسترسی پیدا کنه. کلید سرقت شده برای امضای توکن دسترسی OpenID نسخه 2.0 برای حساب‌های شخصی و برنامه‌های AAD برای اکانت multi-tenant یا شخصی، مورد اعتماد بوده.
شکل زیر نشون دهنده برنامه هایی هستن که میتونن به کلید سرقت شده توسط هکرها، اعتماد کنن .
کدوم برنامه ها تحت تأثیر قرار گرفتن؟
- هر برنامه Azure Active Directory که از «Personal Microsoft accounts only» پشتیبانی میکنه و با پروتکل نسخه 2.0 مایکروسافت کار میکنه، تحت تأثیر قرار گرفته . این شامل برنامه‌های مدیریت‌شده مایکروسافت، مانند Outlook، SharePoint، OneDrive، و Teams، و همچنین برنامه‌های مشتریانی هستش که از احراز هویت اکانت مایکروسافت پشتیبانی میکنن، از جمله برنامه‌هایی که از عملکرد «Login with Microsoft» استفاده میکنن.
- هر برنامه Azure Active Directory که از “mixed audience” پشتیبانی میکنه و با پروتکل v2.0 مایکروسافت کار می کنه نیز تحت تأثیر قرار گرفته . عامل تهدید میتونن توکنهای دسترسی معتبر رو جعل و هویت کاربران برنامه‌ای رو که با حساب شخصی مایکروسافت خودش لاگین کرده رو جعل کنه. مایکروسافت برای محدود کردن قدرت کلید MSA یه افزونه ای رو داره که البته بصورت پیش فرض فعال نیست و باید توسط توسعه دهنده فعال بشه.
- هر برنامه multi-tenant ای که جوری پیکربندی شده باشه که به نقطه پایانی کلیدهای «common» نسخه 2.0 وابسته باشه، تحت تاثیر هستش. براساس مستندات مایکروسافت مشخص نیست که چه زمانی باید از این نقطه پایانی استفاده میشه، بنابراین ممکنه برخی از برنامه های multi-tenant تحت تاثیر قرار میگیرن.
کلید جعلی چطوری کار میکنه :
https://sts.windows.net/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 تنظیم بشه. همچنین tenant ID claim (tid) هم روی 9188040d-6c67-4c5b-b112-36a304b66dad تنظیم بشه که شناسه MSA tenant هستش.آیا مشتریان Azure هنوز در معرض خطر هستند؟
توصیه های برای کاربران Azure :
- برای شناسایی اینکه آیا کلید سرقت شده در محیط شما استفاده شده یا خیر، همه برنامه‌های تحت تأثیر احتمالی رو در محیط خودتون شناسایی کنید، بعد بررسی کنید که آیا توکن جعلی در اونها استفاده شدن یا نه . همچنین از IoCهای منتشر شده توسط مایکروسافت استفاده کنید تا هر فعالیتی رو که از آدرس‌های IP ارائه‌شده توسط مایکروسافت نشات میگیرن، پیدا کنید.
- مطمئن بشید که هیچ یک از برنامه‌ها از نسخه کش شده گواهی‌های عمومی OpenID مایکروسافت استفاده نمیکنن و اگر چنین باشه، حافظه کش رو بروز کنید.
- مایکروسافت تأییدیه‌های دیگه ای رو به Azure SDK اضافه کرده که برای جلوگیری از استفاده از کلیدهای MSA برای احراز هویت در اکانتهای سازمانی طراحی شدن. به کاربران package توصیه میشه اونارو به آخرین نسخه بروز کنن.
چطوری کلید سرقت شده رو در محیط خودمون بررسی کنیم :
|
1 2 |
https://login.microsoftonline.com/common/discovery/v2.0/keyscommon https://login.microsoftonline.com/consumers/discovery/v2.0/keys |
|
1 |
az ad app list --filter "(signinaudience eq 'AzureADMultipleOrgs' or signinaudience eq 'AzureADandPersonalMicrosoftAccount' or signinaudience eq 'PersonalMicrosoftAccount')" --query "[?id].{AppName:displayName, AppID:appId, ObjID:id, HomePageURL:web.homePageUrl}" |
|
1 |
az ad app list --filter "(signinaudience eq 'AzureADMultipleOrgs' or signinaudience eq 'AzureADandPersonalMicrosoftAccount' or signinaudience eq 'PersonalMicrosoftAccount')" --query "[?web && web.homePageUrl && contains(web.homePageUrl, 'azurewebsites.net')].{AppName:displayName, AppID:appId, ObjID:id, HomePageURL:web.homePageUrl}" |
بعد از اینکه برنامه ها رو مشخص کردیم، در مرحله بعدی دنبال احرازهویتهایی مشکوکی باید باشیم که از طریق توکنهای جعلی OpenID امضاء شده با کلید سرقت شده، انجام شدن. برای این کار میتونیم توکن های دسترسی مورد استفاده در برنامه رو آنپک کنیم و رشته 1LTMzakihiRla_8z2BEJVXeWMqo رو داخل فیلد kid در JOSE Header جستجو کنیم.
به گفته مایکروسافت، کلید سرقت شده غیرفعال هستش و بنابراین هرگونه توکن دسترسی امضا شده توسط این کلید باید مشکوک تلقی بشه.
متاسفانه اقدامات استانداری برای لاگ گیری مختص برنامه وجود نداره و بنابراین در بیشتر موارد، صاحبان برنامه‌ها لاگهای دقیقی که حاوی raw access token یا کلید امضای اون باشه، ندارن. در نتیجه، شناسایی و بررسی چنین رویدادهایی میتونه برای دارندگان برنامه ها بسیار چالش برانگیز باشه.
برای بررسی یه برنامه AAD که صرفاً برای احراز هویت multi-tenant پیکربندی شده (بدون پشتیبانی از حساب های شخصی مایکروسافت)، میتونید با فیلتر کردن «iss» و «tid» در توکن دسترسی، توکن های جعلی رو شناسایی کنید.
برنامه‌ها معمولاً از این فیلدها استفاده میکنن و به احتمال زیاد در لاگهای برنامه وجود دارن. علاوه بر این، هرگونه تلاش برای اتصال با یه توکن دسترسی امضا شده توسط MSA tenant ID 9188040d-6c67-4c5b-b112-36a304b66dad ممکنه نشون دهنده استفاده از یک کلید سرقت شده باشه.
در نهایت، اگر لاگ HTTP رو برای WebApp فعال کرده باشید، ممکنه بتونید ببینید کدوم آدرس های IP به برنامه شما دسترسی پیدا کردن. بر اساس گزارش مایکروسافت، آدرس‌های IP زیر با عامل تهدید مرتبط هستن، بنابراین میتونید با اجرای کوئری زیر در Log Analytics برای هر یک از برنامه‌های تحت تأثیر احتمالی Tبررسی کنید که آیا با این آدرسها در ارتباط بودن یا نه :
|
1 2 3 4 5 6 7 8 9 10 11 |
AppServiceHTTPLogs | where Result == "Success" and CIp in ("195.26.87.219","185.236.228.183","85.239.63.160","193.105.134.58", "146.0.74.16","91.231.186.226","91.222.174.41","185.38.142.249", "51.89.156.153","176.31.90.129","137.74.181.100","193.36.119.45", "185.158.248.159","131.153.78.188","37.143.130.146","146.70.157.45", "185.195.200.39","185.38.142.229","146.70.121.44","31.42.177.181", "185.51.134.52","173.44.226.70","45.14.227.233","185.236.231.109", "178.73.220.149","45.14.227.212","91.222.173.225","146.70.35.168", "146.70.157.213","31.42.177.201","5.252.176.8","80.85.158.215", "193.149.129.88","5.252.178.68","116.202.251.8") |
منابع