نگاره‌هایی پیرامون امنیت، شبکه و رمزنگاری

23 جولای 2022

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

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

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 آسیب‌پذیری:

4 پست نوشته شده
علاقه‌مند به برنامه‌نویسی، وب هکینگ و رمزنگاری
دانشجوی رشته گیاه پزشکی دانشگاه ایلام و رشتم در تضاد با علاقم
  • به اشتراک بگذارید:
  1. hitman گفت:

    salam khaste nabashi be omid bounty haye kheli khub
    null byte ee ke estefade kardi chi bod

    • hExToR گفت:

      سلام ممنون از نظرتون
      برای استفاده از ابزار turbo intruder برای تمیز و جایگزینی پیلود ها از %s یا همون null byte استفاده میشه توی race condition ازش

  2. reza گفت:

    بسیار عالی

  3. mr_network گفت:

    سلام ، عالی بود . ایول
    ایشالا که همیشه موفق باشی و بترکونی

  4. sara گفت:

    سلام
    مقاله خیلی جالبی هست
    ولی من متوجه نشدم روند کار رو
    اگر امکان داره توضیح بدید
    مثلا علامتی که جلوی connection اضافه کردید چی بود؟ و چرا اضافه شد؟
    اون افرونه دقیقا داره چه کاری انجام میده؟ و با هر بار درخواستی که به سرور می فرسته داره چه عدد یا پارامتری رو تغییر میده ؟
    و اینکه این آسیب پذیری از کدام قسمت ایجاد شد؟ یعنی در این مورد خاص از چه طریقی باید مانع این اقدام می شدیم که جلوی شارژ شدن بیشتر گرفته بشه ؟

    • hExToR گفت:

      سلام ممنون از نظرتون
      اون علامت null byte هست که برای افزونه turbo intruder باید بزاری
      و این افزونه میاد چند تا درخواست رو به صورت تقریبا همزمان ارسال می‌کنه که در این همزمانی باعث میشه روند طبیعی برنامه دچار اختلال بشه و به آسیب پذیری منجر شده
      در قسمت پلاگینی که اطلاعات پرداخت رو چک می‌کنه و برای رفع این آسیب پذیری بستگی به زبان برنامه نویسی داره ولی خب اکثرا از قابلیت lock کردن استفاده میکنند

  5. علی گفت:

    سلام
    چطور تشخیص بدیم برنامه ما به race condition آسیب پذیره؟

    • hExToR گفت:

      سلام
      با استفاده از افزونه turbo intruder و فرستادن چند درخواست به صورت همزمان تو قسمت مورد نظر بخش مورد نظرتون رو تست کنید

  6. احمد گفت:

    اگر همچین آسیب پذیری یا مشابه آن در یک سایت مهم پیدا بشه چقدر ارزش داره؟ برای مثال در isp یا کارگزاری
    بنظر شما بانتی که باید بهش تعلق بگیره چقدره؟
    ممنون میشم پاسخ بدید

    • hExToR گفت:

      این آسیب پذیری از ارزش بالایی برخورداره و به نظرم باید بین خطرناک و بحرانی باشه چون دیگه شاید مهم ترین چیز برای یه کسب و کار بحث مالی باشه و حساب کن تو یه کارگزاری یا سامانه ارز دیجیتال پیدا بشه باید بحرانی در نظر گرفته بشه و بانتی هم باید مقدار قابل توجهی باشه براش