سلام خدمت شما دوستان عزیز امروز میخوام رایتاپ باگی که از آکادمی لیان پیدا کردم رو براتون شرح بدم.
اول باید جریان پرداخت در درگاههای ایرانی رو بررسی کنیم چون آسیبپذیریهای مختلفی در این بخش رخ میدهد.
Payment Gateway Flow :

- مرحله اول جایی هست که کاربر بعد از اینکه کالا مورد نظرش رو توی فروشگاه آنلاین انتخاب کرد، روی دکمه پرداخت کلیک میکنه
- اینجا فروشگاه و PSP در یک کانال مخفی از دید کاربر، اطلاعاتی رو رد و بدل میکنند، نتیجه اخذ یک Reservation number یا ResNum هست. توی این قسمت، بعضی PSPها پیادهسازی متفاوتی رو ارائه میدن، برای مثال کل فرایند رو Tokenized میکنند
- توی این قسمت، کاربر اطلاعات رو که شامل مبلغ پرداخت، ResNum و آدرس بازگشتی و موارد اینچنینی هست رو دریافت میکنه. معمولا یک فرم HTML با روش POST در این قسمت وجود داره که کاربر رو به سمت درگاه پرداخت هدایت میکنه
- کاربر با اطلاعات کسب شده در مرحله سوم، به سمت درگاه پرداخت میره
- در جواب، در صورت عدم وجود خطا، نشست کاربر بهروز میشه و یه قطعه کد جاوااسکریپت یا HTML کاربر رو مجبور به ارسال یک درخواست GET میکنه
- کاربر درخواست GET رو میفرسته، توجه کنیم که نمیتونست از اول GET بفرسته و باید مرحله قبلی طی میشد و نشست بهروز میشده
- در صورتی که مشکلی نباشه، صفحه پرداخت ظاهر میشه
- کاربر اطلاعات کارت رو وارد میکنه و دکمه پرداخت رو میزنه
- در صورت درست بودن اطلاعات، یک Reference Number یا RefNum تولید میشه که فارسیش میشه «رسید دیجیتال» که به منزله پرداخت موفق است. توی این مرحله باز کاربر توسط یک تکه کد جاوااسکریپت یا HTML به سمت آدرس بازگشتی میشه. این آدرس توی مرحله ۳ توسط خود کاربر ارسال شده. از مواردی که کاربر با خودش به فروشگاه میبرده، ResNum و RefNum و موارد دیگر مشابه هست
- توی این قسمت کاربر روی دکمه «تکمیل فرآیند خرید» کلیک میگنه و اطلاعات رو به فروشگاه میفرسته (این قسمت بهصورت خودکار انجام میشه)
- فروشگاه توی این مرحله صحت RefNum و ResNum رو با PSP بررسی میکنه (البته قبل از بررسی با PSP، خود فروشگاه بررسیهای اولیه رو توی این قسمت انجام میده)
- در صورت موفقیت، پایگاهداده فروشگاه بهروزرسانی میشده و پیغام خرید موفق به کاربر نشون داده میشه
البته این جریان کاری، با کمی تغییر در 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 آسیبپذیری:

دانشجوی رشته گیاه پزشکی دانشگاه ایلام و رشتم در تضاد با علاقم
salam khaste nabashi be omid bounty haye kheli khub
null byte ee ke estefade kardi chi bod
سلام ممنون از نظرتون
برای استفاده از ابزار turbo intruder برای تمیز و جایگزینی پیلود ها از %s یا همون null byte استفاده میشه توی race condition ازش
بسیار عالی
ممنون بابت نظرتون
سلام ، عالی بود . ایول
ایشالا که همیشه موفق باشی و بترکونی
قربونت داداش
ایشالا همچنین موفق خودتم بیییم
سلام
مقاله خیلی جالبی هست
ولی من متوجه نشدم روند کار رو
اگر امکان داره توضیح بدید
مثلا علامتی که جلوی connection اضافه کردید چی بود؟ و چرا اضافه شد؟
اون افرونه دقیقا داره چه کاری انجام میده؟ و با هر بار درخواستی که به سرور می فرسته داره چه عدد یا پارامتری رو تغییر میده ؟
و اینکه این آسیب پذیری از کدام قسمت ایجاد شد؟ یعنی در این مورد خاص از چه طریقی باید مانع این اقدام می شدیم که جلوی شارژ شدن بیشتر گرفته بشه ؟
سلام ممنون از نظرتون
اون علامت null byte هست که برای افزونه turbo intruder باید بزاری
و این افزونه میاد چند تا درخواست رو به صورت تقریبا همزمان ارسال میکنه که در این همزمانی باعث میشه روند طبیعی برنامه دچار اختلال بشه و به آسیب پذیری منجر شده
در قسمت پلاگینی که اطلاعات پرداخت رو چک میکنه و برای رفع این آسیب پذیری بستگی به زبان برنامه نویسی داره ولی خب اکثرا از قابلیت lock کردن استفاده میکنند
سلام
چطور تشخیص بدیم برنامه ما به race condition آسیب پذیره؟
سلام
با استفاده از افزونه turbo intruder و فرستادن چند درخواست به صورت همزمان تو قسمت مورد نظر بخش مورد نظرتون رو تست کنید
اگر همچین آسیب پذیری یا مشابه آن در یک سایت مهم پیدا بشه چقدر ارزش داره؟ برای مثال در isp یا کارگزاری
بنظر شما بانتی که باید بهش تعلق بگیره چقدره؟
ممنون میشم پاسخ بدید
این آسیب پذیری از ارزش بالایی برخورداره و به نظرم باید بین خطرناک و بحرانی باشه چون دیگه شاید مهم ترین چیز برای یه کسب و کار بحث مالی باشه و حساب کن تو یه کارگزاری یا سامانه ارز دیجیتال پیدا بشه باید بحرانی در نظر گرفته بشه و بانتی هم باید مقدار قابل توجهی باشه براش