🛑 كيف حولت ميزة “بحث بسيط” إلى Blind IDOR يكشف معلومات حساسة لأكثر من 20 الف مستخدم خلال دقيقتين بس !🛑 السلام عليكم, قد سمعت بثغرة اسمها Blind IDOR؟ غريبة صح؟ اليوم بتكلم بإذن الله عن ثغرة صادفتها في واحدة من أكبر الشركات ثغرة بدأت كميزة عادية جدًا… ما فيها أي مؤشر يوحي بأنها خطيرة أو حتى يستاهل تفحصها, ومع التجربة والتعمق تحولت إلى واحدة من أغرب وأقوى الثغرات اللي مرت علي في المجال. جهز قهوتك وخلنا نبدأ… ——————————— في البداية زي اي يوم كنت أفحص التارقت الرئيسي: redacted.com الموقع كبير نوعًا ما، فيه ميزات كثيرة، صفحات كثيرة، وفنكشنز كثيرة… وناوي أفحصه كامل، فجلست فترة طويلة يوميًا تقريبًا افحص كل شي وفي كل حته أمشي صفحة صفحة، فنكشن فنكشن، وأجرب كل شي ممكن.. ومو ممكن :) ومع كثرة المحاولات… ما كان فيه أي شيء فعلي ممكن يستغل حتى الـ fuzzing ما طلع لي بشي مفيد لكن وقت Recon لفت نظري نقطة مهمة جدًا. المنصة كلها تعتمد على API واحد لاحظت إن كل التفاعل الحقيقي يصير على Subdomain واحد فقط: api.redacted.com ومهما كان إيش تسوي على الواجهة… كل شيء يتنفذ من هنا. فقلت خلاص… هذا اللي بركز عليه في الفحص الكامل.. بدأت أسوي عليه fuzzing موسّع، والنتائج كانت واضحة: 200 → endpoint شغال 404 → مو موجود 403 → موجود لكن ما عندك الصلاحيات المناسبة ومثل ما كنت متوقع … أغلب ال endpoints الحساسة كانت 403. جربت bypass بأساليب كثيرة: تغييرات في الهيدرز Capital/Small Encoding و Double Encoding ولا وحدة اشتغلت للاسف وهنا تاكدت إن المشكلة مو WAF المشكلة "صلاحيات". ————————— - اختلاف الصلاحيات بين الحسابات - المنصة فيها نوعين رئيسية من الحسابات: - حساب أفراد - حساب شركات قلت خلني أشوف هل فعلاً فيه فرق؟ سويت حساب شركة… أخذت الـ token… ورجعت أطقطق شوي على ال endpoints اللي كانت 403 وفعلاً… كم endpoint مهم فتح معي على طول🫣! وهنا بدأت تتضح الصورة: اختلاف الـ roles هو المفتاح ( وهو شي منطقي وبديهي ). ————————— - البداية الفعلية للثغرة : الـ Search Endpoint - من ضمن ال endpoints اللي شفتها: /api/v2/all-users/search الرد يرجع لك قائمة مستخدمين، لكن بمعلومات بسيطة جدًا زي الاسم, اليوزر, الاي دي وبشكل عام… مافي شيء يحمّس لكن بما إني تعودت أفحص كل شيء، قلت خلني أسوي parameter fuzzing عليه وهنا بدأت تتغير الأمور… ————————— - فحص الباراميترات - بدأت أفحص الباراميترات وطلعت لي باراميترات كثيرة: page length sort search username … وغيرها جربت رقم الصفحة، الطول، الترتيب… كلهم عاديين وما فيهم شيء. لكن باراميتر واحد كان مختلف وهو "search" قلت خلني أجرب قيم كثيرة عليه: username → طلع الحساب display name → طلع الحساب بعدها قلت أجرب شيء المفترض ما يشيك عليه … كتبت أول جزء من إيميلي الحقيقي: sultansdp واللي صار؟ رجّع لي حسابي في الرد!! مع إن هذا الجزء من الإيميل ما يظهر أبدًا للمستخدم، ولا لأي أحد. وقتها استوعبت إن الـ search ما يبحث فقط في البيانات الظاهرة… لكن يبحث بعد في بيانات أعمق داخل الباك اند وتحديدا الـ Model نفسه. وهنا عدلت الجلسة لانها دليل ان فيه شيء مو طبيعي بالبحث👀 ————————— - الربط بين البحث وتحديث الحساب - وقت الفحص لاحظت إن صفحة update profile ترجع نفس الـ JSON structure اللي شفته في search endpoint: نفس الحقول نفس البنية نفس الأسماء وهذا معناه إن الباكند يستخدم نفس الـ Model للتحديث والبحث. حلو.. طيب وش نستنتج ؟ نستنتج سلمك الله ان البحث يقدر يشوف بيانات المفترض ما يشوفها ولا يبحث فيها حتى لكن بقى عندنا مشكلة: ما تقدر تخمّن بيانات حساسة مباشرة، خصوصًا الإيميل أو رقم الجوال والسبب لانك ما تعرف طوله ولا بدايته ولا مزود الخدمة. ومبدئيا الـ WAF بيتفاهم معك لو كثّرت طلبات😂 هنا يبدأ تفكيرك كـ Hunter 🔥 ————————— - اكتشاف دعم الـ Regex داخل البحث - وأنا اتفحص ملفات الـ JS واحللها لاحظت إن البحث يستخدم Regex بشكل داخلي فقلت خلني أجرب: sultan → يطلع sul an → ما يطلع sul_an → طلع! وهنا الزبدة كلها.. علامة _ اشتغلت كـ wildcard لحرف واحد, طيب وش بنستفيد كذا يا سلطان ؟ باختصار صار أقدر أخمن الإيميل حرف حرف بطريقة شرطية “نعم/لا” نفس فكرة Blind SQL Injection لكن على API. ————————— - استغلال الثغرة - كيف صار الاستغلال؟ الآلية كانت كذا: 1- أحدد username ثابت للمستخدم عن طريق باراميتر username 2- أستخدم Regex في search : - إذا طلع الحساب → التخمين صحيح - إذا اختفى → التخمين غلط وبكذا صار البحث عبارة عن oracle يعطيني إجابة “صح” أو “غلط” حسب المعلومات. وبدأت أستخرج الإيميل كذا: أبدأ بتحديد مزود الخدمة: @gmail.com، @anything.com … بعدها أحدد عدد الحروف: _@gmail.com __@gmail.com ___@gmail.com بعدها أبدأ أخمن كل حرف: a___@gmail.com b___@gmail.com … إلى ان يكتمل الإيميل بالكامل. نفس الشي على رقم الجوال، العنوان، إلخ. ————————— - الأتمتة - دائما في الثغرات المعقدة مثل هذي الافضل انك تسوي سكريبت يوضح للترياق ويختصر عليه الثغرة ك PoC اضافي فكتبت سكربت Python بسيط يأتمت العملية كاملة أحط اليوزر → وبعد دقيقة إلى دقيقتين يطلع لي كل بياناته: - الإيميل - رقم الجوال - العنوان وأي معلومة مرتبطة بالمستخدم بدون ما تظهر لي أصلًا في الرد . وهذا ما يخليها IDOR عادي… هذي Blind IDOR بخطورة عالية جدًا 🚨 ————————— - توضيح للـ Backend - هذا كود محاكي للي صار في الباك اند: في الكود هذا، استخدمت نفس فكرة الـ Blind IDOR من الباك اند. الـ API يعتمد على البحث بـ Regex لتخمين بيانات زي الإيميل واليوزر نيم. الـ Wildcard (علامة _ ) هنا تتيح لي أخمن حرف بحرف، عشان أستخرج بيانات مخفية زي ما حصل بالضبط في الثغرة. ————————— - الخلاصة - الفحص بدأ بشكل اعتيادي جدًا، لكن مع فهم بعض التفاصيل وربط السلوك بين الـ endpoints اتضحلي إن ميزة البحث ترتبط مباشرة بنموذج بيانات الحساب، وهذا أدى لفتح باب استعلام غير مقصود يسمح باستخراج معلومات حساسة عن طريق Blind IDOR. تم الابلاغ عن الثغرة وتم إصلاحها بشكل كامل الحمدلله أهم نقطة هنا: أغلب الثغرات ما تجي من خطوة واضحة، لكن من ملاحظات صغيرة ولما تربطها مع بعض تكتشف آلية كاملة ما كانت في بالك 🧠 ————————— سويت لكم تحدي بسيط لمحاكاة ثغرة Blind IDOR باستخدام Flask. التحدي يركز على كيفية استغلال API بطريقة تستخدم الـ Regex و Wildcard لاستخراج بيانات حساسة الهدف انك تطلع الفلاق 🚩 الفلاق : Flag{......................................} رابط التحدي : http://172.237.155.131:5000/ خلونا نشوف First blood 🩸👀 شكرًا لقراءتكم… وموعدنا مع رايت اب قادم بإذن الله 🫡

دورة الأساليب المتقدمة في اكتشاف الثغرات 🔎 مع ناصر البراك 🗓 29 يونيو - 1 يوليو ⏱ 9-7 مساءً 🔗سجّل الآن: form.typeform.com/to/dlJiKeY… #مكافآت_الثغرات