server side request forgery (SSRF) ثغرة ال

مقدمة

ثغرة ال SSRF من الثغرات الخطيرة فى تطبيقات الويب والثغرة دى بتسمح للمهاجم Attacker أنوا يستخدم ال web server نفسه ويخليه يبعت HTTP Request لأى Domain تانى أو حتى يبعت لنفسه أو للشبكة الداخلية

ايه اللى ممكن يحصل بسبب وجود الSSRF ؟

1- ممكن توصل لتطبيقات تانية شغالة على الشبكة الداخلية زى ال admin panel مثلا

2- ممكن تعمل فحص scan للشبكة الداخلية

3- ممكن تؤدى ل remote code execution

4- ممكن تؤدى ل Denial of service Attack

5- ممكن توصل لبيانات أو تطبيقات حساسة على نفس ال server

الاختبار

ازاى نبحث عن ثغرات الssrf؟ (ايه اشهر الاماكن اللى ممكن تكون موجودة فيها؟)

1- خاصية ال File upload

بعض التطبيقات بتسمحلك انك تحمل صورة أو ملف عن طريق ال URL, الخاصية دى ممكن تكون مصابة بثغرة ال SSRF

2- ال HTTP Request Parameters

بعض ال HTTP parameters زى page, url, domain ممكن تكون بتستخدم لغرض معين وفى نفس الوقت ممكن تكون مصابة بثغرة ال SSRF

3- ال Referer Header

ال Referer Header دى بتعرف الموقع اللى أنت بتزورة أنت جاى منين, على سبيل المثال لو أنت بحثت عن موضوع معين فى جوجل وبعدين ضغطت على link الموقع اللى أنت فتحته هيعرف ان انت جاى من جوجل عن طريق الReferer header

بعض خدمات تحليل سلوك المستخدمين اللى بتكون شغالة على جانب السيرفر (server-side analytics services) بتعمل log للURL اللى فى ال Referer header وفى الغالب بتبعت Request لل URL دا

4- من خلال ثغرة ال XXE

ممكن تستغل ثغرة ال SSRF من خلال وجود ثغرة Xml External Entity (XXE)

المثال رقم 1: Image Downloader App

فى المثال دا هنستخدم Application المفروض أنوا بياخد رابط خاص بصورة ويعملها Download زى ما هو واضح فى الصورة

دا شكل ال Request اللى بيروح لل server

دلوقتى هنجرب نبدال ال image_url لل localhost ip علشان نحاول نوصل لأى تطبيقات داخلية على ال server

ممكن نجرب ال common ports او نحاول نعمل scan على نطاق معين أو نعمل scan على ال ports كلها ونشوف النتائج

تقدر تعمل scan عن طريق ال burp intruder أو باستخدام أداة FFUF

لاحظ ال Response هتلاقي الصورة تالفة

لو بصيت على ال source code هتلاقي ال URL بتاع الصورة

قدرنا نوصل ل App تانى على ال server

المثال رقم 2: website check app

هنختبر هنا ال Blind SSRF : يعنى مفيش Response كل اللى نقدر نعرفه هو ال host شغال ولا لا ولو شغال هنقدر نعرف ال ports للى مفتوحه عليه (هنعمل port scanning)

فى الصورة دى بعتنا request لموقع عادى example.com رجعلنا أن الموقع شغال بدون أى تفاصيل (response body)

فى الصورة التانية بعتنا Request لموقع مش موجود أصلا ال server رجعلنا Error واضح من ال Error ان الموقع مش موجود اصلا

فى الصورة الاخيرة بعتنا Request لل localhost IP Address ومن الواضح ان فى تطبيق شغال على port 13337

هل استخدام ال blind SSRF بيقتصر على ال port scanning فقط؟

الاجابة: لا, ممكن ال blind SSRF تؤدى لنتائج خطيرة على سبيل المثال ممكن أستخدمها فى ان اعمل Enumeration لكل hosts اللي فى ال internal network وال ports للى مفتوحة عليها, وبعيدن أبحث عن products معينة بتشتغل على نفس ال ports اللى لقيناها مفتوحة ونجمع كل ال Exploits المعروفة لل products دى ونجرب ال payloads اللى ممكن تشتغل مع ال GET Requests

المثال رقم 3: fake profile app

فى المثال دا هنستغل ثغرة ال SSRF عن طريق عن طريق ثغرة ال Cross Site Scripting (XSS)

ايه وظيفة ال App دا؟ ال App بياخد من المستخدم username و bio ويخزنهم فى ال database وبعدين يرجع يعرضهم فى صفحة تانية وبيسمح للمستخدم انه ينزل ال profile الخاص بيه كملف PDF عن طريق أنو بحول البيانات الخاصة بالمستخدم من HTML ل PDF

ايه مشكلة ال App ؟ مشكلة ال App هى أنه مصاب بثغرة XSS بالتالى ال Attacker ممكن يعمل Inject ل HTML tag زى iframe ويخلى ال src بتاعه local ip address او local file والبرنامج اللى بيحول الHTML ل PDF هيحمل معاه ال App اللى شغال على ال server أو ال internal network

فى الصورة دى بعتنا البيانات الخاصة بالمستخدم ولاكن بدل ال bio بعتنا HTML iframe, ال App حفظ البيانات فى ال data base وعملنا redirect على على المسار profile مع ال username parameter

لو بصينا على ال Response هنلاقى ان ال App مش عامل Sanitization لل Response

الApp علشان يحول ال profile لملف PDF لازم المستخدم يبعت ال TO_PDF Parameter مع ال username

لو بصينا على ملف ال PDF هنلاقى ال app حمل معاه App تانى شغال على نفس ال server

المثال رقم 4: DoS Attack

ممكن ال Attacker يستخدم ال ssrf انه ينفذ هجوم DoS على الشبكة عن طريق أنه يخلى السيرفر يحمل ملفات كبيرة فيستهلك ال bandwidth وبالتالى يعطل الشبكة

المثال رقم 5: SSRF via XXE

زى ما قولت ان ممكن تستغل ثغرة ال SSRF من خلال ال XXE, ال payload بيكون بالشكل دا

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<!ELEMENT foo ANY >
<!ENTITY % xxe SYSTEM "http://internal.service/secret_pass.txt" >]>
<foo>&xxe;</foo>

لما ال XML Parser هيحاول يعمل load ل resource معين هيبعت request لل URL اللى موجود فى ال Payload

الحلول

1- أستخدم white or black list على حسب تصميم التطبيق الخاص بيك: لو التطبيق فيه خاصية بتسمح للمستخدم انه يحمل صورة عن طريق ال URL يبقي تعمل white list بال extensions المسموح بيها (jpg, png, ..) ولازم تتأكد من نوع المحتوى اللى المستخدم بيحمله عن طريق أنك تفحص ال signature الخاصة بالملف

مثال تانى: لو الموقع الخاص بيك فيه ميزة زى أنه بيعمل fetch لأى URL علشان يعرف مثلا عنوان الموقع أو المحتوى اللى فيه, هتستخدم ال black list علشان تمنع أى وصول للشبكة الداخليه أو ال server نفسه زى أنك تعمل block لل requests على ال localhost أو ال IP range الداخلى, ولازم تتأكد من ال ip بتاع ال hostname الاول قبل ما تعمل HTTP request, ممكن ال attacker يضبط ال DNS server بحيث أنه يرد بال 127.0.0.1 مثلا

2- اعمل block لأى URL schemas غير ال HTTP و ال HTTPS على سبيل المثال (gopher://, ftp://, file://, ....etc)

3- لازم التطبيقات اللى شغالة داخليا يكون عليها Authentication