آسیب‌پذیری ۲ هزار دلاری افشای اطلاعات کارت‌های بانکی

سلام دوستان، در این پست میخوام دوتا از آسیب پذیری‌هایی که چند روز پیش در باگ بانتی برنامه خارجی کشف کردم با شما به اشتراک بگذارم. دو آسیب‌پذیری P1 گرفتن و توی برنامه تریاژ شدن و ۲ هزار دلار بابت دریافت کردم، البته من از تیم امنیت اجازه انتشار نگرفتم برای همین اسم برنامه رو توی گزارش می‌ذاریم vulnerable.

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

مورد اول)

با بررسی ساب‌دامین‌های برنامه vulnerable، چشمی به ساب‌دامینی به‌نام x.vulnerable.com برخوردم، این سامانه در ارتباط با رزرو کردن دکتر می‌باشد، تمامی اندپوینت‌های موجود در سایت از هاست دیگری به‌نام y.vulnerable.com فرا‌خوآنی می‌شود و همچنین از مکانیسم JWT برای احراز هویت و سطح دسترسی کاربران استفاده می‌کند.

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

خب با دیدن مقدار ID در درخواست‌ها ذهنم به سمت تست کردن IDOR رفت!

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

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

a0p4W00000NRpB5QAL

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

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

a0p4W00000NRpB5QAL

a0p4W00000NRpB4QAL

a0p4W00000NRpAzQAL

a0p4W00000NRpAQQA1

a0p4W00000NRpBJQA1

حالا که شناسه‌ها انقدر به‌هم شبیه هستن وقتش هست یه حساب جدید بسازم و شناسه کارت اون حساب رو مقایسه کنم!

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

a0p4W00000NRp43QAD

همانطور که میبینید شناسه کارت در حساب جدید فقط ۵ حرف آخر باهم تفاوت دارند و ۱۳ کاراکتر اول یعنی a0p4W00000NRp همگی یکسان می‌باشند.

خب، بنظر شما چه ترفندی قابل پیاده سازیه؟

مطمعنا میتونیم اون حروفی که تغییر میکنند رو به صورت تصادفی تولید و ارسال کنیم (خوشبختانه بروت‌فورس امکان‌پذیر بود و لیمیتی بر روی اندپوینت اعمال نمی‌شد)

اما مهم تر از همه این بود که چک کنم آیا میتونم با اطلاعات حساب خودم و فقط بکار بردن شناسه کارت حساب دیگر، اطلاعات رو تغییر یا حتی پاک کنم؟ دیگه با ریسپانس عدم دسترسی رو به رو نشدم! و بله کارت روی حساب دوم هم تغییر کرده!

مورد دوم)

پس از کشف آسیب پذیری اول که قابلیت تغییر و پاک کردن کارت های بانکی بود، برای بالا بردن شدت این آسیب پذیری و دسترسی به اطلاعات کارت دنبال مسیر دیگیری بودم و بعد از دو روز کار کردن و پیدا نکردن مسیر خاصی از ساب‌دامین x.vulnerable.com بیخیال شدم.

روز بعد با دید بقولی out-of-box وارد عمل شدم و دوباره ترافیک‌های تاریخچه برپ رو چک کردم، تا با یه مسیر جالب رو به رو شدم. این مسیر تو ساب‌دامین c.vulnerable.com قرار داشت و سرویس مربوطه از d.vulnerable.com فراخوآنی میشد. با بررسی سرویس مشخص شد اطلاعات کارت کاربر را بر‌میگرداند. این سرویس که‌ در این مسیر بر خلاف مسیر قبلی که شماره کارت رو لازم داشت، با دادن شناسه کاربر که یک عدد ۷ رقمی که به صورت‌ متوالی بود، اطلاعات کارت کاربر رو دریافت میکردی!

فورا عملیات تست IDOR رو روی مسیر انجام دادم و بووووووم!

اطلاعات کارت‌بانکی حساب‌‌کاربری در پاسخ سرور بدست آوردم!

با اطلاعات بدست اومده، می‌توانیم حتی قسمت بروت‌فورس آسیب‌‌پذیری اول رو حذف کنیم چون تک تک شناسه کارت‌های موجود هر حساب‌کاربری قابل برداشت می‌باشد. همچنین چون شناسه عددی به صورت متوالی می‌باشد (9102301, 9102302 و …) استخراج تمامی کارت‌های بانکی بیماران به‌راحتی قابل انجام می‌باشد.

نکته‌‌هایی که من از این کشف باگ یاد گرفتم:

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

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

منو می‌تونید تو توییتر و اینستاگرام دنبال کنید.