گاهی اوقات آسیبپذیریهای مهم از پیچیدهترین Payloadها یا تکنیکهای پیشرفته به وجود نمیآیند؛ بلکه نتیجه یک فرض اشتباه در منطق برنامه هستند. در این رایتآپ، یک پیکربندی نادرست در فرآیند ورود با Discord بررسی میشود که امکان دور زدن تأیید ایمیل، Pre-Account Takeover، تصاحب حساب کاربران و دور زدن احراز هویت دومرحلهای را فراهم میکرد.
سناریوی ورود با Discord
فرض کنید یک پلتفرم امکان ورود از طریق Discord را در اختیار کاربران قرار داده است.
روند عادی به شکل زیر است:
- کاربر روی گزینه «Login with Discord» کلیک میکند.
- Discord اطلاعات کاربر را در اختیار سایت قرار میدهد.
- سایت بر اساس ایمیل دریافتی حساب جدید ایجاد میکند یا حساب Discord را به حساب موجود کاربر متصل میکند.
به عنوان مثال:
{
"email": "ali@example.com",
"verified": true
}در این حالت سایت فرض میکند صاحب حساب Discord همان صاحب ایمیل است و فرآیند ورود را ادامه میدهد.
امنیت کل این فرآیند به یک فرض وابسته است:
ایمیلی که Discord ارسال میکند باید تأییدشده و متعلق به همان کاربر باشد.
اولین نقطه ضعف
برای بررسی این فرض، ورود با یک حساب Discord انجام شد که هیچ ایمیل تأییدشدهای نداشت.
به عنوان مثال:
Email: attacker@example.com
Verified: Falseیا حتی حسابی که صرفاً با شماره تلفن ایجاد شده بود.
در این شرایط انتظار میرفت سایت دسترسی را متوقف کرده و از کاربر بخواهد ابتدا ایمیل خود را در Discord تأیید کند.
اما اتفاق دیگری رخ داد.
سایت صفحه ایجاد حساب را نمایش داد و فیلد ایمیل را به صورت غیرفعال (Disabled) نشان داد.
<input name="email" disabled>چرا Disabled امنیت ایجاد نمیکند؟
ویژگی Disabled تنها یک محدودیت سمت مرورگر است و هیچ کنترل امنیتی واقعی محسوب نمیشود.
با استفاده از Developer Tools مرورگر میتوان آن را حذف کرد:
<input name="email">اکنون فیلد قابل ویرایش است.
در این مرحله به جای ایمیل خود، یک ایمیل دلخواه وارد شد:
victim@example.comو درخواست ارسال شد.
نکته جالب این بود که سرور این مقدار را بدون هیچ اعتبارسنجی اضافهای پذیرفت.
دور زدن تأیید ایمیل
در نتیجه حسابی با ایمیل زیر ایجاد شد:
victim@example.comدر حالی که هیچ مدرکی مبنی بر مالکیت این ایمیل ارائه نشده بود.
به عبارت دیگر، سایت تنها به مقدار ارسالشده از سمت مرورگر اعتماد کرده و مرحله تأیید ایمیل عملاً دور زده شده بود.
Pre-Account Takeover
حال فرض کنید صاحب ایمیل هنوز در سایت ثبتنام نکرده است.
مهاجم مراحل قبل را انجام میدهد و حسابی با ایمیل زیر ایجاد میکند:
victim@example.comچند روز بعد صاحب واقعی ایمیل قصد ثبتنام دارد.
اما با پیغام زیر مواجه میشود:
This email already existsاز دید قربانی، حساب قبلاً ایجاد شده است.
در واقع مهاجم پیش از ورود قربانی، حساب مرتبط با ایمیل او را در اختیار گرفته است.
این سناریو با نام:
Pre Account Takeover (Pre-ATO)شناخته میشود.
بررسی حسابهای موجود
در مرحله بعد ایمیلی انتخاب شد که از قبل در سیستم ثبت شده بود.
به عنوان مثال:
victim@example.comکه متعلق به یک کاربر واقعی بود.
در این حالت سایت تلاش میکرد حساب Discord فعلی را به حساب قربانی متصل کند.
حالت اول: قربانی فاقد 2FA
فرض کنیم قربانی هیچ احراز هویت دومرحلهای نداشته باشد.
پس از وارد کردن ایمیل قربانی، حساب Discord مهاجم به حساب قربانی متصل شد.
ساختار حساب به شکل زیر درآمد:
Victim Account
└── Discord (Attacker)اکنون مهاجم کافی بود گزینه:
Login with Discordرا انتخاب کند.
در نتیجه مستقیماً وارد حساب قربانی میشد.
این سناریو یک:
Full Account Takeoverمحسوب میشود.
حالت دوم: قربانی دارای 2FA
حال فرض کنیم قربانی از Google Authenticator استفاده میکند.
در چنین شرایطی انتظار میرود هنگام انجام عملیات حساس مانند اتصال یک روش ورود جدید، سایت درخواست کد 2FA کند.
اما این اتفاق رخ نداد.
Discord مهاجم بدون وارد کردن کد 2FA به حساب قربانی متصل شد.
به عنوان مثال:
Victim Account
└── Discord (Attacker)با این حال هنگام ورود نهایی، سایت همچنان کد 2FA را درخواست میکرد.
بنابراین مهاجم موفق به ورود کامل به حساب نمیشد.
در نتیجه این مورد:
2FA Bypass on Account Linkingبود، نه یک Account Takeover کامل.
زنجیره کامل حمله
کل فرآیند را میتوان به شکل زیر خلاصه کرد:
جمعبندی
ریشه اصلی این آسیبپذیری اعتماد بیش از حد سرور به دادههای دریافتی از سمت کاربر بود.
برنامه فرض میکرد اگر فیلدی در رابط کاربری غیرفعال باشد، کاربر قادر به تغییر آن نیست. اما مهاجم توانست با حذف یک ویژگی ساده در HTML، هر ایمیلی را وارد کند و از همین طریق زنجیرهای از آسیبپذیریها را ایجاد کند:
- Email Verification Bypass
- Pre-Account Takeover
- Full Account Takeover
- 2FA Bypass در فرآیند اتصال حساب
این مورد نمونه خوبی از اهمیت اعتبارسنجی دادهها در سمت سرور و عدم اعتماد به محدودیتهای رابط کاربری است.
منبع اصلی مقاله
این مقاله با الهام از گزارش منتشرشده توسط پژوهشگر امنیتی Amr A'laa تهیه شده و با هدف آموزش، بازنویسی، ترجمه و تشریح جزئیات فنی آسیبپذیری برای مخاطبان فارسیزبان ارائه شده است.