سلام علی خلخالی هستم. علاقه مند به حوزه امنیت و باگ هانتر. توی این رایتاپ میخوام از مرحله ریکان تا رسیدن به آسیب پذیری SSRF و virtual-host discovery رو براتون توضیح بدم و همچنین از تست هایی که انجام شد و نتیجه ای نداشت هم براتون میگم که شاید دید خوبی بهتون داد.

ریکان

سابدامین هایی که روشون آسیب پذیری کشف شد با ابزار subfinder پیدا شدند.

Subfinder یک ابزار هست که از data sourceهای پولی و رایگان برای پیدا کردن سابدامین استفاده میکنه. حتما پیشنهاد میشه صفحه subfinder در گیتهاب رو مطالعه کنید.

مرحله بعد از سابدامین هارو پایپ کردم توی httpx تا ببینم داستان از چه قراره 🙂

ابزار httpx یک ابزار اسکنر هست که به شما کمک می کنه تا بررسی کنید که آیا یک سرور روی پروتکل HTTP و HTTPS در دسترس هست یا نه. با استفاده از این ابزار می توانید به سرعت و با دقت بالا اطلاعاتی مانند وضعیت سرور، کد وضعیت HTTP، آدرس IP و پورت سرور، و نام سرور رو به دست بیارید. حتما پیشنهاد میشه صفحه httpx در گیتهاب رو مطالعه کنید.

توی این مرحله بعد از برسی چشمی چند سابدامین جذاب مثل id-mng.notsafe.shop (برای اینکه سابدامین مخففID Manager هست). رفتم سراغ chat-supports.notsafe.shop.

ریکان وب اپلیکیشن

پروکسی مرورگر رو ست کردم روی برپ و شروع به کار کردن با اپلیکیشن کردم. اول از همه وقتی https://chat-supports.notsafe.shop رو باز کردم یک صفحه با status code 200 روبرو شدم که توی سورس صفحش همچین کد جاوااسکریپتی بود:

توضیح کد بالا: اگر کوکی به نام chat_session وجود نداشت، ریدایرکتش کنه به id-mng.notsafe.shop که OAuth Provider هست در غیر این صورت بفرستش به https://chat-supports.notsafe.shop/chat.

بعد از احراز هویت شدن و گرفتن chat_session به chat/ ریدایرکت شدم و صفحه چت برام لود شد.

توی این مرحله یک فاز به استفاده از auth cookie که اینجا chat_session بود انجام دادم ولی به اندپوینت دیگه ای نرسیدم.

توی این فلو authenticate with oauth یک اسیب پذیری وجود داشت که low بود و گزارش ندادم. اسیب پذیری این بود که مقدار state توسط وب اپلیکشین بعد از بازگشت از طرف OAuth provider به اپلیکیشن، مقدارش چک نمیشد و این امر باعث CSRF می شد.

سناریو حمله به این صورت بود: من یک لینک به کاربری که توی oauth provider لاگین بود می دم و وقتی کاربر اون لینک رو باز کنه توی chat-support.notsafe.shop کوکی chat_session رو می گیره و authenticate میشه. توی رایتاپ بعدی این مورد رو باز میکنم. ولی خب الان بگذریم.

شروع تست برای کشف آسیب پذیری

تست هایی زیادی رو انجام دادم ولی چنتا رو براتون گلچین کردم.

تست اول – بدون نتیجه

صفحه چت رو دیدم. سعی کردم پیلود blind XSS تزریق کنم ولی دیدم ورودیم html encode می شد.

 سورس جاوااسکریپت صفحه رو برسی کردم و متوجه شدم که دیتا از طریق وب‌سوکت ارسال و ریسپانس بدون هیچ فیلتری با استفاده از سینک innerHTML به DOM صفحه اضافه می شد. به زبان ساده فلو اینجوری بود که پیام من از طریق وب‌سوکت به سرور ارسال میشد و پاسخ سرور توی صفحه نمایش داده می شد.

html encode سمت کلاینت یا سمت سرور می تونه انجام بشه. اینجا این اتفاق داشت سمت سرور رخ میداد و قابل دور زدن نبود. ولی اگر سمت کلاینت بود می شد به XSS رسید.

تست دوم – کشف SSRF

توی تست بعدی یک URL ارسال کردم تا واکنش وب اپلیکیشن رو ببینم. برای اینکه اکثر صفحه چت ها وقتی لینکی توی پیام باشه یک بخش از بادی و تایتل صفحه رو توی یک کادر کوچیک نمایش میدن. https://google.com رو وارد کردم و بله همین اتفاق افتاد. تایتل صفحه رو نمایش داد.

 باز اینجا دوحالت وجود داشت. یا جاوااسکریپت سمت کلاینت این درخواست رو ارسال می کرد و این دیتا رو نمایش می داد یا سمت سرور این درخواست ارسال میشد و توی ریسپانس دیتا رو برمی گردوند. فرضیه اول امکان پذیر نیست برای اینکه Same Origin Policy اجازه این کارو نمیده.
اینجا این اتفاق سمت سرور اتفاق می افتاد

خب URL سایت خودمو دادم و لاگشو چک کردم. نتیجه:

همونجوری که میتونید حدس بزنید SSRF داشتیم و تونستم به IP سرور که پشت CDN بود برسم. تست هایی دیگه ای انجام دادم که نتیجه نداشت ولی باید تست می شدند.

تست سوم – بدون نتیجه

از اسکیم جاوااسکریپ استفاده کردم که اگر وب اپلیکیش با اون بصورت لینک برخورد میکرد و توی اتریبیوت تگ a میزاشت XSS می بودو یا میتونستم https://memoryleaks.ir/q=" رو ارسال کنم تا ببینم میتونم از اتریبیوت href بریک کنم یا نه که نتیجه ای نداشت.

تست چهارم – بدون نتیجه

وقتی که آدرس سایتی میزاشتیم تایتل اون صفحه رو توی سورس نمایش میداد و اینجا از تگ توی تایتل صفحه استفاده کردم و لینکشو توی چت ارسال کردم html encode می شد. اگر نمی شد میتونستیم XSS داشته باشیم.

کد صفحه:

ریسپانس:

 برای هرکدوم از این تست ها بایپس های زیای رو هم تست کردم ولی نتیجه ای نداشت. خب بریم سراغ باگ اصلی.

شروع کار با IP – دایی جان واقعا IP خوبی داری:)

IP سرور رو پورت اسکن کردم و به این پورت ها رسیدم.

تست برای پیدا کردن virtual-host

پورت های باز رو تست کردم ببینم پشتشون Web‌ Serverهست که از http و https ساپورت میکنند یا نه و روی اون هایی که ساپورت می کردند با سابدامین هایی که پیدا کردم virtual-host discovery کردم و http://88.99.44.113:8000/  یک virtual-host پیدا شد

رسیدن به access.log

خب خب. بعدش رفتم سراغ فاز دایرکتوری و فاز فایل. من از وردلیست raft استفاده کردم که به access.log رسیدم

که توش اندپوینت،توکن،کد، ایپی و… بود.

ریپورتش رو نوشتم و گزارش دادم که high بسته شد.

حساب تویتر، اینستاگرام و وریوکس اکادمی من که می تونید باهام در ارتباط باشید.

خیلی ممنونم که این رایتاپ رو خوندید. امیدوارم خوشتون اومده باشه.