آشنایی کامل با آسیب پذیری SSRF


به این مطلب امتیاز دهید

آسیب پذیری Server-Side Request Forgery (همچنین به عنوان SSRF شناخته می شود) یک باگ امنیتی وب است که به هکر اجازه می دهد تا برنامه سمت سرور را وادار کند تا به یک مقدار ناخواسته درخواست بزند.

 وب سایت ها می توانند درخواست ها را بین سرورهای HTTP تبادل کنند. مانند به‌روزرسانی‌های نرم‌افزار، یا وارد کردن metadata از یک URL یا یک برنامه دیگر استفاده می‌شوند. چنین درخواست ها بین سروری به طور کلی خطرناک نیستند، مگر اینکه به درستی اجرا نشوند، می توانند سرور را در برابر server-side request forgery یا SSRF آسیب پذیر کنند.

یک حمله موفقیت آمیز SSRF اغلب می تواند منجر به اقدامات غیرمجاز یا دسترسی به داده هایی در داخل سازمان شود.

اگر مهاجم بتواند پارامتر url را به localhost (رابط Loopback) تغییر دهد، ممکن است به آنها اجازه دهد منابع داخلی روی سرور را مشاهده کنند و آن را در برابر server-side request forgery آسیب پذیر کند.

اگر هکر بتوانند مقصد درخواست‌های سمت سرور را کنترل کنند، این امر مجموعه‌ای از فعالیت‌های خطرناک را باز می‌کند و به طور بالقوه به آنها اجازه می‌دهد:

 

  • دور زدن لیست IP 
  • دور زدن سرویس های احراز هویت مبتنی بر سرویس
  • خواندن منابع وب و سایر دارایی های مفیدی که برای عموم قابل دسترسی نیستند، به عنوان مثال API های metadata در محیط های AWS یا trace.axd در ASP.NET
  • اسکن پورت  در شبکه داخلی سرور
  • خواندن فایل های وب سرور
  • خواندن اطلاعات حساس مانند آدرس IP سرور وب که در پشت یک reverse proxy اجرا می شود

 

چرا server-side request forgery خطرناک است؟

در حالی که بسیاری از آسیب‌پذیری‌های وب مستقیماً بر سیستم هدف تأثیر می‌گذارند، آسیب پذیری SSRF به مهاجمان اجازه می‌دهد تا از هدف به عنوان یک واسطه استفاده کنند که درخواست‌ها را به سیستم سوم ارسال می‌کند. بنابراین در حالی که یک حمله SSRF ممکن است به خودی خود آسیب زا نباشد، می تواند دسترسی هکرهای مخرب را به سیستم های داخلی که هرگز قرار نبود از طریق اینترنت قابل دسترسی باشند، فراهم کند. دلایل مختلفی برای خطرناک بودن این موضوع وجود دارد.

 

بهره‌برداری از باگ SSRF،  هکر می‌تواند  محدودیت‌هایی را که برای تعامل با سرورهای دیگر که به وب سایت آسیب‌ پذیر اعتماد دارند دور بزند. این می تواند به معنای استخراج اطلاعات یا ایجاد درخواست های مخرب برای تعامل با پورت هایی باشد که از شبکه بیرونی قابل دسترسی نیستند. با آسیب پذیری SSRF، یک هکر  می‌تواند اقدامات مخربی را روی سرور مورد نظر انجام دهد که در غیر این صورت از بیرون امکان‌پذیر نخواهد بود.

 

تصور کنید یک وب سایت با سرویسی دارید که به شما امکان می دهد تصاویر  را از یک سورس خارجی دریافت کنید تا بتواند ابعاد آنها را تغییر دهید. به عنوان یک کنترل امنیتی، سرویس بررسی می‌کند که آیا پاسخ دریافتی از سورس با content-type صحیح (image/jpeg) می‌باشد یا خیر. اگر هدر content-type وجود نداشته باشد یا نوع محتوای متفاوتی را مشخص کند، سرویس فرض می‌کند که قالب تصویر متفاوتی ارائه شده است و پیام خطا را برمی‌گرداند “لطفا فقط تصاویر JPEG را ارائه دهید.” اگر مشکلی در اتصال به سورس وجود داشته باشد، خطایی با مقدار “هیچ تصویری یافت نشد!” نمایش داده می شود

 

بیایید ببینیم هکرها چگونه می‌توانند از ورودی‌های مختلفی استفاده کنند که بر پاسخ سرویس تأثیر می‌گذارند تا مشخص کنند آیا هاست فعال است یا نه:

 

اگر به

 https://victim.com/image.php?url=https://example.com/picture.jpg

 

 درخواست بزنیم، ارتفاع و عرض تصویر را دریافت می کنیم، به این معنی که این یک عکس معتبر با محتوای صحیح است.

 

بیایید یک درخواست HTTP متفاوت را امتحان کنیم و با ارسال

 https://victim.com/image.php?url=https://example.com/index.html

 

 به جای تصویر، یک فایل HTML را به سرور بدهید. اکنون پاسخ سرویس این است: “لطفا فقط تصاویر JPEG ارائه دهید”، زیرا صفحه ارائه شده دارای هدر content-type اشتباه است (text/html به جای image/jpeg).

 

حالا بیایید ببینیم برای یک URL نامعتبر مانند

 

 https://victim.com/image.php?url=https://example.invalid

 

چه اتفاقی می افتد. این درخواست اروری مقدار “تصویر یافت نشد” را برمی‌گرداند، به این معنی که در ارتباط با سورس خطایی رخ داده است.

 

اکنون که می دانیم برنامه برای ورودی های مختلف چگونه رفتار می کند، می توانیم از آن بهره‌برداری کنیم. ما می دانیم که یک URL معتبر با  هدر content-type   نادرست، این خطا را برمی گرداند: “لطفا فقط تصاویر jpeg ارائه دهید.” بیایید درخواست زیر را با یک URL داخلی ارسال کنیم:

 

https://victim.com/image.php?url=127.0.0.1:3306

 

اگر با خطای Image not found مواجه شدیم، به این معنی است که هیچ پاسخی از هاست 127.0.0.1 در پورت 3306 وجود ندارد. با این حال، اگر فقط تصاویر jpeg را ارائه دهید، به این معنی است که سرور داخلی پاسخ داده است، بنابراین یک سرویس در حال اجرا است.  به این ترتیب، ما می‌توانیم از برنامه وب آسیب‌پذیر برای بررسی آدرس‌های IP داخلی و پورت‌های مختلف برای انجام یک اسکن کامل استفاده کنیم. در واقع، چنین آسیب‌ پذیری SSRF به هکرها اجازه می‌دهد تا اسکن پورت را بدون استفاده از اسکنر پورت  انجام دهند.

 

برخی از برنامه ها ورودی های حاوی hostname مانند 127.0.0.1 و localhost یا URL های حساس مانند /admin را مسدود می کنند. در این شرایط، اغلب می توانید با استفاده از تکنیک های مختلف فیلتر را دور بزنید:

 

  1. با استفاده از  IP جایگزین 127.0.0.1، مانند 2130706433، 017700000001، یا 127.1.

 

  1. ثبت domain name خود به صورتی که به 127.0.0.1 resolves شود. برای این منظور می توانید از spoofed.burpcollaborator.net استفاده کنید.
  2. مبهم سازی رشته های مسدود شده با استفاده از  URL encoding یا تغییر حروف کوچک.

 

برخی از برنامه‌ها فقط ورودی‌هایی را مجاز می‌کنند که با white list مقادیر مجاز مطابقت داشته باشد، شروع شود یا حاوی فهرست سفید باشد. در این شرایط، گاهی اوقات می‌توانید با استفاده از ناهماهنگی‌ها در تجزیه URL، فیلتر را دور بزنید.

 

مشخصات URL حاوی تعدادی ویژگی است که ممکن است هنگام پیاده سازی تجزیه موقت و اعتبارسنجی URL ها نادیده گرفته شوند:

 

می‌توانید با استفاده از کاراکتر @، اعتبارنامه‌ها را قبل از hostname در URL جاسازی کنید. مثلا: 

https://expected-host@evil-host

 

می توانید از کاراکتر # برای نشان دادن یک URL fragment استفاده کنید. مثلا:

 https://evil-host#expected-host

 

می توانید از ترکیب این تکنیک ها با هم استفاده کنید.

آسیب‌پذیری‌های blind SSRF زمانی به وجود می‌آیند که می‌توان برنامه‌ای را وادار کرد که درخواست HTTP پشتیبان را به URL ارائه‌شده صادر کند، اما پاسخ درخواست back-end در پاسخ جلویی برنامه برگردانده نمی‌شود.

بهره برداری از blind SSRF  معمولا سخت تر است، اما گاهی اوقات می تواند منجر به اجرای کامل کد از راه دور روی سرور یا سایر اجزای پشتیبان شود.

شناسایی بسیاری از آسیب‌پذیری‌های ssrf نسبتاً آسان است، زیرا ترافیک عادی برنامه شامل پارامترهای درخواست حاوی URLهای کامل است. یافتن نمونه های دیگر SSRF دشوارتر است.

 

بدون دیدگاه

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

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