هناك شيء يسمى SSRF. لقد كتب عنها الكثير ، لكن ما زلت أخبركم بإيجاز.
دعنا نقول أنك تذهب إلى الموقع ، وملء الملف الشخصي والوصول إلى عنصر "تحميل الصورة الرمزية". ولديك خيار - تحميل ملف أو تحديد رابط.
في هذه الحالة ، نحن مهتمون بالنقطة الثانية. إذا قدمنا رابطًا لمورد يحتوي على صورة ، فعندئذٍ تطبيق الويب:
- ينزلها
- تحقق من أن الصورة هي الصورة
- التحقق من الأحجام ، لأنها قد لا يصلح
- اعرضه للمستخدم (للقطع)
لذلك هنا. إذا كان الموقع لا يتحقق من حيث يحاول تنزيل الصورة منه ، فهذه ثغرة أمنية (كقاعدة عامة). علاوة على ذلك ، فإن موجهات الهجمات على ميزة صغيرة مثل تنزيل الصور واسعة للغاية بحيث لا يوجد تجمع كافٍ في الشريط لاستعراض جميع الخيارات.
سُئلت ذات مرة - "ماذا يمكنني أن أفعل إذا كان بإمكاني وضع رابط واحد فقط (http)؟ إنه لا يعطي أي شيء! "
انا اقول لك
أسهل خيار هو محاولة تحديد الخدمات في الداخل. إذا كنا نتحدث عن الصورة ، يمكنك محاولة إلقاء نظرة على المسارات القياسية مثل favicon.ico أو الشعارات أو دليل الرموز ، مما يشير إلى استخدام Apache. من خلال إرسال الطلبات ، يمكننا التكرار على العناوين المحلية الشهيرة ، وكذلك النطاقات الفرعية للموقع التي تعمل في البنية التحتية الداخلية. هذه كلها أنواع من الخيزران ، جيرا ، gitlab وغيرها من الأشياء المحبوبة من قبل جميع الشركات.
ما لأنها ضرورية؟ ولكن لأن المعرفة هي القوة. بعد كل شيء ، حتى عمياء ، يمكنك استخدام نقاط الضعف المختلفة ويستغل. بمعرفة البائع أو إصدار خادم الويب أو الخدمة المستخدمة ، يمكنك تضييق نطاق الهجمات التي يمكنك تطبيقها. ربما ليس الآن ، ولكن في المستقبل ، فإن معرفة المعلومات التقنية حول البنية التحتية الداخلية سوف تساعدك في استغلال نقاط الضعف الأخرى.
حسنًا ، لقد مُنعنا من السماح لنا بإدخال عناوين IP. لنفترض أن لدينا بعض الموارد المهمة داخل البنية التحتية وأن عنوان IP الخاص به هو 192.168.1.1
بادئ ذي بدء ، نبدأ عقليا مجالًا سنخصص له عنوان IP هذا. فليكن my-test-site.com. في الحياة الواقعية ، يجب عليك إنشاء نطاقات فرعية سيتم توجيه عنوانها إلى عنوان IP الذي نحتاجه ، ولكن المزيد في هذا المجال لاحقًا.
كلمة القوة الغاشمة
دعونا نحلم أن لدينا جهاز توجيه في الداخل. / admin / الدليل تحت المصادقة الأساسية. من خلال تغيير الرابط ، يمكننا تحديد تسجيلات الدخول وكلمات المرور لجهاز التوجيه. ولكن هنا الأمر بسيط للغاية ، فنحن فقط نشكل رابطًا للنموذج
http://login:password@my-test-site.com/admin/وبالتالي ، فإن القيمة قبل القولون تكون تسجيل الدخول ، وبعد ذلك - كلمة المرور. ومن خلال علامة @ ، سيكون هناك مجال يتم إرسال هذه البيانات إليه. يرجى ملاحظة أنه لا يعمل مع جميع أنواع الاتصال بالأشخاص الذين تحتاج إلى ملء نموذج. لذلك ، هناك حاجة إلى مصادقة أساسية - إطار منبثق به استجابة 401 من الخادم.
إذا كنا محظوظين وكان الموقع سيعرض على الأقل رمز الاستجابة (200 ، 401 ، 503) ، فسيكون ذلك أسهل بكثير. ثم يمكننا أن نلاحظ بوضوح العملية ونرى انتصارنا:
http://admin:password@my-test-site.com/admin/ - 401
http://admin:admin@my-test-site.com/admin/ - 401
http://admin:123456@my-test-site.com/admin/ - 200بإرسال عشرة أو اثنين من هذه الطلبات ، يمكنك محاولة العثور على كلمة المرور لهذا الموجه. ثم انتقل إلى البرنامج النصي لحفظ DNS الخاص بك أو حتى /reboot.cgi
وإذا لم يكن هناك إجابة وهو دائما نفس الشيء؟
هنا التوقيت سوف يساعدنا.
توقيت
كل شيء يستغرق وقتا. بينما أقضي وقتك في قراءة مقال ، فإن الخدمات تأخذ وقتك للرد.
الخصوصية هي أنه يمكننا محاولة الوصول إلى الموارد الداخلية وقياس التوقيت للإجابة على السؤال - هل هناك خدمة هناك أم لا؟
بعد إرسال العديد من الطلبات ، يمكنك الفرز بشكل أعمى عبر الخدمات الداخلية والموانئ وحتى الدلائل والملفات ، بالاعتماد على مجموعة من الإجابات الشاذة.
1302 ms - http://test.company.com
1307 ms - http://db.company.com
5483 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.comاستجاب النطاق الفرعي jira لأطول فترة ، وعلى الأرجح كان في الداخل ، والفرق ملحوظ لأن خادم الويب حاول تحميل الصفحة ، ثم أدرك أن هذه ليست صورة. وما يهمنا ليس حقيقة "من أجاب عن الأطول؟" ، ولكن على وجه التحديد "من أجاب ليس مثل أي شخص آخر؟" لأن التوقيت يمكن أن يكون مثل التأخير - على سبيل المثال ، إذا وجدت ملفًا كبيرًا أو برنامج نصي يستغرق تنفيذه وقتًا طويلاً. أو العكس ، إجابة سريعة.
1302 ms - http://test.company.com
1307 ms - http://db.company.com
423 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.comفي هذه الحالة ، يقول الجواب إنه إما أن يكون 401 أو إعادة توجيه لا يعالج محلل الصور. أو ربما يمكن الوصول إلى الموقع ، ولكن بعد التحقق من البايتات الأولى أو نوع المحتوى ، رفضنا تطبيق الويب الخاص بنا قبل تنزيل الصفحة بالكامل. لم تنتظر المواقع الأخرى في هذا المثال وجود اتصال (أو لم يكن اسم المضيف مضطربًا)
آليات التحقق الملكية الفكرية
لقد أدخلت العديد من المواقع التحقق من أن عنوان IP ليس داخليًا. لكن المنطق قد يكون خاطئًا ، وفي بعض الأحيان لا يزال بإمكانك جعل التطبيق يتصل بعنوان IP الداخلي. على سبيل المثال ، يتحقق الموقع من كتلتين منطقيتين. أولاً ، يتحقق الأمر لمعرفة ما إذا كان المضيف الذي يشير إلى عنوان IP الخارجي قد منحني بدقة. إذا نجح الموقع ، بعد اجتياز الاختبار الأول ، في إنشاء اتصال ، مع عدم تخزين عنوان IP مؤقتًا في الفقرة السابقة ، يمكنك الذهاب للحصول على خدعة مضحكة.
عند الطلب الأول للنطاق my-test-site.com ، قم بإعطاء عنوان IP خارجي ، على سبيل المثال 123.123.123.123
وبمجرد اجتياز عملية التحقق من الصحة ، ابدأ في إرسال IP داخلي إلى نفس المجال.
في هذه الحالة ، قدم
إميل ليرنر خدمة رائعة - 1u.ms!
يجيب مجال 1u.ms بعناوين IP التي حددتها.
يجب أن يكون تنسيق المجال كما يلي:
make-%IP%-rebind-%IP-rr.1u.msعلى سبيل المثال
make-123.123.123.123-rebind-127.0.0.1-rr.1u.msسيتم الرد على الطلب الأول بالعنوان 123.123.123.123 ، وسيتم الرد على الطلب الثاني بالفعل على 127.0.0.1 (إذا كانت واحدة تلو الأخرى ، في غضون 5 ثوان).
بالمناسبة ، يمكن كتابة عنوان IP بدون نقاط ، في حالة احتياجك إلى نطاق فرعي:
make-123-123-123-123-rebind-127-0-0-1-rr.1u.msبالمناسبة ، قبل إجراء البحث وبعده ، يمكنك كتابة كلمات عشوائية لمنع استخدام البيانات المخزنة مؤقتًا:
bo0om-make-123-123-123-123-rebind-127-0-0.1-rr-test.1u.msولعرض السجل - التناظرية الذيل -f:
curl http://1u.ms:8080/log(أو نفس الرابط في المتصفح)
ميناء المسح الضوئي باستخدام DNS
في الواقع ، إدارة سجلات DNS ، يمكنك محاولة مسح المنافذ. خدعة صغيرة سوف تساعدنا في هذا.
لنفترض أن لدينا مجالًا my-test-site.com.
عادة ، يحتوي على سجل A واحد على الأقل للمورد لفتح.
لنفترض أن عنوان IP لموقعنا هو 172.217.20.46 (مأخوذ من google.com). ولكن يمكننا تحديد العديد من هذه الإدخالات! تخيل أننا أنشأناها وأن سجلات نظام أسماء النطاقات لدينا تبدو كما يلي:
my-test-site.com 172.217.20.46
my-test-site.com 192.168.1.1هل سيتم فتح موردنا؟ نعم سوف. وكل ذلك لأن السجل الأول يذهب أولاً.
الآن قم بتغيير سجلات DNS مثل هذا:
my-test-site.com 192.168.1.1
my-test-site.com 172.217.20.46هل سيتم فتح موردنا؟ سيكون مرة أخرى :)
وكل ذلك لأن المورد سيحاول أولاً التمهيد من أول عنوان IP محدد ، وإذا كانت هناك أي مشاكل في ذلك ، فإنه سينتقل إلى الثاني.
curl "my-test-site.com" -v
* Trying 192.168.1.1...
* TCP_NODELAY set
* Immediate connect fail for 192.168.1.1: Host is down
* Trying 172.217.20.46...
* TCP_NODELAY set
* Connected to my-test-site.com (172.217.20.46) port 80 (#0)
> GET / HTTP/1.1
> Host: my-test-site.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1561
< Date: Tue, 21 Jan 2020 16:35:08 GMTباستخدام هذه الميزة ، يمكنك معرفة أي المنافذ مفتوحة وأيها غير مفتوحة. في الواقع ، ستحاول العديد من المكتبات (وليس كلها) أن تأتي أولاً في المورد الأول ، المدرج أولاً في سجلات DNS ، ثم إلى الثانية.
هنا أشرنا إلى رابط مواردنا في تحميل الصورة الرمزية.
من خلال تحديد نطاقنا ، وتغيير المنفذ ، نحاول استخدام طريقة الاستثناء لتحديد المنفذ المتاح.
http://my-test-site.com:22 - 172.217.20.46:22
http://my-test-site.com:80 - 172.217.20.46:80
http://my-test-site.com:8080 -
http://my-test-site.com:9200 - 172.217.20.46:9200
http://my-test-site.com:3306 -نظرًا لأننا حددنا 192.168.1.1 كسجل أول ، فإننا نستنتج أن هذا العنوان أجاب على المكتبة على 192.168.1.1 (المنفذان 8080 و 3306) ، حتى لو كان غير صحيح ، لكنه أجاب. لذلك هذه المنافذ مفتوحة وهناك خدمات عليها. في هذه الحالة ، لن يتم التبديل إلى العنوان الثاني.
خدمة 1u.ms هنا يمكن أن تساعد أيضًا ، في هذه الحالة سيكون لدينا التكوين التالي:
make-%IP%-and-%IP%rr.1u.msمن النوع
make-192.168.1.1-and-172.217.20.46rr.1u.msسيعود إدخالين ، كل الميزات الأخرى اعتبارًا من الفقرة السابقة.
بالمناسبة ، يمكن استخدام هذا الأسلوب لإعادة ربط DNS بشكل أسرع ، مما يجبر المستعرض على التبديل من خادم "معلق" إلى خادم عمل. أعتقد أنه سيكون من أسرع من الانتظار دقيقة لتحديث ذاكرة التخزين المؤقت DNS. ومع ذلك ، مع Chrome ، على سبيل المثال ، لن تعمل هذه الخدعة ، حيث إنها تتطلب عنوان IP عشوائيًا.
ميزة أخرى تتمثل في أن خادم DNS الذي يحدد به تطبيق الويب عناوين النطاقات يمكن أن يكون مدمجًا في ملف robin - تغيير ترتيب السجلات ، وبالتالي توزيع الحمل بالتساوي على جميع الخوادم. على سبيل المثال ، رفض 8.8.8.8 هذه الميزة ، ولكن في 1.1.1.1 كانت موجودة.
الموجهات
حاول إعادة التوجيه! حسنًا ، أولاً ، يمكن لعمليات إعادة التوجيه تقليل عدد طلبات تطبيق الويب ، على سبيل المثال ، عند فحص المنافذ باستخدام DNS. إذا وصلت الإجابة إليك ، فقم بإعادة التوجيه إلى منفذ أو مجال آخر. إذا لم يكن كذلك ، ربما تعثر في منفذ مفتوح.
لكن أفضل شيء ، بالطبع ، هو محاولة تغيير البروتوكول باستخدام إعادة التوجيه. في ممارستي ، كانت هناك حالات عند إعادة التوجيه إلى الملف: /// etc / passwd عملت وأظهرت محتويات الملف. في الإصدار الذي يحتوي على ssrf الأعمى ، يمكنك محاولة تغيير البروتوكول إلى gopher (بينما لا يزال موجودًا) ، ويمكنك بالفعل إرسال رسائل باستخدام أوامر إلى SMTP وسحر آخر.
الحرمان من الخدمة
هل سيتوقف برنامج تحميل التشغيل إذا أعطيته ملف إدخال بحجم 10 جيجابايت؟ أو صورة تبلغ 225000 بكسل 225000 بكسل ، وتحتل مساحة 141.4 جيجابايت من ذاكرة الوصول العشوائي. قد يؤثر هذا على أداء الموقع. صحيح أن الخادم المتقطع لن يجلب لنا أي متعة ، لذلك ضع ذلك في الاعتبار.
ومجموعة كاملة من كل شيء
ربما هذا هو كل ما يمكنني تسميته الآن. هذا لا يأخذ في الاعتبار الثغرات الأمنية المرتبطة بالتنزيل (حيث يتم تحميله ، وكيفية حفظه ، والذي يتم التحقق منه في نفس الوقت)
ومقاطع الجهات الخارجية (تذكر
imagetragick و
gifoeb ). إذا كان لديك أي أفكار أخرى ، فاترك تعليق.
لا يسعني إلا أن أعطي
SSRF كتيبًا يصف معظم الحالات في هذا الهجوم. وكذلك صفحة تشتمل على SSRF على مستودع PayloadsAllTheThings المفضل للجميع ، والذي يدعمه المجتمع بشكل نشط.
بالمناسبة ، تنطبق العديد من الهجمات على كل من جانب الخادم (على الخادم) وعلى جانب العميل (في المستعرض). المهاجم - الهجوم ، أن تكون خلاقة. الدفاع - الدفاع عن نفسك ، أن يكون أكثر ماكر من الهجوم.
https://bo0om.ru/blind-ssrfزن