آسیب‌پذیری Race Condition در آکادمی لیان

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

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

Payment Gateway Flow :

1. مرحله اول جایی هست که کاربر بعد از اینکه کالا مورد نظرش رو توی فروشگاه آنلاین انتخاب کرد، روی دکمه پرداخت کلیک می‌کنه
2. اینجا فروشگاه و PSP در یک کانال مخفی از دید کاربر، اطلاعاتی رو رد و بدل می‌کنند، نتیجه اخذ یک Reservation number یا ResNum هست. توی این قسمت، بعضی PSPها پیاده‌سازی متفاوتی رو ارائه می‌دن، برای مثال کل فرایند رو Tokenized می‌کنند
3. توی این قسمت، کاربر اطلاعات رو که شامل مبلغ پرداخت، ResNum و آدرس بازگشتی و موارد اینچنینی هست رو دریافت می‌کنه. معمولا یک فرم HTML با روش POST در این قسمت وجود داره که کاربر رو به سمت درگاه پرداخت هدایت می‌کنه
4. کاربر با اطلاعات کسب شده در مرحله سوم، به سمت درگاه پرداخت میره
5. در جواب، در صورت عدم وجود خطا، نشست کاربر به‌روز می‌شه و یه قطعه کد جاوااسکریپت یا HTML کاربر رو مجبور به ارسال یک درخواست GET میکنه
6. کاربر درخواست GET رو می‌فرسته، توجه کنیم که نمی‌تونست از اول GET بفرسته و باید مرحله قبلی طی میشد و نشست به‌روز میشده
7. در صورتی که مشکلی نباشه، صفحه پرداخت ظاهر میشه
8. کاربر اطلاعات کارت رو وارد می‌کنه و دکمه پرداخت رو می‌زنه
9. در صورت درست بودن اطلاعات، یک Reference Number یا RefNum تولید میشه که فارسیش میشه «رسید دیجیتال» که به منزله پرداخت موفق است. توی این مرحله باز کاربر توسط یک تکه کد جاوااسکریپت یا HTML به سمت آدرس بازگشتی میشه. این آدرس توی مرحله ۳ توسط خود کاربر ارسال شده. از مواردی که کاربر با خودش به فروشگاه می‌برده، ResNum و RefNum و موارد دیگر مشابه هست
10. توی این قسمت کاربر روی دکمه «تکمیل فرآیند خرید» کلیک می‌گنه و اطلاعات رو به فروشگاه می‌فرسته (این قسمت به‌صورت خودکار انجام میشه)
11. فروشگاه توی این مرحله صحت RefNum و ResNum رو با PSP بررسی می‌کنه (البته قبل از بررسی با PSP، خود فروشگاه بررسی‌های اولیه رو توی این قسمت انجام میده)
12. در صورت موفقیت، پایگاه‌داده فروشگاه به‌روزرسانی می‌شده و پیغام خرید موفق به کاربر نشون داده میشه

البته این جریان کاری، با کمی تغییر در PSPهای مختلف داره کار می‌کنه، توی درخواست‌های ۱، ۴ و ۱۰ کاربر می‌تونه توی جریان کاری دخالت کنه. آسیب‌پذیری کشف شده هم دقیقا توی مرحله 11 اتفاق می‌یفته

در مرحله 11 ممکن آسیب پذیری های مختلفی مثل IDOR , Race Condition , Double-Spending رخ بده که در سامانه لیان آسیب پذیری Race-Condition رخ داد.

Race Condition  چیست؟

Race Condition اتفاق غیره منتظره ایست که به معنای اجرای همزمان دو یا چند فعالیت توسط سیستم است، در حالی که ماهیت سیستم ایجاب می‌کند که فعالیتها با توالی خاصی پشت سر هم انجام شوند تا منطق سیستم به درستی کار کند.

Race Condition زمانی به یک آسیب‌پذیری تبدیل می‌شود که بر روی مکانیزم کنترل امنیت برنامه تاثیر بگذارد. هکرها می‌توانند برنامه را در شرایطی قرار بدهند که یک فعالیت حساس قبل از اجرای کامل فعالیت دیگر در سیستم‌های کنترل امنیتی اجرا شود. از اینرو از آسیب‌پذیری Race Condition به عنوان آسیب‌پذیری زمان بررسی (Time of Check) یا زمان استفاده (Time of Use) هم نام می‌برند.

Race Condition در پنل تحت وب لیان

در وب اپلیکیشن سامانه لیان در قسمت کیف پول آسیب‌پذیری از نوع Race Condition وجود دارد و در درخواست نهایی از سمت بانک(مرحله ۱۱ در فلو) این آسیب‌پذیری رخ میدهد و باعث میشود موجودی کیف پول چندین برابر مبلغ پرداختی شود.

سناریو حمله:

• افزایش چند برابری موجودی کیف پول
• خرید دوره‌های آکادمی لیان با قیمتی بسیار پایین
• فروش دوره‌های لیان برای سو استفاده

ویدیو POC آسیب‌پذیری: