حملهی HTTP Flooding در تایید ایمیل برای سوء استفاده بدون دخالت کاربر
آنچه می‌خوانید، writeup رامین فرج‌پور، برنامه‌نویس و محقّق امنیتی، از فرآیند کشف آسیب‌پذیری بر روی سامانه‌ی راورو است.
امروزه بسیاری از سایت‌ها به گونه‌‌ای طراحی شده‌اند که اطلاعات شخصی مانند: شماره تلفن، ایمیل، آدرس، فایل‌های رزومه و ... را دریافت می‌کنند.
اگر هر یک از این ویژگی‌ها در سایت ناکارآمد طراحی گردند باعث نشت و سوءاستفاده از اطلاعات کاربران سامانه می‌شود.
در آغاز و قبل از هر چیزی برای آشنایی بیشتر به دسته‌بندی حملات HTTP Flooding می‌پردازیم:
انواع حملات HTTP Flooding single page ( لایه ۷)
Brute-force -۱
Scraping -۲
Crawling -۳
SMS Flooding -۴
Email Flooding -۵
Race Conditions -۶
۷- Hit Counter
۱- Brute-Force
حمله‌ای که در آن تمام حالات ممکن تا رسیدن به جواب بررسی می‌شود؛ بدین معنی که مهاجم تعداد زیادی ورودی را امتحان می‌کند تا در نهایت جواب درستی دریافت کند.
سناریو ۱: بیشتر سایت‌هایی که از رمز یک بار مصرف یا OTP استفاده می‌کنند، اگر پیکربندی نادرستی انجام دهند، باعث افشای کد پیامک‌شده به کاربر می‌شود.
سناریو ۲: برای تغییر ایمیل کاربر، اگر کدی برای تاییدیه ارسال گردد، سبب سوءاستفاده از ایمیل‌های دیگران می‌شود.(ویدئوی زیر نشان‌دهنده‌ی این حمله است)
۲- Scraping
در این حمله، مهاجم یک الگو (pattern) از ساختار مسیر وب استخراج می‌کند.
سناریو ۱: فرض کنیم سایتی از کاربر می‌خواهد تا فایلی به عنوان نمونه «یک مدرک هویتی» را ارسال کند و این فایل با الگوی خاصی درسمت سرور ذخیره می‌شود:
https://example.com/files/20180401103210.pdf
همان‌طور که در بالا مشاهد می کنید، نام فایل بر اساس تاریخ و زمان ذخیره شده است؛ الگوی مشخصی دارد و به راحتی داده‌ها با ارسال درخواست زیاد از سرور قابل دریافت است.
۳- Crawling
این حمله بیشتر برای سرویس‌هایی رخ می‌دهد که حاوی اطلاعات زیادی هستند، مانند: شبکه‌های اجتماعی، جستجو و ... .
سناریو حمله: فرض کنید یک آسیب‌پذیری وجود دارد و داده‌ها در html نشان داده می‌شوند. در این صورت نیازمند یک کد به صورت مایکروسرویس هستیم که مطابق با سرعت داده‌ها دریافت شود.
۴- Flooding SMS
این حمله، یکی از متداول‌ترین حملات است که کم‌تر موردتوجه مدیران کسب‌وکارها قرار می‌گیرد.
سناریو ۱: درخواست ارسالی زیاد به سرور باعث می‌شود کد به شماره همراه کاربران ارسال گردد و اگر در بازه زمانی خاصی منقضی نشود، مهاجم با استفاده از این حمله در کم‌ترین زمان یعنی زیر 2 دقیقه، کد پیامک شده به آن شماره همراه دست می یابد.
سناریو ۲: از آن‌جایی که این سرویس به یک سرویس خارجی متصل می‌شود و در پنل ارسال پیامک برای هر پیامک مبلغی برای شارژ واریز می‌شود، اگر ارسال درخواست محدودیتی نداشته باشد، مهاجم با حملهی کدهای مایکروسرویس خود، باعث ایجاد زیان مالی به سازمان و ... می‌شود.
۵- Flooding Email
در این حمله مهاجم بیشتر در پی DoS کردن یا مختل کردن عملکرد سرویس‌دهنده ایمیل است.
۶- Conditions Race
این حمله به صورتی است که اگر در سرور تعریف متغیرهای برنامه درست انجام نشود، مهاجم با ارسال تعداد درخواست‌های زیاد، می‌تواند متغیرهایی که در سرور برای انجام یک عمل یکسان استفاده می‌شوند را در یک زمان برای دو عمل یکسان استفاده کند.
سناریو ۱: فرض کنید شما می‌خواهید فرآیند عضویت و یا ثبت‌نام در یک سایت را انجام دهید. در زمان یکسان با یک ایمیل بتوانید دو کاربر با ایمیل یکسان در سامانه ثبت کنید.
سناریو ۲: فرض کنید شما قصد انجام یک خرید آنلاین را دارید و مبلغی برای فراخوانیِ سفارش، پرداخت کرده‌اید. در همین حال مایکروسرویس در حال اجرا چندین درخواست ارسال می‌کند تا دو فراخوان یکسان در پایگاه داده ثبت شود.
سناریو ۳: فرض کنید که شما می‌خواهید عضو یک گروه وب شوید و قصد دارید با اجرای چندین نخ (Thread) این کار را انجام دهید. با این روش، شما به صورت خودکار همزمان دو کاربر با نام کاربری و ایمیل یکسان ثبت کرده‌اید.
۷- Hit Counter
در بعضی سایت‌ها برای آمار از مشاهده‌های وبلاگ‌ها و یا سایت از hit count استفاده می‌کنند که نشان دهنده این می‌باشد که چه تعداد کاربر این پست یا مقاله یا سایت مشاهده شده است.
سناریو ۱: اگر در پیاده‌سازی این مورد به درستی انجام نشود یعنی برای هر درخواست که به صفحه مورد نظر می‌شود یک عدد به hit counter اضافه گردد مسبب تعداد مشاهده نادرست از وضعیت آمار در سایت می‌شود.
شرح آسیب‌پذیری
با توجه به توضیحات بالا، هر یک از سناریوها مورد بررسی قرار گرفت. با توجه به نوع بررسی کدهای تاییدیه، از حمله Brute-Force برای نشان‌دادن آسیب‌پذیری تاییدیه کد ایمیل استفاده شده است. با توجه به جزئیات این آسیب‌پذیری دو سناریوی حملهی احتمالی در ذهن تداعی می‌شود.
۱- بتوانم در سامانه‌ی راورو، آدرس ایمیل آن دسته از کاربران که در سامانه ثبت‌نام کرده‌اند را به ایمیل ثبت‌نام شده‌ی دیگری در سامانه که در اختیار خودم است، تغییر بدهم. حالا با این کار باید دید آیا تصاحب حساب کاربری Account Take Over امکان‌پذیر می‌شودیا نه؟
۲- سوءاستفاده از ایمیل‌های دیگران بدون دخالت صاحب ایمیل
در گام بعدی به تست سناریوها پرداختم. گزینه اول جواب نداد. برای همین تصمیم به عملی‌سازی سناریو دوم گرفتم که موفقیت‌آمیز بود و بدون دخالت صاحب ایمیل کد تایید ایمیل دور زده شد. البته در این بین، درخواست‌ها با Thread 80 برای سرور ارسال می‌شد و سرور در تمام این مراحل، HTTP Flooding را شناسایی نکرد. حالا شما این موضوع را می‌‌توانید به ترفندهای دیگر گسترش دهید. به این صورت که اگر در پیکربندی OTP هم این نقص وجود داشته باشد، سوءاستفاده از همین آسیب‌پذیری دور از ذهن نمی‌بود و مهاجم، بدون دخالت صاحب شماره تلفن می‌توانست کد پیامکی که برای کاربر ارسال می‌شد را متوجه شود.
در حال حاضر تیم فنی راورو این آسیب‌پذیری را برطرف کرده‌اند.
کد پیاده‌سازی این حمله از این لینک قابل دریافت است.
راه‌حل پیشنهادی
۱- تا حد امکان برای تایید کدهای ارسال شده به کاربر باید از ترکیبی از کاراکتر و عدد استفاده کرد. با این کار، حالت‌های بررسی کدها بیشتر شده و در صورتی که مهاجم از حمله HTTP Flooding استفاده کرد، انجام این کار سخت‌تر شود.
۲- از Rate Limiter برای Endpoint ها استفاده شود تا حجم وسیعی از درخواست‌ها روانه نشود.
۳- استفاده از Captcha.
۴- استفاده از سرویس‌های ابری مانند CloudFlare
ویدئوی کشف این آسیب‌پذیری
ویدئوی این آسیب‌پذیری از این لینک قابل مشاهده است.
