MFA Fatigue Attack چیست؟ بررسی حمله بمباران درخواست تأیید ورود

MFA Fatigue Attack یا حمله خستگی احراز هویت چندمرحله‌ای، نوعی حمله مهندسی اجتماعی است که مهاجم در آن با ارسال مکرر درخواست‌های تأیید ورود، تلاش می‌کند کاربر را به پذیرش یک ورود غیرمجاز وادار کند. این حمله معمولاً سیستم‌های مبتنی بر اعلان Push را هدف قرار می‌دهد و از خستگی، سردرگمی یا بی‌دقتی کاربر سوءاستفاده می‌کند. استفاده از احراز هویت مقاوم در برابر فیشینگ، تأیید عددی، محدودسازی درخواست‌ها و نظارت بر ورودهای مشکوک از مهم‌ترین راهکارهای مقابله با آن است.

مقدمه: وقتی یک اعلان امنیتی به ابزار نفوذ تبدیل می‌شود

تصور کنید نیمه‌شب تلفن همراه شما چندین بار پشت سر هم اعلان تأیید ورود دریافت می‌کند. شما قصد ورود به هیچ حسابی را ندارید، اما پیام‌ها همچنان ظاهر می‌شوند.

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

همین تصمیم ظاهراً ساده می‌تواند به مهاجم اجازه دهد وارد حساب کاربری شما شود.

این سناریو اساس حمله‌ای است که با نام‌های MFA Fatigue Attack، MFA Bombing، Push Bombing و Push Notification Fatigue شناخته می‌شود.

احراز هویت چندعاملی یا Multi-Factor Authentication یکی از مهم‌ترین کنترل‌های امنیت حساب‌های کاربری است. این فناوری باعث می‌شود دانستن رمز عبور به‌تنهایی برای ورود کافی نباشد.

بااین‌حال، امنیت MFA به روش پیاده‌سازی و نحوه تعامل کاربر با درخواست تأیید نیز وابسته است.

در سیستم‌هایی که ورود با فشردن یک دکمه تأیید می‌شود، احتمال دارد مهاجم به‌جای تلاش برای شکستن فناوری رمزنگاری، مستقیماً تصمیم کاربر را هدف قرار دهد.

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

در بعضی سناریوها نیز از جعل هویت کارکنان پشتیبانی استفاده می‌شود تا درخواست غیرمنتظره، قانونی جلوه کند.

نکته مهم این است که حمله MFA Fatigue لزوماً به معنای هک شدن تلفن همراه یا نرم‌افزار احراز هویت نیست. در بسیاری از موارد، مهاجم از روند عادی ارسال اعلان سوءاستفاده می‌کند.

در این مقاله بررسی می‌کنیم MFA Fatigue Attack چیست، چگونه انجام می‌شود، چه تفاوتی با سایر حملات احراز هویت دارد و کاربران، مدیران سایت و سازمان‌ها چگونه می‌توانند آن را شناسایی و مهار کنند.

MFA چیست و چرا در امنیت حساب‌های کاربری اهمیت دارد؟

برای شناخت حمله MFA Fatigue ابتدا باید سازوکار احراز هویت چندعاملی را درک کنیم.

MFA مخفف Multi-Factor Authentication است و به روشی گفته می‌شود که برای اثبات هویت کاربر، از دو یا چند عامل متعلق به دسته‌های متفاوت استفاده می‌کند.

این عوامل معمولاً در سه گروه قرار می‌گیرند:

• چیزی که می‌دانید: مانند رمز عبور یا PIN.
• چیزی که در اختیار دارید: مانند کلید امنیتی سخت‌افزاری یا دستگاه ثبت‌شده.
• چیزی که هستید: مانند اثر انگشت یا ویژگی‌های بیومتریک.

برای مثال، اگر کاربر ابتدا رمز عبور خود را وارد کند و سپس با یک برنامه احراز هویت روی گوشی، درخواست ورود را تأیید کند، سیستم از دو عامل متفاوت استفاده کرده است.

تفاوت MFA و 2FA

اصطلاح 2FA یا Two-Factor Authentication به احراز هویتی اشاره دارد که دقیقاً از دو عامل مستقل استفاده می‌کند.

MFA مفهوم گسترده‌تری است و می‌تواند دو یا چند عامل داشته باشد.

در کاربرد روزمره، این دو اصطلاح گاهی به‌جای یکدیگر استفاده می‌شوند؛ اما از نظر فنی کاملاً یکسان نیستند.

نکته مهم‌تر این است که استفاده از دو مرحله لزوماً به معنای استفاده از دو عامل مستقل نیست. برای مثال، وارد کردن دو رمز از یک نوع، الزاماً احراز هویت دو‌عاملی محسوب نمی‌شود.

چرا رمز عبور به‌تنهایی کافی نیست؟

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

اگر حساب فقط با رمز عبور محافظت شود، فردی که رمز معتبر را در اختیار دارد ممکن است بتواند وارد حساب شود.

MFA یک مانع اضافی ایجاد می‌کند.

در چنین شرایطی، حتی اگر رمز عبور افشا شده باشد، مهاجم معمولاً برای تکمیل ورود به عامل دیگری نیاز دارد.

البته میزان امنیت این مانع به نوع عامل دوم بستگی دارد.

روش‌های رایج احراز هویت چندعاملی

روش‌های متداول شامل موارد زیر هستند:

1. دریافت رمز یک‌بارمصرف از طریق پیامک.
2. تولید کد زمان‌دار با نرم‌افزار Authenticator.
3. تأیید اعلان Push روی گوشی.
4. استفاده از کلید امنیتی مبتنی بر FIDO2.
5. استفاده از Passkey با تأیید بیومتریک یا PIN دستگاه.

این روش‌ها از نظر مقاومت در برابر فیشینگ، سوءاستفاده از اعلان و حملات واسطه‌ای یکسان نیستند.

در حمله MFA Fatigue، بیشترین توجه به روش‌هایی معطوف است که کاربر می‌تواند درخواست ورود را با یک تأیید ساده بپذیرد.

MFA Fatigue Attack چیست و چه هدفی دارد؟

حمله MFA Fatigue نوعی سوءاستفاده از فرآیند احراز هویت است که در آن مهاجم تلاش می‌کند با ایجاد درخواست‌های تأیید مکرر، مقاومت یا دقت کاربر را کاهش دهد.

واژه Fatigue به معنای خستگی است و به خستگی ذهنی ناشی از تکرار اعلان‌ها اشاره دارد.

در این حمله، مهاجم به‌دنبال شکستن الگوریتم رمزنگاری عامل دوم نیست؛ بلکه تلاش می‌کند کاربر قانونی را به تأیید درخواستی وادار کند که خودش آغاز نکرده است.

چرا این حمله را MFA Bombing می‌نامند؟

اصطلاح MFA Bombing یا Push Bombing به ارسال انبوه درخواست‌های تأیید اشاره دارد.

در اینجا منظور از Bombing، بمباران اطلاعاتی کاربر با اعلان‌های تکراری است، نه حمله‌ای از نوع تخریب فیزیکی.

کاربر ممکن است در مدت کوتاهی چندین درخواست دریافت کند و در تشخیص درخواست معتبر از نامعتبر دچار سردرگمی شود.

آیا MFA Fatigue یک حمله فنی است یا مهندسی اجتماعی؟

این حمله ترکیبی از سوءاستفاده فنی و مهندسی اجتماعی محسوب می‌شود.

بخش فنی ممکن است شامل استفاده از اطلاعات ورود افشاشده و ایجاد درخواست‌های احراز هویت باشد.

بخش انسانی بر نحوه واکنش قربانی تمرکز دارد.

مهاجم می‌خواهد کاربر بدون اطمینان از منشأ درخواست، آن را تأیید کند.

در بعضی موارد، فشار روانی با تماس تلفنی یا پیام جعلی پشتیبانی افزایش پیدا می‌کند.

جایگاه MFA Fatigue در MITRE ATT&CK

این رفتار در چارچوب MITRE ATT&CK با تکنیک T1621 و عنوان Multi-Factor Authentication Request Generation شناخته می‌شود.

این تکنیک در حوزه Credential Access قرار دارد؛ زیرا مهاجم تلاش می‌کند مانع احراز هویت چندعاملی را پشت سر بگذارد و به حساب هدف دسترسی پیدا کند.

در بعضی محیط‌ها، درخواست‌های احراز هویت ممکن است از مسیرهایی مانند بازیابی حساب نیز ایجاد شوند. بنابراین، دریافت اعلان غیرمنتظره همیشه اثبات نمی‌کند که رمز عبور کاربر حتماً افشا شده است.

این تمایز در تحلیل حادثه اهمیت زیادی دارد.

حمله MFA Fatigue چگونه کار می‌کند؟

برای درک بهتر، می‌توان فرآیند حمله را از دید دفاعی به چند مرحله تقسیم کرد.

این مراحل توضیح می‌دهند چه رویدادهایی ممکن است در یک حمله مشاهده شوند و در هر بخش چه نشانه‌هایی برای تیم امنیت اهمیت دارند.

مرحله اول: ایجاد یک تلاش ورود مشکوک

در بسیاری از سناریوها، مهاجم از اطلاعات ورود معتبر یا افشاشده استفاده می‌کند.

این اطلاعات ممکن است قبلاً در یک حادثه امنیتی دیگر سرقت شده باشند.

در این مرحله، سامانه احراز هویت ممکن است رمز عبور را معتبر تشخیص دهد و برای تکمیل ورود، عامل دوم را درخواست کند.

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

مرحله دوم: ارسال اعلان تأیید ورود

پس از آغاز فرآیند احراز هویت، اعلان مربوط به دستگاه ثبت‌شده کاربر ارسال می‌شود.

در یک سیستم Push ساده، کاربر معمولاً دو انتخاب دارد:

• تأیید درخواست ورود.
• رد درخواست ورود.

اگر این درخواست مربوط به ورود خود کاربر باشد، تأیید آن بخشی از فرآیند معمول احراز هویت است.

اما اگر کاربر هیچ تلاشی برای ورود نکرده باشد، درخواست باید مشکوک تلقی شود.

مرحله سوم: تکرار درخواست‌های احراز هویت

در حمله MFA Fatigue، چندین درخواست ممکن است در فاصله‌های زمانی مختلف ایجاد شوند.

هدف این تکرار، کاهش توجه کاربر و افزایش احتمال پذیرش اشتباه است.

اعلان‌های پشت سر هم ممکن است باعث مزاحمت هنگام کار، مطالعه یا استراحت شوند.

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

از دید امنیتی، الگوی تکرار درخواست‌های ردشده یا منقضی‌شده می‌تواند نشانه مهمی برای شناسایی حمله باشد.

مرحله چهارم: ایجاد فشار روانی

مهاجم ممکن است به تکرار اعلان‌ها اکتفا نکند.

گاهی پیام یا تماسی با عنوان پشتیبانی فنی، مسئول امنیت یا واحد فناوری اطلاعات ارسال می‌شود.

در چنین سناریویی، تلاش می‌شود کاربر قانع شود که درخواست تأیید مربوط به یک عملیات ضروری است.

برای مثال، ممکن است ادعا شود که تأیید درخواست برای رفع مشکل حساب لازم است.

این ادعا نباید بدون بررسی از مسیر رسمی سازمان پذیرفته شود.

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

لحظه حساس زمانی است که کاربر یکی از درخواست‌های غیرمجاز را تأیید می‌کند.

در سیستم‌هایی که تأیید اعلان برای تکمیل احراز هویت کافی است، این اقدام ممکن است ورود مهاجم را امکان‌پذیر کند.

البته وجود کنترل‌هایی مانند Conditional Access، محدودیت دستگاه، ارزیابی ریسک یا سیاست‌های دیگر می‌تواند همچنان مانع ورود شود.

بنابراین، تأیید اشتباه به معنای موفقیت قطعی نفوذ در همه سامانه‌ها نیست.

مرحله ششم: بررسی پیامدهای امنیتی

اگر مهاجم موفق به ورود شود، خطر به سطح دسترسی حساب بستگی دارد.

یک حساب عادی ممکن است به اطلاعات شخصی یا فایل‌های کاربر دسترسی داشته باشد.

اما حساب مدیریتی می‌تواند مجوزهای بسیار حساس‌تری در اختیار داشته باشد.

اقداماتی مانند ایجاد نشست جدید، تغییر روش احراز هویت یا دسترسی به داده‌ها باید در بررسی حادثه مورد توجه قرار گیرند.

چرا حمله بمباران درخواست تأیید ورود مؤثر است؟

قدرت این حمله از یک ضعف روان‌شناختی و عملیاتی ناشی می‌شود: کاربران همیشه نمی‌توانند تعداد زیادی اعلان امنیتی را با دقت یکسان بررسی کنند.

خستگی ناشی از اعلان‌های مکرر

کاربران روزانه اعلان‌های فراوانی از برنامه‌ها و سرویس‌های مختلف دریافت می‌کنند.

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

در حمله MFA Fatigue، همین وضعیت به یک عامل خطر تبدیل می‌شود.

عادت به تأیید سریع

در محیط‌های کاری، کاربران ممکن است روزانه چندین بار وارد سامانه‌های سازمانی شوند.

اگر فرآیند ورود دائماً با تأیید یک اعلان همراه باشد، انجام این کار می‌تواند به یک رفتار عادی و تقریباً خودکار تبدیل شود.

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

اعتماد به ظاهر برنامه Authenticator

اعلان ممکن است از یک برنامه معتبر و رسمی نمایش داده شود.

همین موضوع می‌تواند باعث شود کاربر به درخواست اعتماد کند.

اما معتبر بودن برنامه احراز هویت به معنای معتبر بودن تمام درخواست‌هایی نیست که در آن نمایش داده می‌شوند.

برنامه ممکن است یک درخواست واقعی از طرف سامانه احراز هویت را نشان دهد؛ درحالی‌که آغازکننده آن مهاجم بوده است.

استفاده از حس فوریت

در حملات مهندسی اجتماعی، ایجاد اضطراب و فوریت یک روش شناخته‌شده است.

کاربر ممکن است تصور کند برای جلوگیری از قفل شدن حساب یا رفع اختلال باید سریع واکنش نشان دهد.

در مقابل، فرآیند امن باید به کاربر اجازه دهد بدون فشار زمانی غیرضروری، درخواست را بررسی و در صورت لزوم رد کند.

ابهام درباره منشأ درخواست

بعضی سامانه‌ها اطلاعات کافی درباره دستگاه، برنامه یا موقعیت تقریبی ورود نمایش نمی‌دهند.

در این وضعیت، کاربر ممکن است نتواند ارتباط درخواست با فعالیت خودش را تشخیص دهد.

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

پیش‌نیازهای حمله MFA Fatigue چیست؟

شناخت شرایطی که احتمال وقوع این حمله را افزایش می‌دهند، برای کاهش سطح خطر ضروری است.

استفاده از MFA مبتنی بر تأیید ساده

سیستم‌هایی که تنها با فشردن گزینه Approve یا Yes ورود را تأیید می‌کنند، بیشتر در معرض سوءاستفاده از خستگی اعلان قرار دارند.

در مقابل، روش‌هایی که تعامل معنادار و مرتبط با نشست ورود را ضروری می‌کنند، مقاومت بیشتری دارند.

نبود محدودیت برای تعداد درخواست‌ها

اگر یک سامانه اجازه دهد درخواست‌های احراز هویت به‌صورت مکرر و بدون کنترل مناسب ایجاد شوند، احتمال مزاحمت و فشار بر کاربر افزایش پیدا می‌کند.

محدودسازی نرخ درخواست یا Rate Limiting یکی از کنترل‌های دفاعی مهم است.

ضعف در شناسایی ورودهای غیرعادی

اگر سامانه نتواند تلاش‌های ورود از دستگاه‌ها، موقعیت‌ها یا الگوهای غیرمعمول را ارزیابی کند، ممکن است درخواست‌های زیادی به مرحله تأیید برسند.

استفاده از ارزیابی ریسک مبتنی بر زمینه می‌تواند به کاهش این مشکل کمک کند.

ضعف در سیاست‌های احراز هویت

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

البته هیچ‌یک از این شرایط به‌تنهایی وقوع حمله موفق را تضمین نمی‌کنند.

نشانه‌های حمله MFA Fatigue برای کاربران

شناسایی سریع رفتار غیرعادی می‌تواند از تبدیل یک تلاش ناموفق به نفوذ موفق جلوگیری کند.

دریافت اعلان بدون تلاش برای ورود

مهم‌ترین نشانه، دریافت درخواست تأیید در زمانی است که کاربر هیچ فرآیند ورود یا بازیابی حسابی آغاز نکرده است.

چنین درخواست‌هایی نباید تأیید شوند.

حتی اگر اعلان از برنامه رسمی Authenticator نمایش داده شود، ارتباط آن با فعالیت خود کاربر باید بررسی شود.

دریافت درخواست‌های متوالی

اگر چندین درخواست تأیید در مدت کوتاهی ظاهر شوند، باید احتمال حمله Push Bombing در نظر گرفته شود.

به‌خصوص زمانی که کاربر قبلاً درخواست‌های مشابه را رد کرده است.

نمایش اطلاعات ورود غیرمعمول

بعضی برنامه‌ها نام سرویس، دستگاه یا موقعیت تقریبی ورود را نمایش می‌دهند.

اگر این اطلاعات با فعالیت کاربر سازگار نباشند، درخواست مشکوک است.

البته موقعیت جغرافیایی مبتنی بر IP همیشه دقیق نیست و استفاده از VPN یا شبکه تلفن همراه می‌تواند موقعیت نمایش‌داده‌شده را تغییر دهد.

تماس غیرمنتظره با عنوان پشتیبانی

اگر فردی هم‌زمان با دریافت اعلان‌ها تماس بگیرد و درخواست تأیید ورود کند، احتمال سوءاستفاده از مهندسی اجتماعی مطرح می‌شود.

تأیید هویت تماس‌گیرنده باید از مسیر رسمی و مستقلی انجام شود.

شماره تماس نمایش‌داده‌شده به‌تنهایی معیار قابل اعتمادی برای شناسایی تماس‌گیرنده نیست.

تغییرات ناخواسته در تنظیمات امنیتی

دریافت پیام درباره اضافه شدن دستگاه جدید، تغییر روش MFA یا ایجاد نشست ناشناس می‌تواند نشانه دیگری از دسترسی غیرمجاز باشد.

در چنین وضعیتی، فقط رد کردن اعلان‌ها کافی نیست و بررسی کامل امنیت حساب ضرورت دارد.

هنگام دریافت درخواست‌های مشکوک MFA چه باید کرد؟

اگر بدون تلاش برای ورود، اعلان‌های تأیید دریافت می‌کنید، باید موضوع را به‌عنوان یک هشدار امنیتی جدی بررسی کنید.

۱. درخواست را تأیید نکنید

اولین اقدام، خودداری از تأیید هر درخواستی است که شخصاً آن را آغاز نکرده‌اید.

حتی اگر تعداد اعلان‌ها زیاد باشد، برای متوقف کردن مزاحمت نباید گزینه تأیید را انتخاب کنید.

در صورت وجود گزینه رد درخواست، می‌توان از آن استفاده کرد.

۲. از قابلیت گزارش فعالیت مشکوک استفاده کنید

بعضی سامانه‌های احراز هویت امکان Report Suspicious Activity یا Deny and Report را فراهم می‌کنند.

این قابلیت به تیم امنیت یا ارائه‌دهنده سرویس کمک می‌کند رویداد را شناسایی کند.

وجود این گزینه به نوع برنامه و تنظیمات سازمان بستگی دارد.

۳. رمز عبور حساب را از مسیر رسمی تغییر دهید

اگر احتمال می‌دهید اطلاعات ورود افشا شده‌اند، رمز عبور حساب را از طریق وب‌سایت یا برنامه رسمی تغییر دهید.

از لینک‌هایی که در پیام‌های غیرمنتظره ارسال شده‌اند استفاده نکنید.

رمز جدید باید یکتا باشد و در سرویس‌های دیگر استفاده نشده باشد.

تغییر رمز عبور یک اقدام مهم است، اما ممکن است نشست‌های قبلی را به‌صورت خودکار باطل نکند.

۴. نشست‌های فعال را بررسی کنید

اگر سرویس امکان مشاهده نشست‌ها و دستگاه‌های متصل را دارد، فهرست آن‌ها را بررسی کنید.

نشست‌های ناشناس یا غیرضروری باید از طریق امکانات رسمی سرویس خاتمه داده شوند.

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

۵. روش‌های احراز هویت ثبت‌شده را بازبینی کنید

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

هرگونه تغییر مشکوک باید از طریق فرآیند امن بازیابی حساب رسیدگی شود.

۶. موضوع را به مسئول امنیت اطلاع دهید

در حساب‌های سازمانی، اطلاع‌رسانی به تیم فناوری اطلاعات یا SOC اهمیت زیادی دارد.

اطلاعاتی مانند زمان درخواست‌ها، نام برنامه و تعداد تقریبی اعلان‌ها می‌توانند به بررسی کمک کنند.

نباید برای بررسی حادثه، کدهای یک‌بارمصرف یا اطلاعات محرمانه را در اختیار افراد ناشناس قرار داد.

۷. در صورت تأیید اشتباه، حادثه را فوری گزارش کنید

اگر یکی از درخواست‌های مشکوک را تأیید کرده‌اید، باید احتمال ایجاد نشست غیرمجاز بررسی شود.

این وضعیت نباید صرفاً با تغییر رمز عبور تمام‌شده تلقی شود.

تیم امنیت باید ورودهای موفق، نشست‌ها، توکن‌های فعال و تغییرات حساب را نیز ارزیابی کند.

تفاوت MFA Fatigue Attack با سایر حملات احراز هویت

حمله بمباران درخواست تأیید ورود با روش‌هایی مانند Brute Force، فیشینگ و سرقت کد یک‌بارمصرف تفاوت دارد.

شناخت این تفاوت‌ها کمک می‌کند کنترل امنیتی متناسب با تهدید انتخاب شود.

تفاوت MFA Fatigue و Brute Force

در Brute Force، مهاجم تلاش می‌کند رمز عبور یا اطلاعات احراز هویت را با آزمودن مقادیر مختلف حدس بزند.

اما در MFA Fatigue، تمرکز اصلی بر جلب تأیید اشتباه از کاربر است.

در بسیاری از سناریوهای MFA Fatigue، مهاجم از قبل به مرحله عامل دوم رسیده است.

بنابراین، صرفاً محدودسازی حدس رمز عبور ممکن است برای مقابله با همه این حملات کافی نباشد.

تفاوت MFA Fatigue و Phishing

فیشینگ یا Phishing معمولاً شامل فریب کاربر برای افشای اطلاعات یا انجام یک اقدام ناامن است.

MFA Fatigue نیز ماهیتی فریبکارانه دارد، اما معمولاً بر درخواست‌های واقعی ایجادشده در سامانه احراز هویت متکی است.

این دو حمله می‌توانند با یکدیگر ترکیب شوند.

برای مثال، اطلاعات ورود ممکن است ابتدا در یک حادثه فیشینگ افشا شده باشند و سپس درخواست‌های تأیید غیرمجاز ایجاد شوند.

تفاوت MFA Fatigue و سرقت OTP

در سرقت OTP، هدف به دست آوردن رمز یک‌بارمصرفی است که کاربر دریافت یا تولید کرده است.

در MFA Fatigue، مهاجم ممکن است اصلاً نیازی به دانستن کد نداشته باشد و فقط به دنبال تأیید یک اعلان باشد.

به همین دلیل، ماهیت اقدامات دفاعی در این دو حالت یکسان نیست.

جدول مقایسه حملات

در بسیاری از حوادث، چند تکنیک به‌صورت هم‌زمان مشاهده می‌شوند. بنابراین، تحلیل امنیتی نباید صرفاً به یک عنوان حمله محدود شود.

نقش Push Notification در حمله MFA Fatigue

Push Notification یا اعلان فوری، یکی از روش‌های رایج اطلاع‌رسانی درخواست ورود به کاربر است.

استفاده از این قابلیت می‌تواند تجربه ورود را ساده‌تر کند؛ زیرا کاربر برای تأیید، همیشه نیازی به وارد کردن دستی کد ندارد.

اما همین سادگی در برخی پیاده‌سازی‌ها خطر ایجاد می‌کند.

مشکل تأیید با یک لمس

در مدل ساده Push، برنامه احراز هویت درخواست را نمایش می‌دهد و کاربر می‌تواند آن را بپذیرد.

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

به‌خصوص زمانی که کاربر در معرض اعلان‌های تکراری قرار داشته باشد.

چرا اعلان رسمی هم می‌تواند خطرناک باشد؟

اعلان ممکن است کاملاً واقعی باشد و از سرویس احراز هویت معتبر ارسال شود.

بااین‌حال، درخواست ورود مربوط به فعالیت شخص دیگری است.

به عبارت دیگر، مهاجم الزاماً اعلان را جعل نمی‌کند؛ بلکه تلاش می‌کند از مکانیسم قانونی احراز هویت سوءاستفاده کند.

آیا خاموش کردن اعلان‌ها راهکار مناسبی است؟

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

اگر درخواست‌های غیرمجاز همچنان ایجاد شوند، خطر امنیتی باقی می‌ماند.

راهکار مناسب، بررسی منشأ درخواست‌ها، امن‌سازی حساب و استفاده از روش احراز هویت مقاوم‌تر است.

Number Matching چیست و چگونه خطر MFA Fatigue را کاهش می‌دهد؟

Number Matching یا تطبیق عددی یکی از کنترل‌های مهم برای کاهش خطر تأیید اشتباه اعلان‌های MFA است.

در این روش، کاربر به‌جای فشردن ساده یک دکمه، باید مقدار مرتبط با نشست ورود را در برنامه احراز هویت وارد کند.

برای مثال، در یک ورود مجاز، عددی روی صفحه همان نشست نمایش داده می‌شود و کاربر آن را در برنامه Authenticator ثبت می‌کند.

این فرآیند کمک می‌کند تأیید درخواست به مشارکت فعال کاربر در نشست ورود وابسته باشد.

مزایای تأیید عددی

اولین مزیت، کاهش احتمال تأیید تصادفی است.

کاربر برای تکمیل ورود باید عدد مربوط به نشست خودش را مشاهده کند.

دومین مزیت، دشوارتر شدن سوءاستفاده از اعلان‌های تکراری است.

اگر کاربر اصلاً فرآیند ورود را آغاز نکرده باشد، معمولاً عدد مرتبط با نشست قانونی خود را نیز در اختیار ندارد.

آیا Number Matching حمله MFA Fatigue را کاملاً متوقف می‌کند؟

خیر.

تطبیق عددی می‌تواند خطر را به‌طور قابل توجهی کاهش دهد، اما یک راهکار کامل در برابر تمام روش‌های فریب نیست.

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

به همین دلیل، نباید عددی را که از طرف فرد دیگری درخواست شده وارد کرد.

تفاوت Number Matching و احراز هویت مقاوم در برابر فیشینگ

Number Matching به تأیید یک نشست کمک می‌کند، اما لزوماً تضمین نمی‌کند که عملیات به دامنه و سرویس واقعی موردنظر کاربر به‌صورت رمزنگاری‌شده متصل است.

در مقابل، فناوری‌هایی مانند WebAuthn و FIDO2 می‌توانند اعتبار احراز هویت را به سرویس مشخصی متصل کنند.

بنابراین، Number Matching یک بهبود امنیتی مهم برای Push MFA است، اما معادل Phishing-Resistant MFA محسوب نمی‌شود.

بهترین روش احراز هویت برای مقابله با MFA Fatigue چیست؟

برای کاهش اساسی خطر، بهتر است از روش‌هایی استفاده شود که تکمیل احراز هویت به یک تأیید ساده و مستقل از نشست وابسته نباشد.

استفاده از FIDO2

FIDO2 مجموعه‌ای از فناوری‌های احراز هویت مبتنی بر رمزنگاری کلید عمومی است.

در این روش، احراز هویت می‌تواند به هویت سرویس واقعی متصل شود.

این ویژگی مانع بسیاری از حملات فیشینگ می‌شود که در آن‌ها مهاجم تلاش می‌کند اطلاعات احراز هویت را از یک سایت جعلی دریافت کند.

استفاده از WebAuthn

WebAuthn یک استاندارد وب برای احراز هویت مبتنی بر اعتبارنامه‌های رمزنگاری‌شده است.

در پیاده‌سازی صحیح، اعتبارنامه به شناسه سرویس یا Relying Party وابسته می‌شود.

این وابستگی به کاهش خطر استفاده از اعتبارنامه در دامنه جعلی کمک می‌کند.

استفاده از Passkey

Passkey روشی برای ورود است که معمولاً بر فناوری FIDO2/WebAuthn متکی است.

کاربر می‌تواند با PIN یا تأیید بیومتریک دستگاه، عملیات احراز هویت را تکمیل کند.

در این روش، نیازی به دریافت درخواست‌های Push ساده و تأیید آن‌ها به شکل سنتی نیست.

البته امنیت نهایی به پیاده‌سازی سرویس، حفاظت دستگاه، مدیریت نشست و فرآیند بازیابی حساب نیز وابسته است.

استفاده از کلید امنیتی سخت‌افزاری

Security Key سخت‌افزاری یکی دیگر از گزینه‌های مناسب برای محافظت از حساب‌های حساس است.

در مدل‌های سازگار با FIDO2، عملیات احراز هویت از طریق تعامل با کلید و تأیید رمزنگاری‌شده انجام می‌شود.

این روش برای حساب‌های مدیریتی و کاربران دارای دسترسی حساس ارزش زیادی دارد.

مقایسه روش‌های احراز هویت

نکته مهم این است که نبود آسیب‌پذیری نسبت به Push Bombing به معنای امنیت کامل یک روش نیست.

برای مثال، کد TOTP ممکن است در برابر بمباران اعلان Push مقاوم باشد، اما همچنان در برابر فیشینگ بلادرنگ آسیب‌پذیر است.

چگونه سازمان‌ها از حمله MFA Fatigue جلوگیری کنند؟

مقابله سازمانی با این حمله نیازمند ترکیبی از کنترل‌های هویتی، نظارت امنیتی و آموزش کاربران است.

محدودسازی تعداد درخواست‌های MFA

سامانه احراز هویت باید امکان کنترل نرخ ایجاد درخواست را داشته باشد.

برای مثال، تکرار غیرعادی درخواست‌ها می‌تواند باعث اعمال محدودیت موقت یا الزام به بررسی امنیتی شود.

مقادیر مناسب باید متناسب با رفتار کاربران، نوع سرویس و خطر اختلال تعیین شوند.

محدودسازی بیش‌ازحد نیز ممکن است امکان ایجاد اختلال عمدی در ورود کاربران را فراهم کند.

استفاده از Conditional Access

Conditional Access یا دسترسی مشروط، به سازمان اجازه می‌دهد تصمیم ورود را براساس شرایط مختلف اتخاذ کند.

این شرایط ممکن است شامل موارد زیر باشند:

• وضعیت امنیتی دستگاه.
• سطح دسترسی حساب.
• موقعیت و نشانی شبکه.
• میزان ریسک ورود.
• نوع برنامه مقصد.
• شرایط نشست کاربری.

هدف این است که تمام درخواست‌های ورود صرفاً براساس تأیید یک اعلان ارزیابی نشوند.

محافظت از حساب‌های دارای دسترسی ویژه

حساب‌های مدیریتی مانند Global Administrator و سایر حساب‌های حساس باید کنترل‌های سخت‌گیرانه‌تری داشته باشند.

استفاده از احراز هویت مقاوم در برابر فیشینگ، تفکیک حساب‌های مدیریتی و مدیریت دسترسی ممتاز یا PAM از اقدامات مهم است.

فعال‌سازی گزارش درخواست مشکوک

بهتر است کاربران بتوانند درخواست‌های ناشناس را مستقیماً از برنامه احراز هویت گزارش کنند.

این گزارش‌ها باید به سامانه نظارت امنیتی متصل شوند تا بررسی حادثه سریع‌تر انجام شود.

پایش مداوم تلاش‌های ورود

ثبت لاگ‌های مربوط به درخواست‌های احراز هویت، رد شدن درخواست‌ها، انقضای آن‌ها و ورودهای موفق اهمیت زیادی دارد.

اطلاعات باید در قالبی مناسب برای تحلیل و همبستگی ذخیره شوند.

بازبینی روش‌های بازیابی حساب

فرآیندهای Self-Service Password Reset یا SSPR نیز باید بررسی شوند.

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

همچنین اضافه کردن عامل احراز هویت جدید نباید بدون کنترل هویتی مناسب امکان‌پذیر باشد.

کاهش وابستگی به تأییدهای مکرر

طراحی مناسب تجربه کاربری می‌تواند تعداد درخواست‌های غیرضروری احراز هویت را کاهش دهد.

البته کاهش تعداد درخواست‌ها نباید با طولانی کردن بی‌ضابطه نشست‌ها یا حذف احراز هویت برای عملیات حساس انجام شود.

هدف، ایجاد تعادل میان امنیت و تجربه کاربر است.

شناسایی حمله MFA Fatigue از طریق لاگ‌های امنیتی

لاگ‌های سامانه مدیریت هویت یکی از مهم‌ترین منابع تشخیص این حمله هستند.

در بسیاری از موارد، الگوی رویدادها اهمیت بیشتری از یک درخواست منفرد دارد.

تکرار درخواست برای یک حساب

اگر تعداد درخواست‌های MFA برای یک حساب در بازه کوتاهی افزایش پیدا کند، احتمال فعالیت غیرعادی وجود دارد.

البته این وضعیت می‌تواند ناشی از مشکل نرم‌افزاری یا تلاش واقعی کاربر نیز باشد.

بنابراین، تعداد درخواست‌ها باید با زمینه رویداد بررسی شود.

رد شدن متوالی درخواست‌ها

چندین درخواست ردشده برای یک حساب می‌تواند نشان دهد کاربر در حال رد تلاش‌های ورود ناشناس است.

اگر پس از این درخواست‌ها ناگهان یک تأیید موفق ثبت شود، بررسی دقیق‌تر ضروری است.

این الگو به‌تنهایی نفوذ را اثبات نمی‌کند، اما می‌تواند یک هشدار با اولویت بالا باشد.

ارتباط با نشانی‌های IP ناشناس

نشانی IP مرتبط با تلاش ورود باید با رفتار معمول حساب مقایسه شود.

ورود از شبکه یا موقعیت غیرمعمول می‌تواند به افزایش امتیاز ریسک کمک کند.

بااین‌حال، VPN، شبکه‌های سازمانی و تغییرات مسیریابی می‌توانند باعث تفاوت طبیعی در موقعیت ظاهری شوند.

اختلاف میان دستگاه و نشست

اگر درخواست‌های ورود از دستگاه یا محیطی ایجاد شوند که با رفتار شناخته‌شده کاربر سازگار نیست، احتمال سوءاستفاده افزایش می‌یابد.

بررسی شناسه دستگاه، وضعیت مدیریت‌شدگی و سابقه نشست‌ها می‌تواند مفید باشد.

درخواست‌های مشکوک در زمان‌های غیرعادی

زمان وقوع درخواست‌ها نیز یک شاخص تحلیلی است.

برای مثال، حجم غیرعادی اعلان‌ها خارج از ساعات فعالیت معمول می‌تواند نشانه‌ای برای بررسی باشد.

اما تحلیلگر نباید فرض کند که فعالیت خارج از ساعات اداری همیشه مخرب است.

طراحی قانون تشخیص MFA Fatigue در SIEM

SIEM یا Security Information and Event Management می‌تواند داده‌های سامانه‌های احراز هویت را جمع‌آوری و تحلیل کند.

هدف از طراحی قانون تشخیص، شناسایی الگوهای مهم با کمترین میزان هشدار غیرضروری است.

داده‌های موردنیاز

برای تحلیل مناسب، فیلدهای زیر می‌توانند مفید باشند:

• شناسه حساب کاربری.
• زمان درخواست احراز هویت.
• شناسه نشست یا Correlation ID.
• نتیجه درخواست MFA.
• روش احراز هویت مورد استفاده.
• نشانی IP و اطلاعات دستگاه.
• نام برنامه یا سرویس مقصد.
• نشانه‌های ریسک ورود.
• گزارش فعالیت مشکوک توسط کاربر.

در دسترس بودن این داده‌ها به ارائه‌دهنده هویت و سطح مجوزهای ثبت لاگ بستگی دارد.

نمونه سناریوی تشخیص دفاعی

فرض کنید یک سامانه در مدت کوتاهی چندین درخواست احراز هویت برای یک کاربر ثبت می‌کند.

بیشتر درخواست‌ها رد شده یا منقضی شده‌اند.

در ادامه، یک رویداد موفق از دستگاهی غیرمعمول مشاهده می‌شود.

در چنین شرایطی، SIEM می‌تواند هشدار ایجاد کند تا تیم امنیت رابطه میان رویدادها را بررسی کند.

هدف از این تحلیل، اثبات خودکار نفوذ نیست؛ بلکه شناسایی رفتاری است که به توجه امنیتی نیاز دارد.

اهمیت همبستگی رویدادها

بهتر است رویدادهای MFA با سایر اطلاعات امنیتی مقایسه شوند.

برای مثال، اگر هم‌زمان تغییر رمز عبور، ثبت دستگاه جدید یا ایجاد نشست ناشناس مشاهده شود، اولویت بررسی افزایش پیدا می‌کند.

جلوگیری از هشدارهای کاذب

قانون تشخیص باید پس از اجرا ارزیابی و تنظیم شود.

عوامل زیر می‌توانند باعث ایجاد هشدار غیرواقعی شوند:

• اختلال در برنامه احراز هویت.
• تکرار طبیعی ورود توسط کاربر.
• مشکلات شبکه.
• تغییر دستگاه.
• فرآیندهای مجاز بازیابی حساب.
• فعالیت‌های تست امنیتی دارای مجوز.

تنظیم قانون صرفاً براساس تعداد درخواست‌ها، بدون توجه به زمینه، ممکن است باعث افزایش False Positive شود.

بررسی MFA Fatigue در Microsoft Entra ID

Microsoft Entra ID یکی از سامانه‌های مدیریت هویت سازمانی است که قابلیت‌های متنوعی برای احراز هویت و کنترل دسترسی فراهم می‌کند.

در محیط‌هایی که از Microsoft Authenticator استفاده می‌شود، تنظیمات احراز هویت نقش مهمی در کاهش خطر حملات Push Bombing دارند.

استفاده از Number Matching

Microsoft Authenticator از تطبیق عددی برای درخواست‌های Push پشتیبانی می‌کند و این قابلیت برای این نوع اعلان‌ها فعال است.

کاربر باید مقدار مرتبط با نشست ورود را در برنامه ثبت کند.

این روش نسبت به تأیید ساده با یک دکمه، مقاومت بیشتری در برابر پذیرش تصادفی درخواست دارد.

نمایش اطلاعات تکمیلی

بسته به پیکربندی، برنامه می‌تواند اطلاعاتی مانند نام برنامه و موقعیت تقریبی درخواست را نمایش دهد.

این اطلاعات به کاربر کمک می‌کنند درخواست را بهتر ارزیابی کند.

البته اعتبار این داده‌ها باید با توجه به محدودیت‌های مکان‌یابی و شرایط شبکه سنجیده شود.

گزارش فعالیت مشکوک

قابلیت Report Suspicious Activity می‌تواند امکان اعلام درخواست غیرمنتظره را در اختیار کاربر قرار دهد.

این رویداد ممکن است در سیاست‌های ارزیابی ریسک حساب مورد استفاده قرار گیرد.

فعال‌سازی و رفتار دقیق آن به تنظیمات محیط سازمانی وابسته است.

سیاست‌های دسترسی مشروط

سازمان‌ها می‌توانند از Conditional Access برای محدودسازی ورود از شرایط پرخطر استفاده کنند.

برای حساب‌های حساس، بهتر است احراز هویت مقاوم در برابر فیشینگ و دستگاه‌های مورد اعتماد در اولویت قرار گیرند.

حمله MFA Fatigue در Okta و Duo

خطر حملات مبتنی بر خستگی اعلان به یک ارائه‌دهنده خاص محدود نیست.

هر سامانه‌ای که از تأیید مبتنی بر Push استفاده کند، باید این نوع تهدید را در طراحی امنیتی در نظر بگیرد.

ملاحظات امنیتی در Okta

در محیط‌های مبتنی بر Okta، سازمان باید روش‌های مجاز احراز هویت و سیاست‌های دسترسی را بررسی کند.

استفاده از روش‌های مقاوم در برابر فیشینگ، ارزیابی ریسک ورود و محدودسازی دسترسی به برنامه‌های حساس از اقدامات قابل بررسی هستند.

همچنین ثبت و تحلیل رویدادهای ورود و تغییر عوامل احراز هویت اهمیت دارد.

ملاحظات امنیتی در Cisco Duo

در سامانه‌های مبتنی بر Duo نیز باید از قابلیت‌های محافظتی مناسب در برابر درخواست‌های مشکوک استفاده شود.

بسته به نسخه محصول و تنظیمات موجود، امکاناتی مانند تأیید قوی‌تر نشست، سیاست‌های دسترسی و تحلیل رفتار ورود می‌توانند در کاهش خطر مؤثر باشند.

اصل مشترک در همه سامانه‌ها

نام برند به‌تنهایی تعیین‌کننده سطح امنیت نیست.

مهم‌ترین عامل، نحوه پیکربندی و انتخاب روش احراز هویت است.

حتی یک پلتفرم پیشرفته نیز در صورت استفاده از سیاست‌های ضعیف و نبود نظارت می‌تواند در معرض سوءاستفاده قرار گیرد.

نقش MFA Fatigue در نفوذ به حساب‌های سازمانی

حساب‌های سازمانی اغلب به چندین سرویس مختلف متصل هستند.

یک حساب کاربری ممکن است از طریق Single Sign-On یا SSO برای ورود به ایمیل، فضای ذخیره‌سازی، ابزارهای ارتباطی و برنامه‌های تجاری استفاده شود.

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

خطر دسترسی به ایمیل سازمانی

اگر حساب سازمانی به سرویس ایمیل متصل باشد، مهاجم ممکن است بتواند اطلاعات حساس مکاتبات را مشاهده کند.

بسته به مجوزها، خطر سوءاستفاده از هویت کاربر یا دسترسی به اطلاعات داخلی نیز وجود دارد.

خطر دسترسی به فایل‌ها

سامانه‌های ذخیره‌سازی سازمانی ممکن است شامل قراردادها، گزارش‌ها و اسناد محرمانه باشند.

در چنین شرایطی، یک نشست غیرمجاز می‌تواند خطر افشای داده‌ها را افزایش دهد.

خطر حساب‌های مدیریتی

حساب‌های دارای دسترسی ممتاز اهمیت بیشتری دارند.

این حساب‌ها ممکن است مجوز تغییر تنظیمات امنیتی، مدیریت کاربران یا دسترسی به سامانه‌های حساس را داشته باشند.

به همین دلیل، استفاده از Push MFA ساده برای حساب‌های مدیریتی انتخاب مناسبی نیست.

خطر تداوم دسترسی

در بعضی حوادث، مهاجم ممکن است پس از ورود تلاش کند امکان دسترسی مجدد را حفظ کند.

برای تشخیص این وضعیت، بررسی دستگاه‌های ثبت‌شده، عوامل احراز هویت، نشست‌های فعال و تغییرات مجوز ضروری است.

سناریوی واقعی‌نما از حمله MFA Fatigue

برای روشن شدن موضوع، یک مثال فرضی را بررسی می‌کنیم.

این مثال صرفاً برای شناخت خطر و اقدامات دفاعی طراحی شده است.

وضعیت اولیه

یک شرکت خدماتی از احراز هویت چندعاملی برای ورود کارکنان به حساب‌های سازمانی استفاده می‌کند.

کارمند موردنظر از نرم‌افزار Authenticator روی تلفن همراه خود استفاده می‌کند.

در سیستم، درخواست‌های تأیید ورود به شکل اعلان فوری نمایش داده می‌شوند.

آغاز فعالیت مشکوک

در یک بازه زمانی غیرمعمول، کارمند چندین درخواست تأیید دریافت می‌کند.

او در آن زمان قصد ورود به حسابش را ندارد.

ابتدا درخواست‌ها را رد می‌کند، اما اعلان‌های دیگری ظاهر می‌شوند.

واکنش صحیح کارمند

کارمند هیچ درخواستی را تأیید نمی‌کند.

سپس از مسیر رسمی با مسئول امنیت تماس می‌گیرد.

تیم امنیت، لاگ‌های احراز هویت را بررسی می‌کند و متوجه تکرار درخواست‌های غیرعادی می‌شود.

اقدامات دفاعی سازمان

سازمان براساس شواهد، حساب را ارزیابی می‌کند.

نشست‌های مشکوک بررسی می‌شوند و در صورت ضرورت اقدامات حفاظتی مناسب اعمال می‌شوند.

همچنین تنظیمات MFA و سیاست‌های دسترسی بازبینی می‌شوند.

نتیجه سناریو

این مثال نشان می‌دهد که آموزش کاربر و وجود فرآیند پاسخ به حادثه می‌تواند از موفقیت حمله جلوگیری کند.

بااین‌حال، بهترین دفاع نباید صرفاً به دقت کاربر وابسته باشد.

سازمان باید با استفاده از فناوری‌های مقاوم‌تر، احتمال قرار گرفتن کاربر در چنین وضعیت‌هایی را کاهش دهد.

حمله MFA Fatigue چه ارتباطی با امنیت وردپرس دارد؟

بسیاری از مدیران سایت‌های وردپرسی برای افزایش امنیت ورود از افزونه‌های 2FA یا سرویس‌های مدیریت هویت استفاده می‌کنند.

این ابزارها نقش مهمی در محافظت از حساب‌های مدیریتی دارند.

اما انتخاب روش احراز هویت اهمیت زیادی دارد.

آیا وردپرس به‌طور پیش‌فرض در معرض MFA Fatigue است؟

هسته وردپرس به‌صورت پیش‌فرض یک سامانه Push MFA عمومی برای ورود مدیران ارائه نمی‌کند.

بنابراین، وجود چنین خطری به افزونه احراز هویت، سرویس SSO یا سامانه خارجی متصل به سایت بستگی دارد.

اگر ورود مدیر سایت از طریق یک ارائه‌دهنده هویت مبتنی بر Push انجام شود، خطر حمله MFA Fatigue می‌تواند مطرح باشد.

استفاده از افزونه‌های احراز هویت

مدیران سایت باید اعتبار افزونه، روش‌های پشتیبانی‌شده و وضعیت به‌روزرسانی آن را بررسی کنند.

وجود برچسب 2FA یا MFA به‌تنهایی نشان‌دهنده مقاومت در برابر حملات مدرن نیست.

امنیت حساب مدیر وردپرس

برای حساب‌های حساس، استفاده از روش‌های احراز هویت مقاوم در برابر فیشینگ، در صورت پشتیبانی سامانه، می‌تواند انتخاب مناسبی باشد.

همچنین لازم است رمزهای عبور یکتا، حداقل سطح دسترسی و نظارت بر ورودها رعایت شوند.

نقش WAF

WAF یا Web Application Firewall می‌تواند در مقابله با برخی درخواست‌های مخرب و سوءاستفاده از مسیرهای وب نقش داشته باشد.

اما WAF به‌تنهایی نمی‌تواند تمام حملات MFA Fatigue را متوقف کند؛ به‌ویژه زمانی که اعلان‌ها توسط یک ارائه‌دهنده هویت خارجی تولید می‌شوند.

بنابراین، امنیت وردپرس و امنیت سامانه مدیریت هویت باید به‌صورت مکمل بررسی شوند.

آیا MFA Fatigue می‌تواند به دور زدن کامل MFA منجر شود؟

پاسخ به این پرسش به نوع پیاده‌سازی بستگی دارد.

در یک سیستم Push ساده، اگر کاربر درخواست غیرمجاز را تأیید کند و کنترل دیگری مانع نشود، ممکن است مهاجم فرآیند ورود را تکمیل کند.

اما این وضعیت به معنای شکسته شدن رمزنگاری MFA نیست.

عامل دوم از نظر فنی همچنان کار کرده است؛ مشکل این است که کاربر اشتباهاً اجازه یک درخواست غیرمجاز را صادر کرده است.

چرا این تمایز مهم است؟

اگر سازمان تصور کند فناوری رمزنگاری عامل دوم شکسته شده، ممکن است راهکار دفاعی نامناسبی انتخاب کند.

درحالی‌که مشکل اصلی می‌تواند به طراحی تعامل کاربر، نبود تطبیق نشست یا ضعف در سیاست‌های دسترسی مربوط باشد.

آیا تمام MFAها قابل دور زدن هستند؟

روش‌های احراز هویت تهدیدها و محدودیت‌های متفاوتی دارند.

برای مثال، Passkey مبتنی بر WebAuthn می‌تواند در برابر فیشینگ مقاومت بالایی داشته باشد، اما امنیت نشست پس از ورود و سلامت دستگاه همچنان اهمیت دارند.

بنابراین، هیچ راهکار امنیتی نباید بدون در نظر گرفتن سایر لایه‌های دفاعی، تضمین‌کننده امنیت مطلق معرفی شود.

نقش آموزش امنیتی در جلوگیری از MFA Fatigue

آموزش کارکنان می‌تواند احتمال موفقیت حملات مبتنی بر مهندسی اجتماعی را کاهش دهد.

بااین‌حال، آموزش نباید جایگزین کنترل‌های فنی مناسب شود.

قانون اصلی برای کاربران

کاربر فقط باید درخواست احراز هویتی را تأیید کند که خودش فرآیند ورود مربوط به آن را آغاز کرده است.

اگر درخواست غیرمنتظره باشد، حتی در صورت نمایش نام یک سرویس معتبر، نباید بدون بررسی پذیرفته شود.

شناخت تماس‌های جعلی پشتیبانی

کارکنان باید بدانند که تماس‌گیرنده ناشناس ممکن است خود را مسئول فناوری اطلاعات معرفی کند.

برای تأیید درخواست‌های امنیتی، باید از کانال رسمی سازمان استفاده شود.

تمرین واکنش به حادثه

سازمان می‌تواند در چارچوب مجوزهای داخلی، تمرین‌های آموزشی کنترل‌شده برگزار کند.

هدف این تمرین‌ها باید افزایش آگاهی و بررسی فرآیند گزارش‌دهی باشد.

تمرین نباید با ایجاد مزاحمت گسترده، اختلال در خدمات یا فشار روانی غیرضروری همراه شود.

ایجاد فرهنگ گزارش‌دهی

کارکنان باید بتوانند بدون ترس از سرزنش، دریافت درخواست مشکوک یا تأیید اشتباه را سریع گزارش کنند.

تأخیر در گزارش ممکن است فرصت بررسی و مهار حادثه را کاهش دهد.

چک‌لیست دفاعی مقابله با حمله MFA Fatigue

برای مدیران امنیت، بررسی دوره‌ای کنترل‌های زیر می‌تواند مفید باشد.

چک‌لیست کاربران

• درخواست ورود غیرمنتظره را تأیید نکنید.
• درخواست‌های تکراری را به‌عنوان رفتار عادی تلقی نکنید.
• برای متوقف کردن اعلان‌ها، گزینه Approve را انتخاب نکنید.
• درخواست مشکوک را از طریق مسیر رسمی گزارش دهید.
• رمز عبور حساب را در صورت احتمال افشا تغییر دهید.
• نشست‌ها و دستگاه‌های متصل را بررسی کنید.
• از روش‌های احراز هویت مقاوم در برابر فیشینگ استفاده کنید.
• کدها و اطلاعات احراز هویت را در اختیار تماس‌گیرندگان ناشناس قرار ندهید.

چک‌لیست مدیران سیستم

• سیاست‌های MFA را به‌صورت دوره‌ای بازبینی کنید.
• استفاده از Push MFA ساده را در حساب‌های حساس کاهش دهید.
• روش‌های FIDO2 و Passkey را در اولویت قرار دهید.
• محدودسازی نرخ درخواست‌های احراز هویت را بررسی کنید.
• هشدارهای مربوط به تکرار غیرعادی MFA ایجاد کنید.
• قابلیت گزارش فعالیت مشکوک را فعال کنید.
• سامانه‌های مدیریت هویت را به SIEM متصل کنید.
• وضعیت امنیتی دستگاه و ریسک ورود را ارزیابی کنید.
• فرآیند بازیابی حساب را ایمن کنید.
• نشست‌های غیرمجاز و تغییرات عوامل احراز هویت را پایش کنید.
• برنامه مشخصی برای پاسخ به حوادث هویتی داشته باشید.

اجرای این اقدامات باید با توجه به امکانات ارائه‌دهنده هویت و سیاست‌های امنیتی سازمان انجام شود.

اشتباهات رایج در مقابله با MFA Fatigue Attack

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

تصور اینکه هر اعلان Authenticator معتبر است

برنامه احراز هویت ممکن است رسمی باشد، اما درخواست مربوط به فعالیت غیرمجاز باشد.

کاربر باید منشأ درخواست را بررسی کند.

تأیید درخواست برای متوقف کردن مزاحمت

این دقیقاً همان رفتاری است که مهاجم به دنبال آن است.

هیچ درخواست غیرمنتظره‌ای نباید صرفاً برای پایان دادن به اعلان‌های مکرر پذیرفته شود.

اتکا به رمز عبور قوی

رمز عبور قوی ضروری است، اما اگر اطلاعات ورود از طریق فیشینگ یا روش‌های دیگر افشا شوند، کنترل‌های اضافی اهمیت پیدا می‌کنند.

بنابراین، سیاست امنیت حساب نباید فقط بر پیچیدگی رمز عبور متمرکز باشد.

تصور اینکه Number Matching همه تهدیدها را حذف می‌کند

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

برای حساب‌های حساس، احراز هویت مقاوم در برابر فیشینگ انتخاب مناسب‌تری است.

نادیده گرفتن درخواست‌های ردشده

رد شدن درخواست‌های مشکوک نشانه خوبی است، اما به معنای پایان خطر نیست.

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

تغییر رمز عبور بدون بررسی نشست‌ها

اگر ورود غیرمجاز قبلاً موفق شده باشد، ممکن است نشست یا توکن معتبری ایجاد شده باشد.

در چنین شرایطی، باید وضعیت نشست‌ها و اقدامات انجام‌شده در حساب نیز بررسی شود.

فعال‌سازی MFA بدون بازبینی تنظیمات

استفاده از MFA به‌تنهایی کافی نیست.

سازمان باید روش‌های مجاز، سیاست‌های بازیابی، محدودیت‌ها و نحوه مدیریت دستگاه‌های احراز هویت را بررسی کند.

برنامه پاسخ به حادثه MFA Fatigue برای تیم‌های امنیتی

داشتن یک Incident Response Plan مشخص می‌تواند زمان تشخیص و مهار حادثه را کاهش دهد.

این برنامه باید متناسب با سامانه مدیریت هویت و سطح حساسیت حساب‌ها تنظیم شود.

مرحله اول: دریافت و اعتبارسنجی هشدار

هشدار ممکن است از گزارش کاربر، SIEM یا سامانه مدیریت هویت دریافت شود.

تیم امنیت باید بررسی کند آیا رویداد واقعاً غیرعادی است یا با فرآیند مجاز سازمان ارتباط دارد.

مرحله دوم: بررسی احتمال افشای اطلاعات ورود

در صورت مشاهده درخواست‌های غیرمجاز، باید منشأ تلاش‌های ورود بررسی شود.

اگر شواهد نشان‌دهنده خطر افشای رمز عبور باشند، اقدامات حفاظتی مناسب باید اجرا شوند.

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

بسته به شدت حادثه، ممکن است محدودسازی موقت ورود، تغییر اطلاعات احراز هویت یا خاتمه نشست‌های مشکوک ضرورت پیدا کند.

این اقدامات باید از مسیرهای مدیریتی معتبر انجام شوند.

مرحله چهارم: بررسی فعالیت‌های پس از ورود

اگر ورود موفقی مشاهده شده باشد، تیم امنیت باید بررسی کند چه اقداماتی در حساب رخ داده‌اند.

تغییرات عوامل MFA، نشست‌های جدید، دسترسی به داده‌ها و تغییر مجوزها از موارد مهم هستند.

مرحله پنجم: بازیابی امن حساب

بازیابی باید از طریق فرآیند هویت‌سنجی قابل اعتماد انجام شود.

اضافه کردن عامل احراز هویت جدید یا بازگرداندن دسترسی نباید صرفاً براساس تماس یا درخواست تأییدنشده صورت گیرد.

مرحله ششم: اصلاح سیاست‌های امنیتی

پس از مهار حادثه، لازم است علت امکان ایجاد درخواست‌های مکرر بررسی شود.

اصلاح سیاست‌های MFA، فعال‌سازی کنترل‌های مقاوم‌تر و بهبود قوانین تشخیص از نتایج مورد انتظار این مرحله هستند.

مرحله هفتم: مستندسازی

ثبت زمان رویدادها، اقدامات انجام‌شده و یافته‌های نهایی برای تحلیل‌های بعدی اهمیت دارد.

مستندسازی کمک می‌کند سازمان در مواجهه با رویدادهای مشابه، تصمیم‌های دقیق‌تری بگیرد.

معیارهای ارزیابی امنیت در برابر MFA Fatigue

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

تعداد درخواست‌های غیرمنتظره

روند تغییر درخواست‌های گزارش‌شده توسط کاربران می‌تواند به شناخت وضعیت کمک کند.

البته افزایش تعداد گزارش‌ها ممکن است ناشی از بهبود آگاهی و گزارش‌دهی کاربران نیز باشد.

زمان شناسایی حادثه

فاصله میان نخستین درخواست مشکوک و شناسایی آن توسط سامانه نظارتی، شاخص مهمی است.

کاهش این زمان می‌تواند فرصت پاسخ را افزایش دهد.

درصد استفاده از MFA مقاوم در برابر فیشینگ

سازمان می‌تواند بررسی کند چه سهمی از حساب‌های حساس با روش‌هایی مانند FIDO2 محافظت می‌شوند.

این شاخص برای برنامه‌ریزی مهاجرت از روش‌های ضعیف‌تر مفید است.

کیفیت هشدارهای SIEM

تعداد زیاد هشدار به‌تنهایی نشان‌دهنده عملکرد بهتر نیست.

باید میزان هشدارهای معتبر و هشدارهای کاذب ارزیابی شود.

زمان مهار حساب مشکوک

مدت‌زمان لازم برای بررسی، محدودسازی دسترسی و بازگرداندن امن حساب نیز می‌تواند به‌عنوان شاخص عملیاتی ثبت شود.

وضعیت آموزش کاربران

آگاهی کارکنان درباره رد درخواست‌های غیرمنتظره و مسیر گزارش حادثه باید به‌صورت دوره‌ای بررسی شود.

هدف از این ارزیابی، بهبود فرآیندهاست؛ نه سرزنش کاربران.

آیا هوش مصنوعی می‌تواند MFA Fatigue را شناسایی کند؟

هوش مصنوعی و یادگیری ماشین می‌توانند در تحلیل الگوهای غیرعادی احراز هویت نقش داشته باشند.

برای مثال، سامانه تحلیلی ممکن است تعداد درخواست‌ها، زمان‌بندی، مشخصات دستگاه و سابقه ورود کاربر را بررسی کند.

تشخیص رفتار غیرعادی

مدل‌های Anomaly Detection می‌توانند تغییرات محسوس نسبت به الگوی معمول ورود را مشخص کنند.

برای مثال، افزایش ناگهانی درخواست‌های تأیید برای حسابی که معمولاً فعالیت محدودی دارد، می‌تواند نیازمند بررسی باشد.

تحلیل هم‌زمان چند شاخص

روش‌های تحلیلی پیشرفته ممکن است چند ویژگی را در کنار یکدیگر ارزیابی کنند.

این ویژگی‌ها می‌توانند شامل نشانی شبکه، سابقه دستگاه، زمان ورود و تعداد درخواست‌های ردشده باشند.

محدودیت‌های استفاده از هوش مصنوعی

مدل‌های تحلیلی ممکن است خطا داشته باشند.

تغییر محل کار، سفر، تغییر دستگاه یا اختلال شبکه می‌توانند باعث ایجاد رفتار غیرعادی ولی مجاز شوند.

بنابراین، خروجی مدل باید با سیاست‌های امنیتی و شواهد تکمیلی بررسی شود.

اهمیت حفاظت از اطلاعات کاربران

لاگ‌های احراز هویت ممکن است شامل اطلاعات شخصی و داده‌های حساس سازمانی باشند.

انتقال این داده‌ها به سامانه‌های تحلیل خارجی باید براساس مجوزها، قوانین حریم خصوصی و سیاست نگهداری اطلاعات انجام شود.

آینده امنیت MFA و کاهش حملات مبتنی بر خستگی کاربران

روند توسعه فناوری‌های احراز هویت به سمت کاهش وابستگی به رمز عبور و تأییدهای ساده حرکت کرده است.

یکی از اهداف مهم، کاهش امکان فریب کاربران در فرآیند ورود است.

گسترش Passkey

Passkey می‌تواند فرآیند ورود را ساده‌تر کند و درعین‌حال از سازوکارهای رمزنگاری مقاوم در برابر فیشینگ بهره ببرد.

در بسیاری از پیاده‌سازی‌ها، کاربر به‌جای وارد کردن رمز و تأیید اعلان Push، با دستگاه و اعتبارنامه ثبت‌شده احراز هویت می‌شود.

افزایش اهمیت Device Trust

بررسی وضعیت امنیتی دستگاه می‌تواند نقش مهمی در سیاست‌های دسترسی داشته باشد.

در محیط‌های سازمانی، استفاده از دستگاه‌های مدیریت‌شده می‌تواند به کاهش خطر دسترسی غیرمجاز کمک کند.

احراز هویت مبتنی بر ریسک

Risk-Based Authentication تلاش می‌کند شرایط هر ورود را ارزیابی کند.

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

کاهش اتکا به تصمیم‌گیری لحظه‌ای کاربر

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

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

سؤالات متداول درباره MFA Fatigue Attack

MFA Fatigue Attack چیست؟

MFA Fatigue Attack نوعی حمله مهندسی اجتماعی است که مهاجم در آن با ایجاد درخواست‌های مکرر احراز هویت چندعاملی، تلاش می‌کند کاربر را به تأیید یک ورود غیرمجاز وادار کند. این حمله بیشتر با نام Push Bombing نیز شناخته می‌شود.

آیا دریافت اعلان‌های مکرر MFA به معنای هک شدن حساب است؟

خیر، لزوماً به معنای نفوذ موفق نیست. اما می‌تواند نشانه تلاش برای ورود غیرمجاز، افشای اطلاعات ورود یا سوءاستفاده از فرآیند احراز هویت باشد و باید بررسی شود.

اگر درخواست MFA ناشناس دریافت کنیم چه کنیم؟

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

آیا رد کردن درخواست MFA برای جلوگیری از حمله کافی است؟

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

آیا حمله MFA Fatigue بدون دانستن رمز عبور امکان‌پذیر است؟

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

آیا Google Authenticator در برابر MFA Fatigue آسیب‌پذیر است؟

باید میان کدهای TOTP و اعلان‌های Push تفاوت گذاشت. کدهای زمان‌دار Google Authenticator به شکل سنتی با تأیید ساده اعلان Push کار نمی‌کنند؛ بنابراین حمله کلاسیک Push Bombing مستقیماً به همان صورت بر آن‌ها اعمال نمی‌شود. اما کدهای TOTP در برابر همه روش‌های فیشینگ مقاوم نیستند.

آیا Microsoft Authenticator از MFA Fatigue جلوگیری می‌کند؟

Microsoft Authenticator قابلیت‌هایی مانند Number Matching و گزارش فعالیت مشکوک دارد که می‌توانند خطر را کاهش دهند. بااین‌حال، امنیت نهایی به سیاست‌های سازمان و روش احراز هویت انتخاب‌شده وابسته است.

آیا Number Matching امنیت کامل ایجاد می‌کند؟

خیر. Number Matching احتمال تأیید اشتباه را کاهش می‌دهد، اما تمام روش‌های مهندسی اجتماعی یا حملات فیشینگ را متوقف نمی‌کند. روش‌های مبتنی بر FIDO2 مقاومت قوی‌تری در برابر فیشینگ فراهم می‌کنند.

آیا Passkey در برابر MFA Fatigue مقاوم است؟

Passkey مبتنی بر FIDO2/WebAuthn با پیاده‌سازی صحیح، وابسته به تأیید Push ساده نیست و در برابر بسیاری از حملات فیشینگ نیز مقاومت دارد. البته امنیت دستگاه و نشست همچنان اهمیت دارد.

آیا MFA Fatigue همان Brute Force است؟

خیر. Brute Force بر آزمودن اطلاعات احراز هویت تمرکز دارد، اما MFA Fatigue تلاش می‌کند کاربر را به پذیرش درخواست ورود غیرمجاز وادار کند. این دو رفتار ممکن است در یک حادثه با یکدیگر ترکیب شوند.

آیا VPN می‌تواند جلوی MFA Fatigue را بگیرد؟

VPN به‌تنهایی مانع این حمله نمی‌شود. ممکن است بخشی از سیاست‌های دسترسی سازمان بر شبکه‌های مجاز متکی باشد، اما جلوگیری از حمله نیازمند کنترل‌های احراز هویت و نظارت مناسب است.

آیا حمله MFA Bombing روی گوشی اندروید و آیفون انجام می‌شود؟

این حمله به سیستم‌عامل خاصی محدود نیست. اگر برنامه احراز هویت روی دستگاه از تأیید مبتنی بر Push استفاده کند، نوع دستگاه به‌تنهایی مانع سوءاستفاده نخواهد بود.

آیا تغییر رمز عبور حمله را متوقف می‌کند؟

تغییر رمز عبور در صورت افشای اطلاعات ورود اقدام مهمی است، اما ممکن است نشست‌های فعال یا مشکلات دیگر حساب را برطرف نکند. بررسی نشست‌ها، دستگاه‌ها و روش‌های احراز هویت نیز ضرورت دارد.

آیا MFA Fatigue می‌تواند باعث سرقت اطلاعات سازمانی شود؟

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

آیا MFA Fatigue در وردپرس هم اتفاق می‌افتد؟

اگر ورود وردپرس از طریق افزونه یا سامانه هویت خارجی دارای Push MFA انجام شود، این تهدید می‌تواند مطرح باشد. اما هسته وردپرس به‌صورت پیش‌فرض چنین فرآیند Push MFA عمومی‌ای ندارد.

بهترین راه جلوگیری از حمله MFA Fatigue چیست؟

استفاده از احراز هویت مقاوم در برابر فیشینگ مانند FIDO2 و Passkey، محدودسازی درخواست‌های غیرعادی، فعال‌سازی سیاست‌های دسترسی مشروط و آموزش کاربران از مؤثرترین راهکارهای دفاعی هستند.

جمع‌بندی: چگونه از حمله MFA Fatigue جلوگیری کنیم؟

MFA Fatigue Attack نشان می‌دهد که امنیت حساب‌های کاربری فقط به تعداد مراحل احراز هویت وابسته نیست؛ بلکه نحوه طراحی آن مراحل نیز اهمیت دارد.

در این حمله، مهاجم با استفاده از درخواست‌های مکرر تأیید ورود تلاش می‌کند کاربر را خسته یا سردرگم کند تا یک درخواست غیرمجاز را بپذیرد.

خطر اصلی زمانی ایجاد می‌شود که سامانه برای تکمیل ورود به یک تأیید ساده وابسته باشد و کنترل‌های مکمل کافی وجود نداشته باشند.

برای کاربران، مهم‌ترین اقدام این است که هیچ درخواست احراز هویتی را بدون آغاز کردن فرآیند ورود تأیید نکنند.

دریافت درخواست‌های مکرر باید به‌عنوان یک نشانه امنیتی بررسی شود، نه صرفاً مزاحمت نرم‌افزاری.

برای سازمان‌ها، استفاده از Number Matching، محدودسازی درخواست‌ها، بررسی ریسک ورود و اتصال لاگ‌ها به SIEM می‌تواند خطر را کاهش دهد.

بااین‌حال، برای حساب‌های حساس بهتر است مهاجرت به فناوری‌های مقاوم در برابر فیشینگ مانند FIDO2، WebAuthn و Passkey در اولویت قرار گیرد.

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

مهم‌ترین درس MFA Fatigue این است که نباید امنیت حساب را صرفاً به تصمیم‌گیری لحظه‌ای کاربر در برابر اعلان‌های تکراری وابسته کرد.

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

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