در این Write up مربوط به آسیب پذیری منطقی، که توسط Ashlyn Lau تهیه شده است به معرفی یک آسیب پذیری در یک برنامه باگی بانتی پرداخته می‌شود که منجر به بالا بردن سطح دسترسی می‌گردد.
مقدمه
چند ماه پیش به یک یافته جالب در یک برنامه self-registration در رویکرد تست Blackbox برخوردم. مثل همیشه، من تا حد امکان آن را مختصر نموده و بیشتر روی خود مفهوم تمرکز می‌کنم. امیدوارم بتوانم نور جدیدی را در سفر تست نفوذ شما پرتاب کنم!
در فرآیند تست یک برنامه، نیاز به انجام مناسب مرحله شمارش یا Enumeration است. در مورد شمارش، من از لیست کلمات ممکن بسیاری استفاده خواهم کرد که برای فناوری اساسی مورد استفاده برای توسعه برنامه کاربردی باشد.
شمارش زیر نقطه پایانی Swagger را کشف کرد:
پس از بررسی تمام نقاط پایانی که در رابط کاربری Swagger در معرض دید قرار گرفته اند، یک نقطه پایانی خاص برجسته بود، نقطه پایانی که در برنامه مشتری نشان داده نمی‌شد. نام نقطه پایانی نشان می‌دهد که برای بازیابی اطلاعات مشتریان است و به احتمال زیاد توسط پورتال مدیریت داخلی استفاده می‌شود.
خوب، بیایید شروع کنیم و به صورت عمیق‌تر این نقطه پایانی را بررسی کنیم.
Test 1: Without Auth Session Token — Forbidden
Test 2: Account Sign-up and 2FA Session Token
من برای دسترسی به برنامه اقدام به ایجاد یک حساب کاربری کردم. پس از ورود به برنامه و تکمیل فرآیند 2FA، با رمز جلسه 2FA، من به نقطه پایانی دسترسی پیدا نموده و سرور کد وضعیت 200 را برگرداند، اما هیچ داده‌ای بازیابی نشد.
Test 3: How abt 1FA Session Token
من دوباره با حساب ثبت نامی خودم وارد شدم و 2FA OTP را دریافت کردم، اما 2FA را برای ورود به سیستم ارائه نکردم. با رمز جلسه 1FA به نقطه پایانی درخواست ارسال کردم، سرور کد وضعیت 200 را برگرداند، اما هنوز هیچ داده ای بازیابی نشده است…
در این مرحله، باید دست از تلاش بردارم درست است؟! اما اینجا چیزی عجیب است، از آنجایی که من در آزمایش قبلی دسترسی غیرمجاز (وضعیت 403) نداشتم، تقریباً مطمئن هستم که سمت سرور Token جلسه یک کاربر ثبت نام شده را به طور متفاوتی تأیید می‌کند، اما نمی‌دانم چگونه؟!
بیایید یک قدم به عقب برگردیم. حتی کوچکترین اطلاعات جمع آوری شده از موارد بی شمار بدست آمده در recon یا حتی یک پاسخ سرور به ظاهر بی ضرر یا غیر مفید، می‌تواند راهنمای پیشرو در مورد زمان و مکان عمیق‌تر باشد.
با اطمینان 80 درصدی موضوع، متوقف نشدم و با انواع تزریق هدر که می‌دانم به آزمایش ادامه دادم، اما هیچ چیز جواب نداد….
Test 4: 1FA between the Sun and Moon
من دوباره با اکانت ثبت شده خود وارد شدم، اما این بار کار دیگری انجام دادم. در تست قبلی، من قبلاً 2FA OTP را دریافت کرده بودم اما OTP را برای تکمیل 2FA ارائه نکردم.
اما این بار، پس از ورود 1FA و صدور رمز جلسه 1FA توسط سرور، برنامه درخواست 2FA OTP را به سرور ارسال می‌کند تا OTP را برای کاربر ثبت شده فعال کند. خوب، بیایید این درخواست 2FA OTP را به سرور drop کنیم.
اکنون با توکن جلسه 1FA دوباره به نقطه پایانی دسترسی پیدا کردم.
اطلاعات حساس حساب مشتری بازیابی شد. این API داخلی به مهاجم اجازه می‌دهد تا از ورودی‌های هزاران سوابق مشتری از جمله نام مشتری، شماره تلفن همراه، آدرس ایمیل، شماره شناسایی شخصی و غیره پرس و جو کند.
نمودار زیر خلاصه ای از آزمایش شرح داده شده در بالا را نشان می‌دهد:
Conclusion
در این برنامه چه مشکلی رخ داده است؟! سعی کردم خودم را به جای یک توسعه دهنده بگذارم. شاید در عبارات تودرتو if/else که Token جلسه را تأیید می‌کند، 1FA در تست 4 یک رفتار غیرمنتظره بود و به یک جلسه برزخ تبدیل شد که ذاتاً به امتیازات فوق مدیریت افزایش یافت.
کاری را که دوست دارید انجام دهید و از این روند لذت ببرید!
مبنع:
