چگونه با گزارش آسیب پذیری SSRF پول دربیاوریم؟

چگونه با گزارش آسیب پذیری SSRF پول دربیاوریم؟

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

آسیب پذیری SSRF- نتیجه مطالعه 124 گزارش باگ بانتی

در تئوری، SSRF یک کلاس آسیب‌پذیری بسیار ساده است، طوریکه می‌توانید از مکان های دلخواه درخواست ارسال کنید. بااینحال درعمل، اغلب چیز پیچیده‌تری است.

کجاها دنبال SSRF بگردیم؟

اغلب چه پارامترهایی بیشتر درمعرض آسیب‌پذیر بودن هستند؟

آیا ما واقعا به این پل‌لودهای پیچیده با انکودینگ‌های اوکتال یا کاراکترهای یونی‌کد نیاز داریم؟

ما به دنبال پاسخ این پرسش‌ها بودیم. از اینرو، 361 گزارش SSRF را از اینترنت برداشتیم، فیلتر کردیم و برای اینکه بدانیم چگونه افراد با SSRF ها پول درمیاورند، آنها را دسته بندی کردیم.

روش مطالعه

این مطالعه در 3 مرحله انجام شد: جمع آوری گزارش‌ها، برچسب‌گذاری و تحلیل و بررسی

جمع‌آوری نتایج

ما به صورت عمده از 2 منبع برای گردآوری گزارش‎‌ها استفاده کردیم. اولین منبع، داده های بدست‌آمده از لیست رایت‌آپ های Pentester Land  بود و دومین منبع ما جستجو در موتور جستجوی گوگل برای گزارش‌های SSRF ثبت شده در HackerOne بود.

سپس، تمام این داده ها را وارد Notion کردیم تا مشکلات آنها را رفع کنیم. برخی از ردیف ها با “&” ایجاد شده بودند، برخی از پاداش ها با ارزهای مختلفی پرداخت شده بودند و چند مشکل دیگر که برای تحلیل و بررسی درست بایستی رفع می‌شدند.

همچنین بایستی نتایج را از فیلتر گزارش‌های Pentester Land برای بررسی SSRF ها هم رد می‌کردیم.

نتایج بدست آمده جمعا 361 گزارش بود. ما جامعه آماری مان را به گزارش هایی محدود کردیم که پاداش هم دریافت کرده بودند که درآخر 160 گزارش برای ما باقی ماند.

برچسب‌گذاری

سپس ما شروع به برچسب‌گذاری تک تک گزارش‌ها کردیم. برای اینکار، گزارش ها را باز می‌کردیم، مطالعه می‎‌کردیم و داده ای که می‌خواستیم بیرون بکشیم را نشانه گذاری می‌کردیم.

ازجمله:

  • عملکرد آسیب‌پذیری
  • نام پارامتر آسیب‌پذیری
  • روش دورزدن آدرسی که از آن استفاده شده بود
  • اینکه آیا SSRF اجازه خواندن پاسخ ها را داده بود یانه
  • و اثرات آسیب‌پذیری

برای تمام این موارد، در پایگاه داده Notion برچسب هایی ایجاد کردیم. درابتدا، برچسب های ما بسیار جزئی بودند، اما هرچه بیشتر در مساله عمیقتر شدیم متوه شدیم که کدام یک از این برچسب ها معنا دارهستند، کدام یک خیلی خاص هستند و کدام یک حالت کلی تری دارند.

همچنین، درزمان جستجو برای گزارش ها متوجه شدیم که تنها بخشی از برخی از گزارش ها افشا شده است. تلاش کردیم تا اطلاعات مفیدی از خلاصه گزارش بیرون بکشیم ولیکن دراکثر مواردامکان پذیر نبود. علاوه براین، هر گزارشی که باگی در وب اپلیکیشن نداشت یا کمی نتایج مثبت کاذب داشت را نیز نادیده گرفتیم.

که درنهایت 124 گزارش برای ما باقی ماند.

تحلیل و بررسی

اینکه بتوانیم با حفظ سطح جزئیات برچسب های کلی کاربردی هم تولید کنیم کمی برایمان چالش برانگیز بود. پس از اولین دوره برچسب‌گذاری، برچسب هایی که نتایج پایینی داشتند را دوباره بررسی و آنها را به دسته های کلی تر اضافه کردیم.

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

چه توابعی برای SSRF ها آسیب پذیر هستند؟

اولین برچسب، برچسب تابع بود. سوالی که بااین برچسب به دنبال جواب آن بودیم این بود، درچه مکان‌هایی بیشترین احتمال وجود SSRF وجود دارد؟

آسیب پذیری ssrf

اپلیکیشن های خاص / ناشناخته، 34 گزارش

اینها توابعی هستند که اختصاصی برای یک اپلیکیشن خاص بودند یا تابع در گزارش ذکر نشده بود.

ایمپورت کردن با URL، 22 گزارش

رایج ترین عملکردهای آسیب‌پذیری SSRF ایمپورت کردن منابع از URLهاست. دراکثر موارد این آسیب پذیری ها روی تصاویر بودند. به نظر من این مورد چیز زیاد شگفت انگیزی نبود، چراکه همه ما زمانیکه بااین تابع روبه رو می‌شویم به‌دنبال SSRF ها می‌گردیم.

از این 22 گزارش، تنها 7 گزارش به مهاجم پاسخ full-read دادند.

آپلود فایل، 17 گزارش

آسیب‌پذیری های مربوط به آپلود فایل دومین آسیب پذیری رایج گزارش شده است. از 17 گزارش ثبت شده، 7 گزارش مربوط به XXE ها بود و 6 تای آنها مربوط به ffmpeg CVE ها بود.

مرورگر هدلس / تفسیر HTML، 9 گزارش

از 9 گزارش ثبت شده برای مرورگرهای هدلس، 7 گزارش مربوط به SSRFهای Full-read بود. این به این معناست که اگر شما در یک تابع یک SSRF پیدا کردید که روی HTML بک اند که معمولا به منظور تولید فایل PDF یا فایل تصویر رندر می‌شود، پاداش خوبی می‌توانید بدست آورید.

وب هوک‌ها / بررسی وضعیت سرور، 8 گزارش

این توابع نیز محل های کاملا واضحی برای گشتن به دنبال SSRF ها هستند. دراین میان بالاترین پاداش تعلق گرفته 31.337$ برای یک SSRF است.

Proxyها ، 8 گزارش

یکی‌دیگر از توابع آسیب‌پذیری وابسته به SSRF ها پروکسی کردن بود. 8 گزارش با این آسیب‌پذیری ثبت شده بود. بیشی از نیمی از آنها از پارامتر url استفاده کرده بودند.

باگ مکانیزم امنیتی / کتابخانه ای، 7 گزارش

این گروه بیشتر دربرگیرنده باگ های کتابخانه های مکانیسم های امنیتی ای است تا اپلیکیشن های خاص. این 7 گزارش شامل گزارش های من از Stripe درباره Smokescreen و 2 گزارش از سایر هانترها با استفاده از مکانیزم دورزدن به منظور همان عملکرد است.

یکپارچه‌سازی ذخیره‌سازی فایل، 7 گزارش

این باگ ها با سرویس هایی مثل گوگل درایو یا آمازون S3 یکپارچه شده بودند. باگی که بالاترین پاداش را گرفته بود سال پیش به Dropbox گزارش شده بود.

یکپارچه سازی نگهبانی (Sentry integration)، 4 گزارش

4 گزارش درمورد SSRF در Sentry integration وجود داشت. این مساله برای من خیلی شگفت‌انگیز بود، چراکه دقیقا از نحوه کار این حمله چیزی نمی‌دانستم. این آسیب پذیری‌ها در سال‌های 2018 و 2019 گزارش شده بودند، به همین خاطر گمان می‌کردم که دیگر اکنون کارایی نداشته باشند، اما شاید ارزش اش را داشته باشد که در سال 2022 هم تلاش کنیم تا چیزهای مشابعی پیدا کنیم.

باگ مسیردهی (Routing)، 3 گزارش

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

سربرگ هاست، 2 گزارش

2 گزارش وجود داشت که درآن‌ها اپلیکیشن بااستفاده از سربرگ هاست درخواست ایجاد می‌کرد. هردوی این گزارش ها blind بودند و در سال 2018 گزارش شده بودند.

پیکربندی ایمیل، 2 گزارش

2 گزارش وجود داشت که درآن هانتر می توانست دامنه های ایمیل را پیکربندی کند و از آن برای  بدست آوردن SSRF های کور استفاده کند.

خط اول درخواست، 1 گزارش

درنهایت، 1 گزارش درباره استفاده از خط اول درخواست در SSRRF بود. درحالت عادی، من سعی کردم تا توابع را تنها بااستفاده از یک گزارش حذف یا تجمع کنم، اما این یک نمونه را گذاشتم که بماند:

  • پاداش این گزارش 8.600$

پارامترهایی که می توانید به وردلیست تان اضافه کنید

دراین بخش اسم پارامترهایی که از گزارش‌های ارائه شده بیرون کشیدم قرار داده ام. اکثر آناه پارامترهای GET، POST یا JSON بودند، بااستثنا موراد زیر:

  • پارامترهای مسیری مثل example[.]com/path/SSRF-PAYLOAD/
  • هاست و X-Forwarded-For هدرها

پارامترهای آسیب پذیری ssrf

url

u

src

endpoint

srcURL

remote_attachment_url

 q

link

import_url

images

image[src]

image

id

html

ewsUrl

downloadpath

destination

consumerUri

 add_imageurl

 

منبع

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

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