آشنایی با حمله SSRF

آشنایی با حمله SSRF

SSRF مخفف Server Side Request Forgery است و به نفوذگر اجازه ارسال درخواست‌هایی با امضاهای جعلی به سمت یک سرور آسیب‌پذیر را می دهد و چون این سرور آسیب پذیر است، درخواست‌ها معتبر شناخته می‌شوند و به عنوان یه نود معتبر در شبکه معرفی می‌شود.

از این طریق کنترل‌های فایروال پشت سر گذاشته شده و نفوذگر به سرویس‌های داخل شبکه دست پیدا می‌کند.

تصور کنید یک وب سرور عمومی در شبکه یک شرکت به آدرس زیراست:

public.site.com

این آدرس یک سرویس پراکسی را در public.site.com/proxy هاست می‌کند که صفحات وب  که در پارامتر url مشخص شدند را پردازش و به کاربر نمایش می‌دهد. تصور کنید کاربر درخواست زیر را ارسال می‌کند

https://public.site.com/proxy?url=google.com

در این شرایط، وب اپلیکشن  صفحه گوگل را نمایش می‌دهد

آشنایی با حمله SSRF

حال تصور کنید admin.site.com  یک سرور داخلیست که یک پنل مخفی ادمین را هاست می‌کند.

برای آنکه مطمئن شوند که فقط کارمندان می‌توانند به این صفحه دسترسی داشته باشند، Access control را طوری تنظیم مرده‌اند که از بیرون و عملاً اینترنت کسی به آندسترسی نداشته باشد و فقط کسانی به آن دسترسی پیدا کنند که یک IP معتبر داخلی داشته باشند (مثلاً یکی از workstation های کارمندان).

حال اگر یک کاربر تقاضای زیر را بدهد چه اتفاقی می‌اُفتد؟

https://public.site.com/proxy?url=admin.site.com

اگر مکانیسم کنترل SSRF نداشته باشند، چون درخواست از Public.site.com ارسال شده است و یک ماشین معتبر داخل شبکه است، صفحه ادمین به کاربر نمایش داده می‌شود. درواقع درخواست‌های نامعتبر که در حالت عادی توسط فایروال بلاک می‌شدند، الان اجرا می‌شوند!

حال با استفاده از این وضعیت، نفوذگر می‌تواند هر نوع درخواست را روی شبکه ارسال کند و بسته به اینکه آن سرور چه دسترسی‌هایی دارد، نفوذگر می‌تواند فایل‌های حساس داخل شبکه را بخواند یا API های داخلی را صدا بزند و یا مثل حالتی که توضیح داده شد به بخش‌های مخفی مخصوص مدیران دست پیدا کند.

انواع SSRF

۲ نوع SSRF وجود دارد:  Regular SSRF یا SSRF معمولی و Blind SSRF.

مکانیسم‌های هردوی آنها یکسان است و عملاً اعتماد بین ماشین‌های روی یک شبکه را مورد هدف قرار میدهند و exploit می کنند، تنها تفاوتی که بین این دو است در این است که در Blind نفوذگر بازخوردی از سمت سرور به وسیله درخواست های HTTP یا error message ها دریافت نمی کند.

هرچند این موضوع کمی استخراج داده‌ها و exploit کردن شبکه را سخت‌تر می کند اما با این حال برای نفوذگر با ارزش است.

چطورSSRF پیدا کنیم؟

بهترین راه پیدا کردن این نوع آسیب‌پذیری‌ها این است که به صورت دستی code review کنیم و بررسی کنیم که آیا تمامی ورودی‌های URL به صورت درست اعتبارسنجی می‌شوند یا خیر؟

البته همیشه نمی‌توانیم این کار را انجام دهیم و دسترسی کامل به کد نداریم، بنابراین باید تمرکز خود را روی ویژگی‌هایی که نشان دهنده SSRF هستند بگذاریم.

همان‌طور که اشاره کردم SSRF زمانی اتفاق می‌افتد که یک سرور به منابع خارجی نیاز داشته باشد.

به طور مثال، بعضی وقت‌ها یک وب اپلیکیشن نیاز دارد تا از روی URL یک عکس، thumbnail درست کند یا مثلاً نیازدارد تا ازروی یک ویدیو از سایت دیگر یک Screen shot داشته باشد (مثلاً youtube.com یا aparat.com). اگر سرور دسترسی به منابع داخلی خودش را درست محدود نکرده باشد، SSRF اتفاق می افتد.

فکر کنیم صفحه زیر که روی public.site.com است به کاربران اجازه دهد تا عکس خودشان را از طریق اینترنت آپلود کنند

https://public.site.com/upload_profile_from_url.php?url=www.google.com

برای این که test.jpeg را پردازش کند، اول باید سراغ محتویات google.com رفته و آن را بخواند. اگر سرور تفاوتی بین منابع داخلی و خارجی قائل نشده باشد، یک نفوذگر به راحتی می‌تواند درخواست زیر را ارسال کند:

https://public.site.com/upload_profile_from_url.php?url=localhost/password_file.txt

و همان‌طور که از اسم فایل مشخص است، می تواند فایل محتویات پسوردها را نمایش دهد.

ویژگی‌هایی که معمولاً نسبت به SSRF آسیب‌پذیر هستند عبارتند از: webhook ها، فایل آپلودها به وسیله URL، پردازشگرهای اسناد و تصاویر، link expansion ها و سرویس های پراکسی! در واقع همه این ویژگی ها نیاز دارند تا منابع خارجی را مشاهده و پردازش کنند.

تست کردن SSRF معمولاً با آماده کردن ورودی URL با یک آدرس داخلی شروع می‌شود. حالا بسته به config شبکه ممکن است نیاز باشد چندین سرور مختلف تست شوند. مثلاً آدرس های زیر همان اول تست می شوند:

  • ۱۲۷٫۰٫۰٫۰/۸
  • ۱۹۲٫۱۶۸٫۰٫۰/۱۶
  • ۱۰٫۰٫۰٫۰/۸

در لینک زیر می توانید یک SSRF جالب که اردیبهشت ۹۷ از Shopify گرفته شده است و ۲۵۰۰۰ دلار بانتی دریافت شده است را ببینید

https://hackerone.com/reports/341876

این مطلب به امید خدا در آینده به‌روزرسانی خواهد شد

0 پاسخ

پاسخ دهید

میخواهید به بحث بپیوندید؟
مشارکت رایگان.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *