سلام خدمت شما دوستان عزیز امروز میخوام رایتاپ باگی که از آکادمی لیان پیدا کردم رو براتون شرح بدم.
اول باید جریان پرداخت در درگاههای ایرانی رو بررسی کنیم چون آسیبپذیریهای مختلفی در این بخش رخ میدهد.
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 یا کارگزاری
بنظر شما بانتی که باید بهش تعلق بگیره چقدره؟
ممنون میشم پاسخ بدید
این آسیب پذیری از ارزش بالایی برخورداره و به نظرم باید بین خطرناک و بحرانی باشه چون دیگه شاید مهم ترین چیز برای یه کسب و کار بحث مالی باشه و حساب کن تو یه کارگزاری یا سامانه ارز دیجیتال پیدا بشه باید بحرانی در نظر گرفته بشه و بانتی هم باید مقدار قابل توجهی باشه براش
سلام
استفاده از vps به جای سیستم خودمون تاثیری توی حمله داره؟ مثلا سرور از هتزنر آلمان بگیریم یا ایران بگیریم. باعث میشه حمله قدرتمند تر و درصد موفقیتش بیشتر بشه؟
کندی و ضعیف بودن سایت هدف تاثیری داره در حمله؟
سلام بله اگه با vps باشه بهتره
ولی من عادی با همین توربو میزنم تو ۹۰ درصد شرایط کارو راه میندازه مگه دیگه جایی نیاز به اسکریپت اختصاصی داشته باشی
و توربو بایت آخر هر درخواست رو نگه میدارع و بعد میفرسته
سلام
اون ۳ عددی که توی اسکریپت بود چیه و تغییر هرکدوم چه تاثیری داره؟
سلام
concurrentConnections این یعنی درخواست ها تو چند ترد ارسال بشن و requestsPerConnection و این پارامتر هم میگه تو کانکشن چند درخواست ارسال شه باید اینارو تغییر بدی تا به نتیجه دلخواه برسی
سلام
رایتاپ زیبایی بود
فقط ای کاش جنبه های فنی کار هم توضیح داده می شد
تست کردم ولی جواب نداد یعنی فکر کنم اصلا درست انجام ندادم
من turbo intruder رو نصب کردم
اول از همه اینکه کدهای اصلی داخل اون با تصویر شما فرق داشت. شما این کدها رو شخصی سازی کردید ؟
اگر میشه این کدها رو داخل یه فایل text برامون آپلود کنید و لطفا توضیح بدید فرقش با کدهای اصلی خود برنامه چی هست و چه کاری رو هر قسمت داره انجام میده ؟
من چند مرتبه و هر بار تعداد ۵۰ رکوئست رو تست کردم
این مشکلات رو داشتم :
۱- بیشتر درخواست ها fail میشد (طبق آمار پایین صفحه turbo intruder ). مثلا از ۵۰ تا فقط ۱۲ تا به نظر واقعا سمت سرور میرفت.
و متوجه نشدم این fail شدن در مورد کار خود افزونه بوده که مثلا کرش می کرده یا پاسخ سرور بوده یا … ؟
۲ – پاسخ دریافتی از سرور در صفحه turbo intruder نشون داده نمی شد و فقط اون هایی که fail می شد رو به صورت null نشون میداد در لیست.
ولی درخواست هایی که به نظر کامل شده بود پاسخش رو نمی دیدم ولی در تصویر شما response مشخص شده بود که چه status برگشت داده و …
۳ – تفاوت بین کانکشن همزمان و تعداد درخواست ارسالی در هر کانکشن رو در تنظیمات turbo intruder متوجه نشدم و با تغییرش فرق خاصی رو در خروجی ندیدم
۴ – و در نهایت اینکه این تست برای من جواب نداد و موجودی بیشتری اضافه نشد و فقط همون مقدار اصلی اضافه شد.
ممنون میشم اگر موارد فنی این رایتاپ رو توضیح بدید
سلام ممنون از نظرتون
ببینید توی trubo intruder که باز میشه یه حالت کشویی داره باید اون رو بزاری رو حالت race.py و اون کد بالا میاد
این fail شده شاید دلیلش این باشه اسکریپت رو درست انتخاب نکردین بزارین race.py
concurrentConnections این یعنی درخواست ها تو چند ترد ارسال بشن و requestsPerConnection و این پارامتر هم میگه تو کانکشن چند درخواست ارسال شه باید اینارو تغییر بدی تا به نتیجه دلخواه برسی
و کلا باید باهاشون بازی کنی تا منجر به آسیب پذیری بشن ولی خب همیشه منجر به آسیب پذیری نمیشه و سامانه ایمنه
سلام کیف کردم واقعا عالی بود