https://virgool.ir/feed/@moradloo1779محقق امنیتی کارشناس تست نفوذ وب اپلیکیشن https://pihunter.netfa2026-11-11 23:34:37https://files.virgool.ir/upload/users/1244410/avatar/z5onob.jpghttps://virgool.ir/@moradloo1779https://virgool.ir/@moradloo1779/url-shortener-fifrthquxeprبا سلام، من مهدی مرادلو هستم و در این نوشتار به بررسی آسیب‌پذیری‌هایی که ممکن است در سرویس‌های کوتاه‌کننده لینک وجود داشته باشد، پرداخته و نکات ضروری که باید در پیاده‌سازی این سرویس‌ها رعایت شوند را ذکر خواهم کرد من در این نوشتار به کوتاه کننده های لینک داخلی می پردازم و سرویس دهنده های کوتاه کننده لینک و ... هدف من در این نوشتار نیست.. متأسفانه، با اینکه این مسائل بسیار ابتدایی به نظر می‌رسند، اما این آسیب‌پذیری‌ها به وفور در میان شرکت‌های ایرانی مشاهده می‌شوند و در بسیاری از موارد منجر به تصاحب حساب‌های کاربری یا افشای اطلاعات کاربران می‌گردند.لینک کوتاه چیستلینک کوتاه (Short URL) به URL گفته می‌شود که با استفاده از یک سرویس خاص به آدرس طولانی‌تر تبدیل می‌شود. این فرآیند به کاهش طول لینک کمک کرده و آن را برای به اشتراک‌گذاری آسان‌تر و همچنین صرفه‌جویی در فضای اشغالی تبدیل می‌کند. این خدمات راهی آسان برای فشرده‌سازیURLهای طولانی به لینک‌های کوچک و مناسب برای پست‌های رسانه‌های اجتماعی، پیام‌های متنی و غیره فراهم می‌آورد. به عنوان مثال، پس از خرید یک بلیط، کاربر یک لینک کوتاه‌شده دریافت می‌کند که با وارد کردن آن در مرورگر به آدرس دیگری هدایت می‌شود که در آن اطلاعات بلیط خود را مشاهده می‌کند.نحوه کارکرد کوتاه‌کننده‌هایURLتوسعه‌دهندگان می‌توانند از روش‌های مختلفی برای پیاده‌سازی یک سرویس کوتاه‌کننده لینک داخلی استفاده کنند که به‌طور خودکار پس از خرید یا انجام فعالیت‌های خاص، لینک‌های کوتاه‌شده را تولید کند. یکی از شیوه‌های متداول پیاده‌سازی این سرویس به ترتیب زیر است: سرویس کوتاه‌کننده لینک ابتدا یک رشته تصادفی (کد کوتاه) تولید کرده و آن را به URL طولانی (مانند صفحه اطلاعات سفارش یا ...) در پایگاه داده مرتبط می‌سازد. هنگامی که کاربر لینک کوتاه را وارد می‌کند، سرویس با استفاده از کد کوتاه، URL طولانی را از پایگاه داده جستجو کرده و سپس کاربر را به آن هدایت می‌کند.نکات امنیتی که حتماً باید در پیاده‌سازی رعایت کنیدیکی از مواردی که به‌صورت گسترده در لینک‌های کوتاه استفاده می‌شود، نمایش اطلاعات خرید و سفارش است. در بیشتر موارد، داخل لینک‌های کوتاه‌شده توکن حساب کاربری وجود دارد. به‌عنوان مثال، فرض کنید لینک کوتاه به این شکل است:https://links.ir/5sGeT1زمانی که کاربر این لینک را در مرورگر وارد می‌کند، به آدرس زیر هدایت می‌شود:https://linkorginal.ir/order/1?token=RudderEncrypt%3AU2FsdGVkX19SjA%2Bmj3Ar91hSIsXjaKgAczMA6sge5X1Y3tJREM2x1SgJe40nmt9ghAB00j1jvrYAlKMQgu%2FWMUBwDLkaKvt%2Fy9WA%2BNاز آنجا که برای مشاهده اطلاعات نیاز به ورود به حساب کاربری است، سامانه توکن حساب کاربری را نیز در انتهای آدرس قرار می‌دهد.،.همچنین در برخی موارد، کدهای تخفیف با لینک کوتاه ارسال می‌شود یا برای تکمیل یک فرم لینک کوتاه ایجاد شده و برای کاربر ارسال می‌گردد که حاوی اطلاعات حساس است. اگر مهاجم نتواند به انی لینک ها دسترسی داشته باشد مشکلی ایجاد نمی شود اما روش های مختلفی برای بدست آوردن لینک های کوتاه وجود دارد.چگونه مهاجم می‌تواند به لینک‌های کوتاه سایر کاربران دسترسی داشته باشد؟ایندکس شدن لینک‌های کوتاه در موتورهای جستجو:لینک‌های ریدایرکت با وضعیت‌های 302، 303 و 307 می‌توانند ایندکس شوند، مگر اینکه توسعه‌دهندگان اقدامات پیشگیرانه‌ای مانند استفاده از تگ noindex یا محدودیت‌های robots.txt را اعمال کنند. در صورتی که این محدودیت‌ها اعمال نشود، مهاجم می‌تواند با استفاده از یک جستجوی ساده در موتورهای جستجو به برخی از لینک‌های کوتاه که حاوی اطلاعات حساس هستند، دسترسی پیدا کند.Brute force لینک‌های کوتاه:بیشتر کوتاه‌کننده‌های لینکی که در برنامه‌های باگ بانتی به آن‌ها برخورد کرده‌ام، دارای یک رشته تصادفی ۵ کارکتری هستند (شامل حروف بزرگ، کوچک و اعداد) که کل حالت‌های ممکن حدوداً ۹۱۶,۱۳۲,۸۳۲ است. با توجه به این تعداد، اگر یک میلیون لینک صحیح داشته باشیم، به‌طور میانگین با ارسال هر ۹۰۰ درخواست به یک لینک صحیح خواهیم رسید.برای انجام Brute Force، که به معنای تلاش برای دسترسی به اطلاعات با آزمایش همه یا برخی از ترکیب‌های ممکن است، ابزارهای بسیار زیادی وجود دارد که استفاده از آن‌ها نیز بسیار ساده است. این روش به مهاجم این امکان را می‌دهد که با استفاده از یک اسکریپت یا ابزار خودکار به سرعت ترکیب‌های مختلف را آزمایش کرده و به راحتی به لینک‌های صحیح دسترسی پیدا کند.برای جلوگیری از Brute Force، می‌توانید طول رشته را به ۸ افزایش داده و همچنینRate Limiting اعمال کنید. این دو اقدام به‌طور چشمگیری سطح امنیت را افزایش داده و دسترسی غیرمجاز را دشوارتر می‌کند.همچنین، بهتر است برای لینک‌های کوتاه که حاوی اطلاعات حساس هستند، تاریخ انقضا اعمال کنید (مثلاً برای لینک کوتاه تغییر رمز عبور) که پس از زمان مورد نظر منقضی شود. این اقدام می‌تواند به جلوگیری از سوءاستفاده از لینک‌های قدیمی و ناامن کمک کند، چرا که ممکن است مشکلات و تنظیمات اشتباه امنیتی در بخش‌های دیگر سبب شود که محدودیت Rate Limiting اعمال شده دور بخورد.روش‌های دور زدن محدودیتRate Limitingمن در این نوشتار قصد ندارم به روش ها و تکنیک های مختلف دور زدن Rate Limiting، بپردازم ولی برای آشنایی توسعه‌دهندگان، به چند مورد اشاره می‌کنم.عموماً محدودیت‌ها بر رویIP درخواست‌کننده اعمال می‌شود. یکی از روش‌های دور زدن محدودیت‌های اعمال شده بر روی IP استفاده از هدرهای خاص است.زمانی که درخواست‌ها از طریق لود بالانسر، پروکسی یاCDN به سرور اصلی می‌رسند، لود بالانسر هدرX-Forwarded-For را به درخواست‌ها اضافه می‌کند تا منبع درخواست را شناسایی کند. این هدر به سرور اصلی کمک می‌کند تا بداند درخواست از کجا آمده است.با این حال، مهاجمان می‌توانند با اضافه کردن هدرX-Forwarded-For جعلی به درخواست‌های خود، آدرس IP دیگری را به‌جای آدرس IP واقعی قرار دهند. این کار می‌تواند به آن‌ها اجازه دهد تا از محدودیت‌های Rate Limiting عبور کرده و سیستم را فریب دهند. همچنین می‌توانند از هدرهای مختلفی مانند X-Real-IP، X-Originating-IP و X-Client-IP نیز استفاده کنند. این هدرها به مهاجمان اجازه می‌دهند تا آدرسIP واقعی خود را مخفی کرده و به راحتی از محدودیت‌های اعمال‌شده عبور کنند. علاوه بر این، هدرهای دیگری نیز وجود دارد که می‌توانند برای دور زدن محدودیت‌ها مورد سوءاستفاده قرار گیرند.در صورتی که Rate Limiting بر روی سرور اصلی انجام نشود، این محدودیت‌ها بر روی لود بالانسرها یا فایروال‌ها اعمال می‌شوند. در این صورت، اگر مهاجمIP سرور اصلی را کشف کند، می‌تواند درخواست‌ها را به‌صورت مستقیم ارسال کرده و از محدودیت تعداد درخواست‌ها عبور کند.با توجه به این مسائل، ضرورت انقضای لینک‌ها پس از تاریخ مقرر بیشتر احساس می‌شود.روش‌های شناسایی سرویس کوتاه‌کننده لینک در یک سامانهبه عنوان یک متخصص امنیت، برای شناسایی سرویس کوتاه‌کننده لینک در یک سامانه، می‌توانید از چند روش استفاده کنید. فرض کنید در برنامه باگ بانتی می‌خواهید آدرس کوتاه‌کننده لینک یک سامانه را شناسایی کنید. یکی از روش‌های متداول، شناسایی ساب‌دامین‌ها (Subdomain Enumeration) است. همچنین می‌توانید ازFuzzing برای یافتن مسیرهای مرتبط با این سرویس استفاده کنید. علاوه بر این، روش‌های دیگری نیز برای شناسایی این سرویس وجود دارد.عموماً از این سرویس برای ارسال اطلاعات سفارش پس از خرید استفاده می‌شود، که لینک کوتاه برای پیگیری سفارش ارسال می‌گردد. یکی از موارد دیگر، لینک‌های موجود در ایمیل‌های ارسالی توسط سامانه است.روش دیگری که می‌توانید استفاده کنید، بهره‌گیری از ابزارهای backlink checker است. ممکن است فردی یک لینک کوتاه را در شبکه‌های اجتماعی یا مکان‌های دیگر ثبت کرده باشد، و با استفاده از ابزاری مانندSEMrush می‌توان به آن لینک‌ها دسترسی پیدا کرد. به عنوان مثال، در دو گزارشی که ارسال کردم، توانستم با این روش به لینک کوتاه دست یابم.از اینکه تا انتهای این محتوا را مطالعه کردید، سپاسگزارم و امیدوارم مطالب منتشر شده برایتان مفید واقع شده باشد.mahdi moradloomahdi moradlooWed, 09 Oct 2024 18:35:40 +0330https://virgool.ir/@moradloo1779/آسیب-پذیری-در-بخش-تأیید-پرداخت-پلتفرم-دیوار-ta78fein1t3dبا سلام، مهدی مرادلو هستم. در این رایت‌آپ ، قصد دارم به بررسی یک آسیب‌پذیری که در بخش تأیید پرداخت پلتفرم دیوار وجود داشت بپردازم.امیدوارم که از خوندن این رایت‌آپ لذت ببرید .قبل از شروع نیاز می بینم که توضیحات روی در مورد PSP های ایرانی بدم و توصیه میکنم حتما مستندات درگاه های پرداخت مختلف رو خودتون بخونید تا با ساختار کلی و عملکردشون آشنا بشید.کل پروسه پرداخت در pspهای ایرانی شمای مثل شکل زیر داره. ( فقط نیازه به توضیح هست من مراحلی که موضوع رو به حاشیه می برد رو قیچی کردم و سعی کردم به شکل ساده تری موضوع رو بیان کنم)1-پذیرنده سفارش کاربر رو دریافت میکنه و بعد اطلاعات رو در پایگاه داده خودش ذخیره میکنه بعد پذیرنده اطلاعات ترمینال خودش را همراه با مبلغ سفارش و پارامتر های دیگه مثل callbackurl و... به سمت بانک ارسال میکنه و یک Token دریافت می کنه بعد کاربر رو به درگاه بانکی هدایت می کنه تا کاربر پرداختش رو انجام بده .2-پس از اینکه کاربر اطلاعات بانکی خودش رو وارد کرد و پرداخت در سمت درگاه پرداخت انجام شد درگاه اطلاعات مربوط به پرداخت رو در اختیار کلاینت (مرورگر کاربر) قرار میده و هدایتش میکنه به سایت پذیرنده تا پرداخت تکمیل بشه .3-پذیرنده اطلاعات رو دریافت می کنه ابتدا پایگاه داده بررسی میکنه که اطلاعات دریافتی تکراری نباشه و سپس اطلاعات پرداخت رو به سمت بانک ارسال میکنه و در صورت معتبر بودن رسید پرداخت وتطابقش با سفارش کاربر پرداخت رو تأیید کرده و خدمات رو به کاربر ارائه میکنه.)رسید دیجیتال رو هم در پایگاه داده خودش ذخیره میکنه که دوباره مصرف نشه)تا اینجای کار با فرآیندی که یک پرداخت طی میکنه آشنا شدیم پلتفرم دیوار نیز همین روال رو برای پرداخت داره کاربر ابتدا یکی از آیتم های مورد نظرش رو انتخاب میکنه وسپس بروی پرداخت میزنه به درگاه بانکی هدایت میشه ،پرداخت رو انجام میده و بعد اطلاعات پرداخت به اندپوینت تأیید پرداخت دیوار ارسال میشه سپس سامانه پرداخت رو تأیید یا رد میکنه .بیشتر آسیب پذیری هایی که مربوط به بخش پرداخت پلتفرم ها هست در بخش سوم اتفاق می افته جایی که کاربر اطلاعات رو به پذیرنده ارسال میکنه تا پرداخت تأیید بشه من تقریبا بیشتر مستندات فنی درگاه بانکی مختلف ایرانی رو خوندم متاسفانه هیچ یک از psp ها ساختاری رو پیاده سازی نکردن تا بعد از پرداخت در درگاه بانکی خود pspمستقیم از سرور خود یک درخواست به پذیرنده ارسال کنه و پرداخت رو تأیید کنه ، پیاده سازی این ساختار باعث ایمنی بیشتر سامانه ها میشه چرا که کاربر نمی تونه اطلاعات مربوط به پرداخت رو تغییر بده و یکپارچگی سیستم حفظ میشه البته این به معنی معیوب بودن ساختار فعلی نیست اگر پذیرنده ساختار تأیید پرداخت رو درست پیاده سازی کنه مشکلی پیش نمیاد .ولی بیشتر PSPهای بین المللی مثل paypal علاوه بر روش قبلی مکانیزم Instant Payment Notification IPN را نیز پیاده سازی کرده اند که سبب امن تر شدن تأیید پرداخت میشه (البته تنها دلیل استفاده از این مکانیزیم امنیت نیست ) / خلاصه مکانیزمIPN:· شروع پرداخت در وب‌سایت فروشنده و هدایت به پی‌پال.· تأیید پرداخت در پی‌پال.· ارسال پیام IPN به URL مشخص شده توسط فروشنده.· دریافت و پردازش پیام IPN توسط سرور فروشنده.· تأیید دریافت و پردازش پیام IPN به پی‌پال.· تکمیل تراکنش و ارائه کالا یا خدمات.آسیب پذیری IDORمن اولین تستی که روی درگاه پرداخت دیوار انجام دادم آسیب پذیری IDOR بود، میخواستم ببینم ایا میشه یک سفارش رو با مبلغ کمتری پرداخت کرد یانه برای این کار باید ابتدا یک سفارش با مبلغ بیشتر ایجاد میکردم و آیدی اون سفارش رو بدست می آوردم برای بدست آوردن آیدی سفارش ابتدا به بخش پرداخت آگهی رفتم و بروی نردبان کردن آگهی زدم که هزینه این آیتم 60 هزار تومان بود بعد اینکه بروی خرید این آیتم زدم و وارد درگاه پرداخت اینترنتی شدم بروی انصراف از خرید زدم در این حالت یک درخواست به اند پوینت زیر ارسال می شد که شامل پارامتر های مختلفی بود من پارامتر ResNum را از داخل این درخواست یاداشت کردم و سپس درخواست را Dropکردم.درخواست مربوط به انصراف از خریدPOST /v8/paymentcore/saman/callback/ HTTP/1.1Host: api.divar.irUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0Accept-Language: en-US,en;q=0.5Content-Length: 219Origin: https://sep.shaparak.irMID=10880614&TerminalId=10880614&RefNum=&ResNum=Sa5deqm_lCjitDMgj&State=CanceledByUserدر درخواست روبروResNumهمان آیدی سفارش در پذیرنده (دیوار)هستRefNumمقدار رسید دیجیتال بانکی است (چون اینجا پرداختی انجام نشده مقدار آن خالی است )Stateهم وضعیت پرداخت می باشدحالا باید می رفتم و یک آیتم با مبلغ کمتر رو انتخاب و پرداخت می کردم سپس وقتی اطلاعات پرداخت به پذیرنده ( دیوار ) ارسال می شد مقدار ResNum سفارش 60 هزار تومانی را جایگزین میکردم در آن درخواست ، سپس درخواست را ارسال می کردم اگر سامانه آسیب پذیر بود سفارش 60 هزار تومانی تأیید می شد پس از پرداخت در درگاه بانکی با درخواست زیر مواجه می شدیم که من مقدار ResNum آن را تغییر و ResNum که در مرحله قبل یاداشت کرده بودم را جایگزین کرده و درخواست رو ارسال کردم. سامانه آسیب پذیر نبود .تراکنش لغو و پول به حساب بانکی من برگشت خورد .درخواست تراکنش موفقPOST /v8/paymentcore/saman/callback/ HTTP/1.1Host: api.divar.irUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0Accept-Language: en-US,en;q=0.5Content-Length: 219Origin: https://sep.shaparak.irMID=10880614&TerminalId=10880614&RefNum=Gs01f23$5123123adsfjklda$SDALDSAOFFADSIDSA211&ResNum= Sa5deqm_lCjitDMgj&State=OKدر سامانه های آسیب پذیر سامانه استعلام RefNum را از بانک دریافت می کند و در صورت معتبر بودن RefNumدیگر بررسی نمی کند که آیا مبلغ RefNum با فاکتوری(ResNum) که در سامانه تأیید می شود یکسان است یا خیر سامانه فاکتور را تأیید و Refnum را برای جلوگیری از Double spending در پایگاه داده ذخیره میکنه.سامانه دیوار ولی این مورد رعایت شده بود ،دیوار ابتدا یک درخواست به بانک ارسال می کرد و استعلام RefNumرا دریافت می کرد ،بانک در پاسخ استعلام وضعیت پرداخت و مبلغ پرداختی را باز می گرداند ،سپس سامانه دیوار بررسی میکرد که ایا مبلغ فاکتوری که میخواهد تأیید کند (ResNum) با مبلغی که بانک از استعلام RefNum بازگرداند برابر است یا خیر در صورتی که تفاوتی در این دو باشد سامانه دیوار درخواست Reverse را به بانک ارسال و تراکنش رو بازگشت می داد که باعث می شد پول به حساب بانکی پرداخت کننده برگرده تا اینجای کار مشکلی وجود نداشت اما سناریویی در ذهنم نقش بست که اگر درست پیش می رفت می شد با استفاده از یک رسید دیجیتال ابتدا یک فاکتور رو پرداخت کرد و سپس با ایجاد درخواستی متفاوتی سامانه رو مجبور به ارسال درخواست لغو تراکنش به بانک می کرد.فقط قبل از اینکه مرحله بعد شروع بشه نیازه که در مورد Reverse تراکنش یه توضیحی بدم تا مسئله شفاف تر بشه پذیرنده تا 50 دقیقه بعد از تأیید تراکنش می تونه درخواست اصلاح تراکنش رو به بانک ارسال کنه و سبب لغو تراکنش و بازگشت پول به حساب بانکی واریز کننده بشه .آسیب پذیری Race conditionsسامانه پس از اینکه تراکنش را تأیید می کند برای جلوگیری از Double spending مقدار Refnum را در پایگاه داده ذخیره می کند و قبل از استعلام هر پرداخت نیز ابتدا پایگاه داده را بررسی میکند که Refnum تکراری نباشه بعد فرآیند استعلام و تأیید پرداخت رو انجام میده .سناریویی که در ذهنم نقش بسته بود این بود که اگر سامانه به Raceconditions آسیب پذیر یود می شد از یک Refnum بیش از یک بار مصرف کرد یعنی از یک Refnum تو دو تا درخواست استفاده می کردیم وچون درخواست ها همزمان پردازش می شد قبل از اینکه Refnumدر پایگاه داده ذخیره بشه میرفت سمت استعلام از بانک و من می تونستم سناریوم رو اجرا کنم.من یک پرداخت موفق انجام دهم بدون تغییر در پارامتر های آن و این درخواست را به Repeater ارسال کنم سپس درخواست را تکثیر کرده و در درخواست دوم مقدار ResNum مربوط به یک سفارش با مبلغ متفاوت را قرار داهم سپس دو درخواست را در برپ سوئیت داخل یک گروه قرار داده و درخواست ها را تکنیک single packet attackارسال کنم اگر سناریو من درست اجرا می شد درخواست اول سبب تأیید پرداخت و درخواست دوم چون مبلغ متفاوت بود سبب ارسال درخواست Reverse به بانک و برگشت پول به حساب بانکی می شد.و تمام 😊 سناریو به بار نشست و فاکتور اول تأیید شد و درخواست دوم باعث شد که دیوار درخواست لغو تراکنش رو به بانک ارسال کنه که سبب بازگشت پول به کارت بانکی من می شد.بخش دوم پرداخت چند فاکتور با یک رسید دیجیتالحالا که میشد از یک رسید دیجیتال بیش از یکبار استفاده کرد حدس زدم که امکان پرداخت چند فاکتور با یک رسید دیجیتال نیز وجود داشته باشد برای تست این مورد کافی بود سفارش های هم قیمت ایجاد کرده و مثل مرحله قبل درخواست را با تکنیک single packet attack ارسال کنم که سبب پرداخت همه فاکتورها با یک رسید دیجیتال بانکی می شد.امیدوارم که از خوندن این رایت‌آپ لذت برده باشید سعی کردم که همه موارد شفاف و با جزئیات بیان بشه این آسیب پذیری اسفند 1402 به پلتفرم دیوار گزارش شد و شرکت آگه پردازان هوشمند (دیوار) برای این آسیب پذیری 50 میلیون تومان بانتی پرداخت کرد و پس از مدتی هم آسیب پذیری برطرف شد شما هم برای گزارش آسیب پذیری هاتون می تونید به لینک زیر مراجعه کنید و آسیب پذیری های مربوط به پلتفرم دیوار رو ارسال کنید.https://divar.ir/bugbountymahdi moradloomahdi moradlooWed, 07 Aug 2024 19:57:16 +0330https://virgool.ir/@moradloo1779/آسیب-پذیری-افشای-اطلاعات-مسافران-بروی-پروتکل-mqtt-takclm4lnpepبا سلام، مهدی مرادلو هستم. در این رایت آپ ، قصد دارم به بررسی یک آسیب‌پذیری که بر روی پلتفرم اسنپ تاکسی وجود داشت و موجب افشای اطلاعات مشتریان می‌شد، بپردازم..سوپراپ اسنپ سرویس های متنوعی رو ارائه میکنه از سفارش غذای اینترنتی تا سفارش تاکسی و... که موجب میشه برنامه باگ بانتی اسنپ Scope خیلی بزرگی داشته باشه که سبب جذاب شدن برنامه اش میشه.یکی از بخش های خیلی جذاب این برنامه سرویس تاکسی اینترنتی هست که فیچر های زیادی داره و سناریوهای زیادی رو میشه روش تست کرد.برای اینکه بتونم با عملکرد کلی برنامه آشنا بشم ابتدا مثل یک کاربر عادی شروع به استفاده از برنامه کردم و بصورت manual همه قسمت ها و پارامتر هاشو چک میکردم تا یک شمای کلی از برنامه داشته باشم. پس از بررسی کلی درخواست ها سناریو های زیر به ذهنم رسید.بررسی سناریوهای مختلف حملهRace conditionsاین موقعیت زمانی رخ می‌دهد که چندین پروسس یا ترد به یک منبع مشترک، به طور مثال یک فایل سیستم یا یک رکورد در پایگاه داده، همزمان دسترسی پیدا می‌کنند. برای واضح شدن، مثلاً فرض کنید یک کارت هدیه دارید که با وارد کردن کد آن، مبلغی به حساب شما اضافه می‌شود. حالا تصور کنید چندین نفر به طور همزمان سعی کنند این کد را وارد کنند. در صورتی که سیستم به درستی این وضعیت را مدیریت نکند، ممکن است مبلغ مورد نظر چندین بار به حساب اضافه شود، که نتیجه‌ای ناخواسته و اشتباه است.این مشکل به عنوان «شرایط رقابتی» یا "Race Condition" شناخته می‌شود. در این حالت، نتیجه نهایی به ترتیب زمانی که دسترسی به منبع مشترک رخ می‌دهد، وابسته است و ممکن است نتایج غیرمنتظره‌ای تولید کند. برای جلوگیری از چنین مشکلاتی، معمولاً از تکنیک‌هایی مانند قفل‌ها (Locks) استفاده می‌شود تا اطمینان حاصل شود که تنها یک پروسس یا ترد در هر لحظه به منبع مشترک دسترسی دارد. به عنوان مثال، می‌توان از یک قفل برای محدود کردن دسترسی به کارت هدیه استفاده کرد تا تنها یک نفر بتواند همزمان کد را وارد کند و مبلغ به درستی به حساب اضافه شود.اولین موردی که دوست داشتم بررسی کنم Race conditions بود ، سفر اول زمانی که من سامانه رو بررسی میکردم رایگان بود واگر سامانه نسبت به Race conditionsآسیب پذیر بود می شد بجای یک سفر چند سفر رایگان گرفت . در burp suite می توان برای Race conditions از افزونه turbo intruder استفاده کرد همچنین بطور پیش فرض نیز می توان با گروه بندی کردن درخواست ها در burp suite و ارسال درخواست ها با تکنیک single packet آسیب پذیری race conditions رو بروی سامانه شناسایی کرد.کافیست چند درخواست سفر ایجاد کنید و سپس درخواست ها را در یک گروه قرار داده و با تکنیک single packe ارسال کنید تا متوجه آسیب پذیر بودن یا نبودن سامانه بشوید.پس از بررسی و ارسال درخواست ها متوجه شدم دقت لازم در این قسمت بکاررفته و سامانه در این بخش آسیب پذیر نیست.2- یکی از مواردی که باید در تست Race conditions مورد توجه قرار بگیره ساختار برنامه هاست عموما ساختار بیشتر برنامه ها به شکلی پیاده سازی شده اند که نمیشه یک کد تخفیف رو چندبار بروی یک سفارش اعمال کرد پس برای تست آسیب پذیری Race conditions بروی کد تخفیف بهتره که دو سفارش مجزا ایجاد کنید و سعی کنید کد تخفیف رو بروی دو سفارش اعمال کنید.من بروی اسنپ تاکسی برای تست این مورد ابتدا دوتا درخواست تاکسی ایجاد کردم و بعد سعی کردم یک کد تخفیف رو روی دو سفر اعمال کنم که این مورد هم به آسیب پذیری ختم نشد.Business logicاسنپ برای رانندگان خودش نسبت به مسافتی که طی میکنن سهمیه سوخت در سامانه سماس اعمال میکنه اگر اسنپ مسافت تاکسی تا مسافر رو قبل از سوار شدن مسافر در نظر میگرفت میشد سهمیه سوخت به مقدار دلخواه گرفت و یک آسیب پذیری ایجاد می شد چونکه با توجه به ساختار موجود راننده می تونست از یک شهر دیگه سفر یک شهر دیگه رو قبول کنه مثلا یک تاکسی در اهواز سفری در مشهد رو قبول کنه که مسافت 2000 کیلومتری دارد که سبب اعمال سهمیه سوخت 200 لیتری برای این سفر می شد و مهاجم می تونست با ثبت سفرجعلی و قبول کردنش با اکانت راننده خودش از این مکانیزیم سو استفاده کنه برای این کار هم کافی بود ابتدا یک سفر ایجاد کنید و شناسه سفر که ساختار این شکلی داره رو بدست بیارید SNP-240506-72634-5215 سپس با استفاده از اکانت راننده یک درخواست به اندپوینت زیر بزنید تا سفر برای شما ثبت بشه.https://api.snapp.site/driver/ SNP-240506-72634-5125/acceptپس از بررسی متوجه شدم که مسافت راننده تا مبدا سفر جزو محدوده نیست که سهمیه بهش تعلق بگیره و این مورد منتفی بود.مورد بعدی که بررسی کردم ورودی های غیر متعارف بود یکی از موراد منفی کردن زمان توقف در سفر بود منطق برنامه به این شکله که شما وقتی مقدار 10 دقیقه توقف رو وارد می کنید این مقدار میره و در عددی ضرب میشه و هزینه به سفر اضافه میشه منتها اگر این عدد ورودی منفی باشه یعنی ما بجای 10 دقیقه توقف عدد -10 دقیقه توقف رو وارد کنیم این عدد منفی میره در یک عدد ثابت ضرب میشه و سپس وقتی خروجی منفی با هزینه سفر جمع میشن سبب کاهش هزینه سفر میشه پس از بررسی این قسمت هم متوجه شدم برنامه فقط اعداد طبیعی ((Nرو قبول میکنه و این قسمت هم آسیب پذیر نیست.آسیب پذیری IDORعموما آسیب پذیری IDORتوی پلتفرم های مثل اسنپ رو باید تو موارد غیر مستقیم دنبالش گشت مثلا امکان اینکه در اندپوینت مربوط به نمایش اطلاعات سفر آسیب پذیری IDOR باشه خیلی بعیده ولی احتمال اینکه توی ثبت شکایت برای یک سفر یا تغییر جزئیات سفر این مشکل پیش بیاد بیشتره که این موارد هم آسیب پذیری نبودند ولی قسمت اشتراک سفر خیلی توجهم رو جلب کرد .https://share.snapp.taxi/ride-receipt/msnn6e9tjqJ5qQilrd3kiqGfS7bxKBiluVMXKeR1PqXUs0Hw5b57jIJYp3e2قبلش یه توضیح بدم در مورد نسخه راننده اسنپ ، در نسخه راننده اطلاعات سفر مثل مبدا مقصد و قیمت برای راننده ارسال میشه تا از بین سفرها یک سفر رو انتخاب کنهحالا چیزی که تو ذهنم نقش بست این بود که ممکنه مقدار انتهای اند پوینت (اشتراک سفر) تو اطلاعاتی باشه که به سمت راننده ارسال میشه رفتم سراغ genymotion و اپ راننده رو باز کردم(اسنپ راننده نسخه pwaنداره) ، شروع کردم به کپچر کردن ترافیک ولی مسئله عجیبی پیش اومد اطلاعات داشت رد و بدل میشد ولی ترافیک مربوط به درخواست های سفر بروی burpsuite نداشتم همه قسمت ها رو بررسی کردم چیزی نبود حدس زدم که ممکنه اسنپ از پروتکلی استفاده کنه که burpsuite پشتیبانیش نمیکنه به همین خاطر رفتم سمت Wireshark ، Wireshark یک ابزار قدرتمند برای تحلیل و آنالیز ترافیک و پروتکل های شبکه است که باهاش می تونیم کل ترافیک رو capture و بررسی کنیم.پس از بررسی ترافیک توی Wireshark متوجه شدم که اسنپ برای این بخش از پروتکل MQTT استفاده میکنه.سرویس تاکسی اینترنتی نیاز به ارتباطات سریع و با کارایی بالا داره. MQTTبه دلیل سبکی و سرعت بالای خود، مناسب برای ارسال پیام‌های کوچک و به صورت فوریه که این ویژگی می‌تونه ارتباطات بین درخواست‌دهنده و راننده رو بهبود ببخشهپروتکل MQTT از مدل انتشار/اشتراک پیام استفاده می‌کند که این مدل امکان ارسال پیام‌ها به یک مخاطب خاص یا گروه از مخاطبین را فراهم می‌کند. مثلا وقتی یه مسافر توی یه نقطه خاصی درخواستش رو به سمت broker ارسال میکنه broker میتونه درخواست مسافر رو به گروهی از رانندگان که در نزدیکی مسافر هستند ارسال کنه این ویژگی می‌تونه منجر به ارسال همزمان اطلاعیه‌ها به رانندگان و، مدیریت بهتر سفرها و بهبود تجربه کاربری بشه بعد اینکه متوجه پروتکل استفاده شده در اسنپ شدم سعی کردم یک ابزار آماده برای proxyو interceptاین پروتکل پیدا کنم که به ابزار زیر رسیدم.https://github.com/NVISOsecurity/IOXYبعد اجرای ابزار مسئله دیگه ای پیش اومد که به کلی توجه ام رو از آسیب پذیری IDOR دور کرد وقتی ترافیک دریافت میشد شماره تماس مسافر نیز برای راننده ارسال میشد فقط تو بخش UI نمایش داده نشده بود (یعنی شماره مسافر قبل اینکه راننده سفر رو قبول کنه نمایش داده می شد) ترافیکی که دریافت میکردم همچنین چیزی بود (خلاصش کردم یکم)}"id":"SNP-240506-72634-5125","origin_lat": 35.70324,"origin_lng": 51.34601,"destination_lat": 35.7090,"destination_lng": 51.3634,"passenger":"مهدی مرادلو","amount": 3800000,"cellphone": "+989121112233"}{کارکرد کلی سیستم به این شکل بود که موقعیت رانننده برای Broker ارسال میشد و Broker هم سفر های مربوط به موقعیت مکانی راننده رو براش PUSH میکرد حالا میشد مختصات موقعیت مکانی مختلفی رو به سمت BROKERارسال و اطلاعات کامل سفرها رو دریافت کرد مهاجم با نوشتن یک برنامه و ارسال خودکار و دریافت اطلاعات می تونست به اطلاعات کل سفرهای کشور دسترسی داشته باشد وبا ذخیره اطلاعات در پایگاه داده یک بیگ دیتا از کل سفرهای اسنپ داشته باشه.این آسیب‌پذیری در سال ۱۴۰۰گزارش شد و در مدت زمان کوتاهی برطرف شد. اسنپ بابت این آسیب‌پذیری ۵۰ میلیون تومان پاداش پرداخت کرد.برای مشاهده برنامه باگ بانتی اسنپ و ارسال می تونید به لینک زیر مراجعه کنید.https://snapp.ir/bugbounty/mahdi moradloomahdi moradlooSun, 14 Jul 2024 14:56:34 +0330