در این Write up مربوط به آسیب پذیری منطقی، که توسط Fady Othman تهیه شده است به معرفی یک آسیب پذیری در یک برنامه باگی بانتی پرداخته می شود که منجر به عبور از مکانیزم امنیتی تعریف شده می گردد.
مقدمه
همانطور که حملات سایبری هر روز افزایش می‌یابد، امنیت برنامه‌های کاربردی وب نیز افزایش می‌یابد. این منجر به دو مشکل بالقوه می‌شود که توسعه دهندگان نمی‌توانند به تنهایی آن‌ها را حل کنند. اولین مورد این است که شکستن سیستم‌ها بسیار سخت‌تر است: حتی اگر آن‌ها از برخی از رایج ترین مسائل امنیتی آگاه باشند، اشکالات احتمالی سیستم‌های برنامه‌های کاربردی وب بسیار گسترده‌تر و حل آن‌ها پیچیده‌تر است. مشکل دوم چارچوب‌های مدرن است. حتی اگر آن‌ها به طور پیش فرض ایمن هستند، نمی‌توانند از سیستم در برابر اشکالات منطقی محافظت کنند.
وقتی توسعه‌دهندگان به راحتی نمی‌توانند تمام مسیرهای اجرایی را که می‌تواند منجر به یک اشکال منطقی شود، پیدا کنند، هکرهای اخلاقی وارد صحنه می‌شوند، این یافته‌ها را بسیار جالب و ارزشمند می‌کند.
در این پست وبلاگ، روشی را که برای یافتن اشکالات منطقی به عنوان یک هکر اخلاقی معتبر دنبال می‌کنم، توضیح خواهم داد. من این کار را با توضیح یک آسیب‌پذیری واقعی از آخرین pentest خود با Strike انجام می‌دهم و پس از آن، مراحلی را که باید برای یافتن باگ‌های منطقی دنبال کنید، خلاصه می‌کنم. این مراحل کلی خواهند بود و با هر هدفی قابل استفاده هستند، پس بیایید شروع کنیم.
چگونه شروع کردم؟
در Strike به من یک pentest برای یک بازار NFT اختصاص داده شد. یکی از زمینه‌هایی که مشتری می‌خواست من روی آن تمرکز کنم، پرداخت‌های FIAT بود. اساسا، FIAT یک نام فانتزی برای ارزهای معمولی (مانند USD، EUR و غیره) است، بنابراین این وب سایت به کاربران اجازه می‌دهد تا با استفاده از ارزهای معمولی به جای ارزهای دیجیتال، برای NFT ها پرداخت کنند.
این وب سایت از یک نام خصوصی به عنوان درگاه پرداخت خود استفاده می‌کرد. مشتری یک محیط آزمایشی برای من فراهم کرد که از sandbox برای آزمایش پرداخت‌ها استفاده می‌کند و به من این امکان را می‌دهد که از شماره‌های کارت اعتباری آزمایشی استفاده کنم و بدون خرج کردن پول واقعی، پرداخت‌ها را انجام دهم.
قبل از شروع، بیایید نحوه عملکرد شرکت را توضیح دهیم. به طور خلاصه، فروشنده – بازار NFT در این مورد – یک لینک ایجاد می‌کند و آن را در اختیار کاربر قرار می‌دهد. سپس از آن برای پرداخت با استفاده از کارت اعتباری خود استفاده می‌کند. پس از آن، سرورهای شرکت درخواستی را به یک Callback Endpoint که توسط فروشنده میزبانی شده است ارسال می‌کنند، بنابراین می‌توانند تایید کنند که پرداخت انجام شده است.
به منظور محافظت در برابر حملات احتمالی، مشتری که من برای آن کار می‌کردم IPهای شرکت را در لیست سفید قرار داد تا از ارسال درخواست هر IP دیگری به نقطه پایانی برگشت به تماس جلوگیری شود. این بسیار مؤثر است زیرا مانع از ارسال تأییدیه پرداخت جعلی توسط افراد می‌شود.
از آنجایی که باید سیستم آن‌ها را هک کنم، همه چیز را برای دور زدن لیست سفید IP انجام دادم، اما همه چیز به درستی هم در برنامه و هم در WAF پیاده سازی شده بود و ارائه هدرهایی مانند “X-Forwarded-For” به منظور Bypass به خوبی کار نمی‌کرد.
به نظر می‌رسید تنها راه حل این است که سرورهای شرکت را به نوعی مجبور به ارسال تأییدیه جعلی کنم. با این حال، این کار باید بدون هک کردن سرورهای آن انجام می‌شد زیرا خارج از محدوده بود و توسط مشتری کنترل نمی‌شد، بنابراین انجام هرگونه هک اخلاقی علیه خود شرکت غیرقانونی بود.
در این مرحله من کمی گیر کردم، بنابراین تصمیم گرفتم خودم یک حساب sandbox برای شرکت ایجاد کنم. به این ترتیب می‌توانستم تصویر کاملی از آنچه در پشت صحنه می‌گذرد داشته باشم و امکان شکستن منطق برنامه را بدون نیاز به دور زدن لیست سفید IP ببینم.
من شروع به جستجو در اسناد API شرکت کردم. من postman را دانلود کردم و collection را باز کردم. برای استفاده از APIها در collection، باید مقادیر X-Login، X-Trans-Key و SecretKey را در محیط postman تنظیم کنم. وقتی یک حساب sandbox از شرکت ثبت می‌کنید، این مقادیر در دسترس هستند.
من شروع به جستجوی APIها کردم و نقطه پایانی API را که مسئول ایجاد لینک‌های پرداخت در Postman Collection در زیر Payings->Payments->Redirect->2 مرحله تسویه حساب (بدون payment_method_id) کشف کردم.
هنگام نگاه کردن به پارامترهای JSON برای نقطه پایانی، متوجه دو پارامتر جالب، پارامتر “order_id” و “notification_url” شدم. “notification_url” روی Callback Endpoint تنظیم شده است تا برنامه بتواند پرداخت‌های موفق را تایید کند و “order_id” توسط برنامه تنظیم شده است تا پرداخت را با سفارش مرتبط کند.
بعد از دیدن این دو پارامتر، دقیقاً فهمیدم که باید چه کار کنم. من سناریوی حمله زیر را در ذهن داشتم:
اگر از حساب شخصی خود در شرکت برای ایجاد لینک پرداخت استفاده کنم و کارهای زیر را انجام دهم چه؟
- از حساب sandbox خود برای ایجاد URL پرداخت استفاده می‌کنم.
- در “order_id” مقدار یا همان Value سفارش خود را در بازار NFT قرار می‌دهم.
- “notification_url” را روی Callback URL از بازار NFT تنظیم می‌کنم.
- سپس پرداخت انجام را انجام می‌دهم. به این ترتیب، شرکت با شناسه سفارش برای من با بازار NFT تماس خواهد گرفت و عملاً لیست سفید IP را دور زده خواهد شد.
من سناریوی حمله بالا را آزمایش کردم و همانطور که گمان می‌کردم، توسعه دهندگان فقط order id را بررسی کردند اما payment id را بررسی نکردند. payment id توسط شرکت در هنگام انجام callback ارسال می‌شود و همچنین هنگام ایجاد لینک در وهله اول در دسترس است.
سناریوی بالا به من اجازه داد تا لیست سفید IP را دور بزنم زیرا callback از طرف شرکت می‌آید. همچنین، به ما این امکان را می‌دهد که قیمت را کاملاً کنترل کنیم.
نتیجه گیری
بر اساس سناریوی بالا متوجه خواهید شد که مراحلی وجود دارد که هر زمان که به دنبال اشکالات منطقی هستید می‌توانید آن‌ها را تکرار کنید:
- منطق برنامه را درک کنید. این بدان معنی است که شما باید به عنوان یک کاربر معمولی از برنامه استفاده کنید.
- سعی کنید جزئیات فنی پیاده سازی را درک کنید. این معمولاً مستلزم خواندن اسناد مربوط به فناوری‌ها/APIهای مورد استفاده توسط وب‌سایت مورد نظر است.
- شما باید کد خود را بنویسید که از همان فناوری یا API استفاده می‌کند. این به شما این امکان را می‌دهد که در جزئیات غوطه ور شوید و مطمئن شوید که اسناد را به درستی درک کرده اید و همچنین بعداً به بهره برداری کمک می‌کند. در حین نوشتن کد، سعی کنید روی آنچه ممکن است اشتباه باشد تمرکز کنید. به عنوان مثال: اگر نوع بررسی‌هایی را که برای جلوگیری از حملات باید اجرا کنید را در نظر بگیرید، این به شما امکان می‌دهد یک چک لیست بسازید که می‌توانید در تست نفوذ جعبه سیاه از آن استفاده کنید.
امیدوارم این مقاله برای شما مفید واقع شده باشد.
