آسیب پذیری افشای اطلاعات مسافران بروی پروتکل MQTT

با سلام، مهدی مرادلو هستم. در این رایت آپ ، قصد دارم به بررسی یک آسیب‌پذیری که بر روی پلتفرم اسنپ تاکسی وجود داشت و موجب افشای اطلاعات مشتریان می‌شد، بپردازم..

سوپراپ اسنپ سرویس های متنوعی رو ارائه میکنه از سفارش غذای اینترنتی تا سفارش تاکسی و... که موجب میشه برنامه باگ بانتی اسنپ 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 نمایش داده نشده بود (یعنی شماره مسافر قبل اینکه راننده سفر رو قبول کنه نمایش داده می شد) ترافیکی که دریافت میکردم همچنین چیزی بود (خلاصش کردم یکم)

}

&quotid&quot:&quotSNP-240506-72634-5125&quot,

&quotorigin_lat&quot: 35.70324,

&quotorigin_lng&quot: 51.34601,

&quotdestination_lat&quot: 35.7090,

&quotdestination_lng&quot: 51.3634,

&quotpassenger&quot:&quotمهدی مرادلو&quot,

&quotamount&quot: 3800000,

&quotcellphone&quot: &quot+989121112233&quot

}

{کارکرد کلی سیستم به این شکل بود که موقعیت رانننده برای Broker ارسال میشد و Broker هم سفر های مربوط به موقعیت مکانی راننده رو براش PUSH میکرد حالا میشد مختصات موقعیت مکانی مختلفی رو به سمت BROKERارسال و اطلاعات کامل سفرها رو دریافت کرد مهاجم با نوشتن یک برنامه و ارسال خودکار و دریافت اطلاعات می تونست به اطلاعات کل سفرهای کشور دسترسی داشته باشد وبا ذخیره اطلاعات در پایگاه داده یک بیگ دیتا از کل سفرهای اسنپ داشته باشه.

این آسیب‌پذیری در سال ۱۴۰۰گزارش شد و در مدت زمان کوتاهی برطرف شد. اسنپ بابت این آسیب‌پذیری ۵۰ میلیون تومان پاداش پرداخت کرد.برای مشاهده برنامه باگ بانتی اسنپ و ارسال می تونید به لینک زیر مراجعه کنید.

https://snapp.ir/bugbounty/