في الآونة الأخيرة ، بدأت أتلقى اقتراحًا للتحقق من تشغيل الخدمات المختلفة بحثًا عن الأخطاء ونقاط الضعف. وفي مثل هذه المقترحات ، أحاول العمل من أجل الحصول على النتيجة والحصول على أقصى درجات المتعة من هذه العملية. لكن نتيجة "المشروع" الأخير صدمتني على أقل تقدير.
طلب مني اختبار مزود الاستضافة.
لن أفصح عن الاسم. وفي قصتي سأستخدم اسم Hoster. مع الموقع نفسه ، كانت خدمة الاستضافة قياسية. عروض لشراء VDS ، المجالات ، شهادات SSL.
بادئ ذي بدء ، فوجئت بكيفية تنفيذ حساب المستخدم الشخصي. لم يكن إثبات ملكية عنوان البريد الإلكتروني أثناء التسجيل مطلوبًا. وهذا يعني أنه يمكنك التسجيل باستخدام عنوان البريد الإلكتروني steve.jobs@apple.com. أو الأفضل من ذلك ، support@hoster.com.
لكن لحسن الحظ ، من خلال القياس مع
هذه القصة ، لم يحدث الكشف عن المعلومات الحساسة لمكتب دعم الخدمة.
ومع ذلك ، فقد حدث ذلك عندما قمت بإنشاء طلب دعم اختبار وفحصت على الفور توفر طلبات معرف المجاورة لطلبات الدعم الأخرى. من المستغرب أنها كانت متاحة. وكان من الممكن ملاحظة من وما يسجل مع المضيف. وما هي المشاكل التي يواجهها المستخدمون؟ بشكل عام ، فإن الضعف IDOR القياسية ، والتي الآن لن يفاجئ أي شخص. بالطبع ، تم تصحيحها على الفور.
كان هناك أيضًا العديد من الأماكن مع XSS المخزنة. كان هناك أيضًا Blind XSS الذي أعاد ملف تعريف ارتباط مسؤول الخدمة إلي. بفضل XSS ، تمكنت من معرفة مكان وجود واجهة المسؤول ، وكشفت بشكل عام عن الكثير من المعلومات المثيرة للاهتمام.
- كم عدد المستخدمين النشطين.
- كم عدد المجالات في السيطرة.
- كيف يتم نشر عدد VDS.
وأكثر من ذلك بكثير ...
حدثت العديد من الأخطاء في رموز CSRF ، والتي سمحت نيابةً عن المستخدم بعمل أشياء خطيرة في حسابك. وإذا كانت هناك أماكن تم فيها نقل رموز CSRF ، فقد تم نقلها ببساطة. لا أحد يعتزم التحقق منها على الواجهة الخلفية. نتيجة لاستنتاجاتي ، تم تعطيل جزء من الوظيفة بالكامل. على سبيل المثال ، تمت إزالة مصادقة 2FA لإزالتها مؤقتًا ، حيث لم تتم في التنفيذ.
أثناء عملي ، اهتمت ليس فقط بمشاكل الأمان ، ولكن أيضًا بأخطاء التنفيذ أو مشاكل في تشغيل بعض الوظائف. أنا أحب QA لا يمكن أن يمر من هذا القبيل. نتيجةً لذلك ، وصل متتبعي للمشكلة إلى الرقم 22. العديد من المشكلات في المجموع التي وجدتها وثابتة (جدير بالذكر للغاية).
وكانت النتائج أكثر من مقنعة. وخططت بالفعل لإكمال هذا المشروع. لكن لسبب ما ، تذكرت مرة أخرى مشكلة عدم تأكيد صاحب عنوان البريد الإلكتروني أثناء التسجيل. وبدأ في الخروج بمواقف يمكن أن يخلق فيها ذلك أقصى مشاكل الاستضافة وأصحابها. في مرحلة ما ، بدأت أفكر في علاقات أصحاب خدمة الاستضافة هذه مع مشاريع أخرى لنفس الشركة التي عرفت عنها. بعد بضع دقائق ، قمت بتسجيل حساب بعنوان البريد الإلكتروني لمشروع آخر لنفس الشركة (فليكن support@example.com). ثم تمكنت من ربط المجال example.com بحسابي الذي تم إنشاؤه suppot@example.com. لكن ما زلت لا أستطيع التحكم في محتوى المجال المنضم.
لكنه يمكنه أن يصطاد رسائل البريد الإلكتروني نيابة عن خدمة example.com.
ليس من الواضح أين جاءت رسائل الاستجابة. لأنني أجبت على رسالة اختبار واحدة من هذا القبيل لنفسي. لكنني لم أتلق الجواب نفسه. ربما اختفت استجابةً للمالك الحقيقي لحساب البريد الإلكتروني support@example.com.
ثم حدث شيء ما قررت أن أكتب هذا المقال.
تمكنت من حل المجال الفرعي المنسي. ضعف نطاق السيطرة الكلاسيكية. يمكنك قراءة المزيد عن هذا
هنا .
لا أعرف السبب ، لكنني حاولت إضافة رابط إلى مجال غير موجود. وفعلت ذلك.
تمت إضافة النطاق الفرعي بنجاح ويمكنني التحكم في محتويات هذا النطاق الفرعي. وتم عرض المحتوى.
ولكن هذا لا يمكن أن يكون هو نفسه! كيف ذلك؟ بعد كل شيء ، لا تعمل مشكلة ضعف الاستيلاء على المجال الفرعي الكلاسيكية إلا مع النطاقات الفرعية الحالية.
هذا الوضع بالتأكيد لا يصلح في رأسي. هذا ، حسناً ، لقد تمكنت من تجاوز مستويات التحقق من الصحة في موقفي على example.com ، وهو أمر غير مألوف لي (ربما بفضل
مثال .com باسم حسابي). ولكن كيف يمكن إضافة نطاقات فرعية على الإطلاق والتحكم فيها دون التحقق من المكونات الموجودة في سجلات A و TXT و CNAME ...؟
عادةً ما أرى هذا - سنضيف نطاقًا فرعيًا إليك ، فقط أنت تثبت أنه يمكنك القيام بذلك. اذهب وأضف إلى TXT هذا التجزئة
الأولوليبيشيبيشبيديش .
لكن لم يكن هناك شيء كهذا. هل تريد admin.example.com نطاق فرعي؟ لا مشكلة!
كما لو أن هناك مشكلة في Subdomain Takeover V2.
نظرًا لقدرتك على التواصل بسرعة مع مالكي خدمة الاستضافة المختبرة - فتحت هذا المربع بواسطة Pandora.
اتضح ما يلي. استضافة عملت من خلال CloudFlare. وكان يعمل بطريقة دهاء جدا.
سأحاول أن أشرح بكلمات بسيطة.
تحدث تقريبًا ، أقول لك ، تعال إلي ، سأستضيفك. تفويض المجالات الخاصة بك لي.
ثم أرسل جميع المكالمات الواردة بشكل عشوائي إلى CloudFlare ، معتبرة أنها صحيحة.
وإذا كنت تثق بي في مجال vasya.ru ، وجاء أحد الجيران و zapilit الموقع مع test.vasya.ru وأعطيته لي أيضًا لاستضافته ، فقم بإضافة الخادم الخاص بي ، الذي لديه حق الوصول إلى CloudFlare ولديه بالفعل حقوق إلى vasya.ru ، المستوى الثالث دون مشاكل مجال لجار وجميع القواعد ، بسرعة ودون سؤال. بالنسبة لجميع DNS ، وصلت المعلومات الصحيحة من CloudFlare. و CloudFlare يثق بي.
عادة ، بالطبع ، يقوم مزودو خدمات الاستضافة بتكوين خدمات DNS الخاصة بهم. ولكن هنا اتضح أنهم قاموا بالغش ونقل كل شيء إلى CloudFlare من مستخدم واحد.
لذلك لدينا god_mode الاستيلاء على المجال الفرعي. صحيح ، هذا يعمل فقط مع تلك العناوين التي يتحكم فيها الاستضافة بالفعل. ولكن بالاقتران مع لوحة مسؤول الخدمة المكتشفة مسبقًا - يمكن أن يلعب هذا خدعة على كل من المضيف وعملاء خدمة الاستضافة.
في الوقت الحالي ، تم إصلاح جميع نقاط الضعف والأخطاء المهمة تقريبًا. وآمل ألا يقرر أحد هذه المسرات المعمارية بعد قراءة هذه القصة.
ملاحظة: التعليقات والاقتراحات على المادة هي موضع ترحيب. شكر خاص ل
Patriot2k للحصول على المشورة الفنية! أنا منفتح أيضًا على اقتراحات لاختبار شيء مثير للاهتمام.