جدول محتوا
Internal Recon
در بحث Bug Hunting یکی از مهم‌ترین فازها، ریکان هست که می‌تونیم دو دسته‌ی External Recon و Internal Recon رو در نظر بگیریم که اینجا به صورت مختصر هر کدوم رو توضیح می‌دم. در فاز external هدف شناسایی ساب دامین‌های تارگت هست و سعی می‌کنیم با استفاده از Automation و داشتن یک Recon Workflow به این کار سرعت بدیم. در فاز Internal تمرکز ما بر روی مپ کردن اپلیکیشن است تا با Functionalityها و زیرساخت هدف بهتر آشنا بشیم. بعد از مپ کردن قسمت‌های مختلف این هدف، سعی کردم به دنبال نقاطی باشم که ممکن بود برای من کشف یک آسیب‌پذیری با Impact بالا رو به دنبال داشته باشه. تعداد زیادی از Functionalityها در وب اپلیکیشن‌های مختلف، تنها برای کاربران Authenticated در سیستم فعال هستند و آسیب‌پذیری‌های خوبی رو در این قسمت‌ها می‌شه پیدا کرد. من بعد از لاگین در این اپلیکیشن، یکی از جاهایی که برای تست انتخاب کردم مسیر /MyInfo/MemberInfo بود که در این مسیر یک کاربر می‌تونه از طریق فرم Personal Info که در تصویر زیر می‌بینیم، اطلاعات یا بخشی از اطلاعات خودش رو به روز کنه:
آسیب‌پذیری منطقی در Personal Info
من داخل این فرم سناریوهای حمله‌ی مختلفی رو در نظر داشتم که یکی از اون‌ها تغییر ایمیل کاربران دیگر این وب اپلیکیشن بود تا بتونم به Account Takeover برسم. قبل از تست این سناریوها، من متوجه شدم اگر روی Edit در جلوی ایمیلم کلیک کنم، یک پیام نمایش داده می‌شه که اپلیکیشن از من می‌خواد برای تغییر ایمیلم به یک ایمیل دیگه، Verification Code که به ایمیل جاری من ارسال می‌شه رو وارد کنم تا ایمیلم تغییر کنه:
زمانی که با همچین پیغامی روبرو شدم، سعی کردم دنبال راهی باشم تا اول این مکانیزم رو دور بزنم و دنبال ساده‌ترین راه ممکن بودم. زمانی که روی Edit My Info در فرم بالا کلیک کردم، با درخواست زیر روبرو شدم:
در درخواست بالا، Old_Email به ایمیل جاری که در اکانت من تنظیم شده اشاره می‌کنه. من مقدار این پارامتر رو به یک ایمیل دیگه تغییر دادم و در اینجا دو حالت ممکن بود پیش بیاد. حالت اول این بود که سرور جلوی این درخواست رو بگیره و از من یک Verification Code بخواد و حالت دوم این بود بدون اینکه Verification Code رو وارد کنم، ایمیل من تغییر کنه. پس مقدار این پارامتر رو به یک ایمیل دیگه تغییر دادم و درخواست رو فرستادم و اینبار اپلیکیشن بدون اینکه از من کدی رو بخواد، ایمیل جدید رو برای اکانت من ست کرد و اینجا به یک آسیب‌پذیری منطقی رسیدم. در تصویر زیر می‌تونید ساختار این حمله رو ببینید:
دقت داشته باشید، قبل از اینکه یک باگ رو گزارش بدید، به این فکر کنید راهی وجود داره که بشه شدت آسیب‌پذیری رو بالاتر برد یا نه. هدف بعدی من این بود که بتونم ایمیل یک کاربر دیگه رو تغییر بدم.
تست آسیب‌پذیری CSRF در Personal Info
سامانه‌ی هدف به صورت Cookie-Based کار می‌کرد و یکی از سناریوهای حمله‌ای که در نظر گرفتم، استفاده از CSRF برای تغییر اطلاعات شخصی قربانی و ایمیل بود. در درخواست بالا یک CSRF Token ارسال می‌شد (personal_key) و در نتیجه شروع کردم به بررسی راه‌های ممکن برای دور زدن Anti-CSRF Token. فارغ از روش‌های رایجی که برای تست توکن مورد نظر وجود داره، ما می‌تونیم از آسیب‌پذیری‌های دیگه کمک بگیریم تا به CSRF Token قربانی دسترسی پیدا کنیم. استفاده از CORS برای دسترسی به توکن قربانی در اینجا ممکن نبود. در مسیر بالا که اشاره کردم، سعی کردم یک آسیب‌پذیری دیگه پیدا کنم تا بتونم توکن قربانی رو بخونم. در اینجا حمله‌ی Web Cache Deception به ذهنم رسید.تست حمله‌ی Web Cache Deception
همون‌طور که می‌دونید وب اپلیکیشن‌ها از قابلیت Caching System استفاده می‌کنند تا منابعی که به صورت مرتب توسط کاربرها درخواست داده می‌شه، کش شده و در درخواست‌های بعدی کاربر سریع‌تر به منبع دسترسی پیدا کنه. فایل‌هایی که عموما کش می‌شن فایل‌های استاتیک و عمومی هستند مثل فایل‌های js، css و فایل‌های استاتیک دیگر. در سناریوی حمله‌ی Web Cache Deception، هکر عموما دنبال صفحه‌ای می‌گرده که شامل اطلاعات حساس و یا اطلاعات مفیدی از کاربر باشه و بعد با دست‌کاری Path و ارسال لینک دست‌کاری شده به قربانی، به اطلاعات حساس و کش شده‌ی کاربر توسط Caching System دسترسی پیدا می‌کنه. پیشنهاد می‌کنم برای آشنایی بیشتر با این آسیب‌پذیری، اول با مکانیزم Caching آشنا بشید (می‌تونید از این مرجع استفاده کنید) و بعد این مقاله رو بخونید تا در خوبی از این آسیب‌پذیری پیدا کنید. برای تست Web Cache Deception در این هدف، مراحل زیر رو انجام دادم: - ابتدا مسیری رو پیدا کردم که شامل اطلاعات حساسی از کاربر بود. در واقع همین مسیری بود که بالاتر دربارش صحبت کردیم یعنی MyInfo/MemberInfo - در انتهای مسیر بالا یک فایل استاتیک رو اضافه کردم و درخواست رو به سمت سرور ارسال کردم تا ببینم سرور چه نوع پاسخی بهم بر می‌گردونه و آیا همون صفحه رو دوباره می‌بینم یا نه: target.com/MyInfo/MemberInfo/test.css - بعد از ارسال درخواست بالا، پاسخی از سمت سرور دریافت کردم که همون محتوای صفحه‌ی MemberInfo بود (بر اساس نوع فناوری و پیکربندی، ممکنه نوع پاسخی که دریافت می‌کنیم متفاوت باشه و ما با حالتی کار داریم که همان محتوای صفحه یعنی MemberInfo در اینجا برای ما برگردونده بشه). زمانی که URL بالا رو در یک مرورگر دیگه باز کردم متوجه شدم که این مسیر توسط Caching System کش شده و به صورت پابلیک قابل دسترس هست و می‌تونم اطلاعات کش شده‌ی کاربر رو ببینم. در ویدیوی زیر مراحلی که توضیح دادم رو می‌تونید ببینید: من تا اینجا متوجه شدم که اپلیکیشن نسبت به حمله‌ی Web Cache Deception آسیب‌پذیره. در اقع من می‌تونستم یک گزارش تنظیم کنم و برای تیم امنیتی ارسال کنم ولی نکته‌ای که ابتدای این رایت‌آپ هم بهش اشاره کردم این بود که سعی کنیم همیشه قبل از ارسال گزارش یک آسیب‌پذیری، فکر کنیم که راهی وجود داره بشه شدت آسیب‌پذیری رو بالاتر برد یا نه.ترکیب Web Cache Deception با آسیب‌پذیری‌های قبلی
هدف من این بود که با تغییر ایمیل قربانی، بتونم به Account Takeover برسم و دیدیم که سناریوی CSRF به صورت مستقیم جواب نمی‌داد و من دنبال یک آسیب‌پذیری بودم تا با کمک اون بتونم به توکن قربانی دسترسی پیدا کنم. حالا یه سوال مطرح می‌شه و اینکه چطور می‌شه با استفاده از Web Cache Deception به توکن قربانی دسترسی پیدا کرد؟ نکته اینجاست که صفحه‌ی کش شده، به جز اطلاعات کاربر مثل ایمیل و غیره، شامل personal_key هم می‌شه. این نکته رو می‌تونیم در تصویر زیر ببینیم:
برای دسترسی به توکن و تغییر ایمیل کاربر با استفاده از ترکیب آسیب‌پذیری‌های شرح داده شده در بالا، من سناریوی حمله‌ی زیر رو پیاده‌سازی کردم:
- ابتدا هکر لینک دامین خودش رو برای قربانی که در وب‌سایت لاگین هست، ارسال می‌کنه.
- زمانی که قربانی وارد دامین هکر بشه، چندین فاز صورت می‌گیره:
فاز اول: یک درخواست GET با استفاده از یک تگ img به مسیر زیر ارسال می‌شه تا با استفاده از CSRF Token، Web Cache Deception یا Personal_Key قربانی کش بشه:
https://gmemberssl.gmarket.co.kr/MyInfo/MemberInfo/<Random_Number>.css
در URL بالا، Random_Number به صورت داینامیک ساخته می‌شه و هر کاربری که از دامین من بازدید کنه، یک درخواست GET به مسیر بالا ارسال می‌شه تا بتونم به ازای کاربران مختلف، مسیرهای کش شده‌ی هر کاربر رو ببینم و بتونم به اطلاعات کش شده‌ی هر کاربر دسترسی پیدا کنم. فاز دوم: یک درخواست از دامین هکر به URL کش شده ارسال می‌شه تا CSRF Token یا Personal Key خونده بشه که این‌کار به سادگی قابل انجام هست، چون هم مسیر مورد نظر رو می‌دونیم و هم فایلی که در انتهای مسیر اضافه شده و به راحتی می‌شه از URL کش شده به CSRF Token دسترسی پیدا کرد. فاز سوم: در این مرحله باید CSRF Token که از مرحله‌ی قبل گرفته شده به صورت داینامیک در داخل فرم تغییر اطلاعات کاربر یا فرم Edit My Info قرار داده باشه تا حمله‌ی CSRF انجام بشه. این فرم هم به صورت اتوماتیک توسط جاوا اسکریپت Submit می‌شه و در نهایت ایمیل قربانی تغییر پیدا می‌کنه. دقت کنید در این مرحله از آسیب‌پذیری منطقی که در ابتدای فرایند پیدا کرده بودم هم استفاده کردم تا ایمیل قربانی بدون ارسال Verification Code تغییر پیدا کنه:
ویدیوی POC این آسیب‌پذیری رو می‌تونید در پایین تماشا کنید. در این ویدیو قربانی ابتدا وارد دامین هکر شده و حمله‌ی Web Cache Deception انجام می‌شه و بعد با استفاده از اکسپلویت نوشته شده، CSRF Token از URL کش شده خوانده و داخل صفحه‌ی CSRF Token قربانی نمایش داده می‌شه، درنهایت حمله‌ی CSRF اجرا شده و ایمیل قربانی به ایمیل دیگه‌ای تغییر پیدا می‌کنه:
بعد از ارسال گزارش آسیب‌پذیری، تیم امنیتی ebay جواب زیر رو بهم داد:
امیدوارم که از خوندن این رایت‌آپ لذت برده باشید. همیشه سعی کنید در هر هدفی که تست می‌کنید، سناریوهای ترکیبی مختلف رو در نظر بگیرید (مثل ترکیب آسیب‌پذیری‌های منطقی و فنی) تا به یک آسیب‌پذیری با Impact بالاتر برسید. از طریق این شناسه @LogicalHunter می‌تونید در تلگرام و توییتر با من در ارتباط باشید.