​🔥 شکار ۴ باگ بحرانی و منطقی در لایه سوکت پرداخت!

​در ادامه پست قبل، تستر با اسکریپت پایتون خودش شروع کرد به فرستادن فریم‌های دستکاری‌شده ISO 8583 به سمت سرور شبیه‌ساز پرداخت. سرور پردازشگر برخلاف ظاهرش، توی بررسی منطق تراکنش‌ها (Business Logic) فاجعه بود و تستر تونست ۴ تا باگ بسیار خطرناک ازش دربیاره:

​1️⃣ دور زدن پنجره زمانی و حمله تکرار (Replay Attack):

سرورها برای اینکه یک تراکنش به خاطر اختلال شبکه دوبار حساب نشه، تا چند ثانیه تراکنش تکراری رو رد می‌کنن. اما تستر فهمید اگه کمی صبر کنه تا اون زمان منقضی بشه و بعد دقیقاً همون کد هگز تراکنش قبلی رو بفرسته، سرور اون رو به عنوان یک خرید کاملاً جدید قبول می‌کنه! (یعنی امکان دبل‌شارژ کردن و دزدیدن پول از کارت مشتری).

​2️⃣ آسیب‌پذیری IDOR بین فروشگاه‌ها (Cross-Merchant IDOR):

تستر با اکانت و سوکت «فروشگاه ب» به سرور وصل شد، اما در پیام هگزادسیمال، شماره مرجع تراکنش (RRN) متعلق به «فروشگاه الف» رو قرار داد. سرور اصلاً چک نکرد که این تراکنش مال کیه و درخواست ابطال (Void) یا برگشت وجه رو تایید کرد! یعنی یک فروشگاه راحت می‌تونست تراکنش‌های رقیبش رو باطل کنه.

​3️⃣ تراکنش شبح (Ghost Transactions):

تستر بدون اینکه فریم احراز هویت (AUTH) رو به سوکت سرور بفرسته، مستقیم درخواست پرداخت فرستاد. سرور تاییدیه پرداخت رو صادر کرد (DE39 = 00)، اما عجیب اینجا بود که این تراکنش در هیچ‌کدوم از سیستم‌های حسابداری، مانیتورینگ و پنل مدیریت ثبت نشد! یعنی پول جابه‌جا می‌شد بدون اینکه ردی بمونه.

​4️⃣ بای‌پاس تایید هویت کارت در زمان ابطال:

پوزهای اندرویدی موقع باطل کردن تراکنش، از کاربر می‌خوان که همون کارت قبلی رو بکشه تا دستگاه تطابق رو چک کنه. تستر با کپی کردن فریم ابطال و فرستادن مستقیم اون از طریق پایتون به سوکت شبکه، این لایه امنیتیِ توکن‌سازی کارت رو کاملاً دور زد و سرور بدون چک کردن اطلاعات کارت، ابطال رو انجام داد.

​👇 پست سوم و آخر رو برای نتیجه‌گیری معماری این باگ‌ها دنبال کنید...

​🆔 @androidSec_fa

​#امنیت #تست_نفوذ #باگ_منطقی #امنیت_شبکه #سوکت_نویسی #تست_پوز