جعل Client ID در OAuth؛ شمارش کاربران بدون ردپا در لاگ
خلاصهٔ کاملتر
به گزارش تیم تحقیقاتی Proofpoint، تکنیک تازهای به اسم جعل شناسهٔ کلاینت (OAuth client ID spoofing) داره بین مهاجمهای محیطهای ابری جا میافته. ایدهٔ اصلی سادهست: در درخواست احراز هویت، پارامتر client_id یعنی شناسهٔ یکتای اپلیکیشن ارسال میشه و همین مقدار در لاگ ورود Microsoft Entra ID ثبت میشه. مهاجم بهجای شناسهٔ یک اپلیکیشن واقعی، یک شناسهٔ ساختگی میفرسته.
نکتهٔ کلیدی اینه که Entra ID بسته به معتبر بودن شناسه و ثبتشده بودن اپلیکیشن، پاسخهای متفاوتی برمیگردونه. نویسنده میگه با تحلیل همین تفاوتها — که در قالب کدهای خطای AADSTS ظاهر میشن — یک درخواستکنندهٔ احراز هویتنشده میتونه بفهمه کدوم نام کاربری وجود داره، کدوم رمز درسته، و حتی اینکه احراز هویت چندعاملی یا سیاست دسترسی مشروط اعمال شده یا نه.
مزیت این روش برای مهاجم، پنهانکاریه. وقتی شناسهٔ جعلی استفاده میشه، فیلد نام اپلیکیشن در لاگ خالی میمونه؛ پس هر سازوکار تشخیصی که دنبال جهش ترافیک روی یک اپلیکیشن خاص میگرده، این فعالیت رو کاملاً از دست میده. مهمتر از اون، وقتی نام کاربری و رمز هر دو درست باشن، سرویس خطای «شناسهٔ اپلیکیشن ناشناخته» برمیگردونه — یعنی مهاجم اعتبارنامهٔ معتبر رو پیدا کرده ولی هیچ رکورد ورود موفقی ساخته نشده.
روشهای سنتی شمارش کاربر معمولاً یک اپلیکیشن داخلی ثابت مایکروسافت رو هدف میگیرن و همین باعث میشه انبوه درخواستها روی یک اپلیکیشن، سریع توجه تیم SOC رو جلب کنه. پخش کردن تلاشها روی هزاران اپلیکیشن خیالی، هم همبستگیسازی رو سخت میکنه، هم از محدودیت نرخ فرار میده، و هم سیاستهای دسترسی مشروطی که فقط روی اپلیکیشنهای مشخص تعریف شدن رو دور میزنه.
Proofpoint دو کمپین بزرگ با همین روش رو ردیابی کرده. کمپینی که با نام UNK_pyreq2323 دنبال میشه از دی ۱۴۰۴ شروع شده، از زیرساخت AWS اومده و بیش از یک میلیون حساب در نزدیک ۴٬۰۰۰ سازمان رو هدف گرفته؛ حجم بالای تلاشهای ناموفق باعث قفل شدن حساب حدود ۲۸٪ از کاربران هدف شده.
کمپین دوم با نام UNK_OutFlareAZ از آذر ۱۴۰۴ آغاز شده، بیشتر از زیرساخت Cloudflare استفاده کرده و مقیاسش بزرگتر بوده: بیش از دو میلیون کاربر و ۳٫۷ میلیون شناسهٔ اپلیکیشن جعلی. تفاوتها هم گویاست؛ اولی فقط بخشی از یک شناسهٔ شناختهشده رو تصادفی میکرده و هر شناسه رو تا ۱۲ کاربر به کار میبرده، ولی دومی برای هر درخواست یک شناسهٔ کاملاً تصادفی میساخته و کاربرها رو الفبایی جلو میرفته.
همین تفاوتها در ابزار، زیرساخت و الگوی اجرا، به گفتهٔ نویسنده نشون میده چند گروه بهشکل مستقل به همین تکنیک رسیدن. توصیهٔ دفاعی گزارش هم مشخصه: لاگهای ورود رو دنبال رکوردهایی بگردید که نام اپلیکیشن یا شناسهٔ اپلیکیشن توشون خالیه، و خطای مربوط به «شناسهٔ اپلیکیشن ناشناخته» رو صرفاً یک ورود ناموفق ساده حساب نکنید — ممکنه نشونهٔ لو رفتن یک اعتبارنامهٔ معتبر باشه.
نکات کلیدی:
- در جعل client ID، مهاجم شناسهٔ اپلیکیشن ساختگی میفرسته و نیازی به ثبت هیچ اپلیکیشن OAuth نداره
- تفاوت پاسخهای Entra ID اجازه میده اعتبار نام کاربری و رمز بدون ثبت ورود موفق استنتاج بشه
- خالی موندن فیلد نام اپلیکیشن در لاگ، تشخیصهای مبتنی بر اپلیکیشن و سیاستهای دسترسی مشروط رو دور میزنه
- کمپین UNK_pyreq2323 بیش از یک میلیون کاربر در حدود ۴٬۰۰۰ سازمان رو هدف گرفت و ۲۸٪ از اونها قفل حساب گرفتن
- کمپین UNK_OutFlareAZ با بیش از ۳٫۷ میلیون شناسهٔ جعلی، نسخهٔ پختهتر همین تکنیک بود
- رکوردهای ورود بدون نام اپلیکیشن رو باید نشانهٔ احتمالی این حمله در نظر گرفت
