با افزایش آگاهی نسبت به آسیب‌پذیری روش‌های احراز هویت چندمرحله‌ای (MFA) در برابر فیشینگ، روش‌های احراز هویت بدون رمز عبور مبتنی بر FIDO2 (مانند کلیدهای عبور یا passkeys مثل YubiKeys، Okta FastPass و Windows Hello) به‌طور فزاینده‌ای توصیه می‌شوند.
چالش‌های فیشینگ در MFA سنتی
رایج‌ترین روش‌های MFA، مانند کدهای SMS، اعلان‌های پاپ آپ(push notifications) و کدهای یک‌بارمصرف مبتنی بر اپلیکیشن، به‌طور معمول با کیت‌های فیشینگ مدرن مهاجم در میانه ارتباط (AitM) دور زده می‌شوند. این کیت‌ها با رهگیری نشست احراز هویت‌شده‌ای که کاربر با وارد کردن رمز عبور و تکمیل MFA ایجاد می‌کند، عمل می‌کنند. وب‌سایت فیشینگ پیام‌ها را بین کاربر و وب‌سایت واقعی منتقل می‌کند و بدین ترتیب نشست را سرقت می‌کند.
مزیت کلیدهای عبور
در مقابل، احراز هویت مبتنی بر کلیدهای عبور(passkeys) در برابر فیشینگ مقاوم است؛ زیرا این کلیدها به دامنه‌ای خاص متصل‌اند. استفاده از کلید عبور برای microsoft.com در یک سایت فیشینگ مانند phishing.com، حتی با استفاده از کیت AitM، مقدار صحیحی برای گذراندن احراز هویت تولید نمی‌کند. با افزایش محبوبیت کلیدهای عبور، مهاجمان تکنیک‌هایی برای تضعیف یا دور زدن فرآیند احراز هویت توسعه داده‌اند تا آن را در برابر حملات فیشینگ آسیب‌پذیر کنند.
در ادامه چند تکنیک که مهاجمان برای دور زدن کلید عبور استفاده می‌کنند، آمده است.
حملات تضعیف احراز هویت
حملات کاهش سطح احراز هویت (downgrade attack) رایج‌ترین روش برای دور زدن MFA مقاوم به فیشینگ است. کیت‌های AitM مجرمانه، مانند Evilginx، قابلیت تضعیف MFA را دارند. در این حملات، مهاجم پیام‌ها را به‌طور کامل منتقل نمی‌کند، بلکه برخی را تغییر می‌دهد. برای مثال، اپلیکیشن ممکن است از کاربر بخواهد بین کلید عبور یا کد تأیید پشتیبان انتخاب کند؛ اما وب‌سایت فیشینگ این گزینه را به «استفاده از کد تأیید پشتیبان» محدود می‌کند و امکان استفاده از کلید عبور امن را حذف می‌کند.
این روش برای حساب‌هایی که از ورود SSO به‌عنوان روش پیش‌فرض استفاده می‌کنند نیز اعمال می‌شود، جایی که کیت فیشینگ گزینه نام کاربری و رمز عبور پشتیبان را انتخاب می‌کند. وجود روش‌های پشتیبان کمتر امن، حتی در حضور روش‌های مقاوم به فیشینگ، حساب را آسیب‌پذیر می‌کند.
فیشینگ کد دستگاه
مهاجمان برای دور زدن احراز هویت مقاوم به فیشینگ، از حملات فیشینگ کد دستگاه(Device Code Phishing) استفاده می‌کنند که از جریان‌های احراز هویت جایگزین برای دستگاه‌هایی که از کلیدهای عبور پشتیبانی نمی‌کنند (مانند دستگاه‌های بدون مرورگر یا با قابلیت ورودی محدود) سوءاستفاده می‌کنند.
در این روش، کاربر کدی منحصربه‌فرد دریافت کرده و به وب‌سایتی در مرورگر دستگاهی دیگر هدایت می‌شود تا کد را وارد کند و دستگاه را تأیید نماید. مهاجم با فریب کاربر برای وارد کردن کد ارائه‌شده توسط او در وب‌سایت ارائه‌دهنده احراز هویت، به حساب دسترسی پیدا می‌کند. این حمله از URLهای معتبر استفاده می‌کند و نیازی به رضایت صریح برای مجوزهای اضافی ندارد. این تکنیک در کمپین‌های اخیر، از جمله حملات تحت حمایت روسیه به حساب‌های M365، مشاهده شده است.
فیشینگ با ترفند درخواست تایید
فیشینگ با ترفند درخواست تایید (Consent Phishing) یکی از اولین تکنیک‌های حملات SaaS است که اخیرا افزایش یافته است. OAuth به کاربران امکان می‌دهد تا به برنامه‌های شخص ثالث اجازه دسترسی به داده‌هایشان را بدهند. در این روش، مهاجمان با فریب کاربران برای اعطای مجوز به اپلیکیشن‌های مخرب OAuth، به داده‌های حساس یا انجام اقدامات خطرناک دسترسی پیدا می‌کنند.
در حمله فیشینگ رضایت، مهاجم لینکی فیشینگ به هدف ارسال می‌کند که درخواست مجوز برای دسترسی به داده‌های حساس یا انجام اقدامات خطرناک را دارد. اگر هدف این مجوزها را اعطا کند، مهاجم به همان سطح دسترسی به حساب هدف دست می‌یابد. این دسترسی می‌تواند احراز هویت چندمرحله‌ای (MFA) را دور زده و حتی پس از تغییر رمز عبور باقی بماند.
فیشینگ رضایت معمولا با حملاتی مرتبط است که برای دسترسی به مستأجران Microsoft Azure یا Google Workspace انجام می‌شوند. با این حال، اخیرا اپلیکیشن‌های SaaS که APIهای تأییدشده با OAuth و فروشگاه‌های برنامه خود را پیاده‌سازی می‌کنند، مانند نمونه اخیر علیه کاربران GitHub، به همان شیوه هدف قرار گرفته‌اند.
پس از اعطای مجوز، مهاجم دسترسی گسترده‌ای به حساب پیدا می‌کند. در این نمونه مربوط به GitHub، مهاجم می‌تواند مخازن را تغییر دهد تا حملات بیشتری علیه کاربران انجام دهد (مانند آلوده کردن آن‌ها به بدافزار)، مخازن و سرویس‌های متصل به آن را آلوده کند و داده‌های حساسی که حساب به آن‌ها دسترسی دارد را استخراج نماید.
فیشینگ تأیید
تأیید ایمیل گاهی به‌عنوان کنترل امنیتی، مانند ثبت حساب جدید، استفاده می‌شود. مهاجمان با فیشینگ تایید(Verification Phishing) یا مهندسی اجتماعی، کاربران را فریب می‌دهند تا لینک تأیید موجود در ایمیل را کلیک کنند یا کد تأیید را ارائه دهند.
نمونه‌ای از این تکنیک، جعل هویت بین ارائه‌دهندگان هویت (IdP) است، جایی که مهاجم یک حساب IdP جدید با دامنه ایمیل شرکتی قربانی ثبت می‌کند. در بسیاری از موارد، این امکان ورود از طریق SSO با IdP جدید را بدون بررسی اضافی فراهم می‌کند. با توجه به تعداد زیاد اپلیکیشن‌هایی که می‌توانند به‌عنوان ارائه‌دهنده هویت (IdP) برای اهداف SSO عمل کنند، اهداف بالقوه متعددی وجود دارند (بسته به اپلیکیشن و روش‌های ورود پشتیبانی‌شده توسط آن).
ارائه‌دهندگان هویت مدیریت‌شده می‌توانند به‌صورت مرکزی توسط سازمان (که مالک و گرداننده IdP و هویت‌های آن است) اداره شوند، در حالی که IdPهای «اجتماعی» مدیریت‌نشده توسط فروشنده کنترل می‌شوند و هویت‌ها توسط کاربر مالکیت و اداره می‌شوند.
فیشینگ رمز عبور خاص اپلیکیشن
در این روش مهندسی اجتماعی، مهاجم کاربر را فریب می‌دهد تا یک «رمز عبور خاص اپلیکیشن» (ASP یاApp-Specific Password) برای حساب خود ایجاد کرده و آن را با مهاجم به اشتراک بگذارد. این رمزهای قدیمی در ارائه‌دهندگان SaaS مانند Google و Apple برای اپلیکیشن‌هایی که از احراز هویت مدرن پشتیبانی نمی‌کنند، طراحی شده‌اند.
مهاجم، با جعل هویت یک نهاد قابل‌اعتماد (مانند پشتیبانی فنی)، کاربر را به تنظیمات امنیتی حساب هدایت کرده و از او می‌خواهد رمز را در فرم یا چت تحت کنترل مهاجم وارد کند. این رمزها، که از MFA پشتیبانی نمی‌کنند، به مهاجم دسترسی مداوم به داده‌های حساب (مانند ایمیل‌ها، فایل‌ها)، بدون ایجاد هشدارهای امنیتی معمول، از طریق APIها می‌دهند. این روش دسترسی را مخفی‌تر و پایدارتر از توکن نشست می‌کند؛ زیرا این رمزهای عبور معمولا تا زمانی که کاربر به‌صورت دستی آن‌ها را ابطال نکند، معتبر باقی می‌مانند.
نمونه‌ای اخیر نشان داد که یک متخصص عملیات اطلاعاتی روسیه با فریب پیچیده‌ای هدف قرار گرفت، جایی که مهاجم با جعل هویت وزارت امور خارجه آمریکا، کاربر را به ایجاد و اشتراک ASP برای دسترسی به صندوق پستی Google هدایت کرد.
هدف قرار دادن حساب‌های محلی بدون کلید عبور
ساده‌ترین راه دور زدن کلیدهای عبور(passkeys)، هدف قرار دادن اپلیکیشن‌هایی است که از کلیدهای عبور پشتیبانی نمی‌کنند. این اپلیکیشن‌ها (مانند Slack، Mailchimp، Postman، GitHub) اغلب از ورود مستقیم به‌جای SSO استفاده می‌کنند و فاقد کنترل‌های امنیتی قوی ارائه‌دهندگان IdP (مانند Microsoft، Google، Okta) هستند.
همان‌طور که روش‌های پشتیبان MFA اغلب در کنار کلیدهای عبور ثبت می‌شوند، روش‌های ورود محلی مخفی(ghost login) نیز غالبا در کنار SSO ثبت می‌شوند، به این معنا که حساب‌ها چندین نقطه ورود بالقوه دارند. در بسیاری از موارد، این حساب‌ها اصلا MFA ندارند، که آن‌ها را به همان اندازه در برابر حملاتی که از اطلاعات کاربری سرقت‌شده استفاده می‌کنند آسیب‌پذیر می‌کند.
نتیجه‌گیری
اغلب اوقات، مهاجمان نیازی به انجام کار خاصی ندارند تا از پس‌کی‌ها عبور کنند. تنها با استفاده از همان ابزارها و تکنیک‌های فیشینگ معمولی که استفاده می‌کنند، می‌توانند به راحتی به هدف خود برسند، به‌ویژه اگر روش‌های احراز هویت پشتیبانی غیر از پس‌کی، مانند MFA (احراز هویت چندعاملی)، به حساب متصل باشد.
تنها حساب‌هایی که واقعاً امن هستند، آن‌هایی هستند که فقط از پس‌کی‌ها استفاده می‌کنند و هیچ روش پشتیبان دیگری ندارند یا از سیاست‌های دسترسی مشروط برای جلوگیری از احراز هویت غیر از پس‌کی‌ها استفاده می‌کنند.
اما در اینجا نیز جزئیات مهم هستند (مثل نمونه اخیر از قالب‌های CA (پالایش دسترسی) ارائه‌شده توسط مایکروسافت که ورودهای “خطرناک” را به عنوان مثبت کاذب در نظر می‌گیرند و اجازه می‌دهند که این ورودها انجام شود).
و نظارت بر اپلیکیشن‌ها و گسترش هویت به هیچ وجه کار ساده‌ای نیست، به‌ویژه وقتی که سطوح مختلفی از دید و کنترل در اختیار تیم‌های امنیتی برای هر اپلیکیشن وجود دارد (و این واقعیت که بسیاری از اپلیکیشن‌ها اصلاً به‌طور متمرکز پذیرفته یا شناخته نشده‌اند).
پیشگیری و مقابله با حملات فیشینگ با Push Security
حملات کاهش سطح دسترسی (downgrade attacks) که از کیت‌های فیشینگ AitM (attacker-in-the-middle) استفاده می‌کنند، اکثریت حملات فیشینگ برای دور زدن پس‌کی‌ها را تشکیل می‌دهند.
پلتفرم امنیتی مبتنی بر مرورگر Push Security، قابلیت‌های شناسایی و واکنش جامع در برابر حملات هویتی مانند فیشینگ AitM، پر کردن اعتبارنامه‌ها (credential stuffing)، اسپری کردن پسوردها (password spraying) و دزدیدن نشست‌ها (session hijacking) با استفاده از توکن‌های نشست دزدیده شده را فراهم می‌کند.
همچنین می‌توانید از Push برای پیدا کردن و رفع آسیب‌پذیری‌های هویتی در تمام اپلیکیشن‌هایی که کارکنان شما از آن‌ها استفاده می‌کنند، مانند: ورودهای نامرئی (ghost logins)، شکاف‌های پوشش SSO، شکاف‌های MFA، پسوردهای ضعیف، نشت‌شده و استفاده‌شده مجدد، یکپارچگی‌های خطرناک OAuth و غیره استفاده کنید.
