ثريد | كيف نشأ "بُعد"؟ من مشكلة إلى حل 🚀🇸🇦 . . .

مبرررررووووووكككككك مهندددسسسيي وزميييلللللل المجال اخيرا جت 🔥🔥🔥🤍🤍 ماشاء الله تبارك الله، الله يجعلها بداية خيييرر لك 🫡🤍 – at Riyadh, Kingdom of Saudi Arabia

الله يوفقك يا سعود وتصير زميل المهنة 🔥 " اكثر شخص مجتهد عرفته ما شاء الله " 🫡🤍 – at Riyadh, Kingdom of Saudi Arabia

Kimi K3 is calling.. – at Riyadh, Kingdom of Saudi Arabia

بفضل الله انتهينا من تقديم آخر يوم في معسكر CTF 👏🏻 تطرقنا لأساسيات مهمة في الـCTF من الشبكات إلى الويب وبعض أساليب الاختراق، وكانت تجربة اكثر من رائعة. ونفخر بتجاوز عدد المسجلين 1300+ طالب 🫡 الشكر موصول لإدارة وأعضاء @CGClub_sa وللأستاذ @jn_rh5 على جهودهم في إنجاح المبادرة 🤍

احد يخبرلنا معسكر Ai؟ 🫠

ننتظركم! 🤩🔥👏🏻 – at Riyadh, Kingdom of Saudi Arabia

مبارك عليكم الشّهر الفضيل، جعلنا الله وإيّاكم من صوّامه وقوّامه وغفر لنا ذنوبنا وجعلنا من العتقاء من النار، وكل عام وانتم بخير 🌙🤍 – at Riyadh, Kingdom of Saudi Arabia

🛑 How I turned a "Simple Search" feature into a Blind IDOR that exposed sensitive information for over 20k users in just 2 minutes! 🛑 Have you heard of a vulnerability called Blind IDOR? Sounds strange, right? Today, I’m going to talk about a vulnerability I discovered in one of the largest companies. It started as an ordinary feature… there was no sign that it was dangerous or even worth testing. But after experimenting and digging deeper, it turned into one of the strangest and most powerful vulnerabilities I’ve ever encountered. Grab your coffee and let’s dive in… ——————————— It all started like any other day when I was testing the main target: redacted.com The site is fairly large, with many features, pages, and functions… I planned to test it fully, so I spent long hours every day testing everything, page by page, function by function, and trying everything possible. After all my attempts, I didn’t find anything exploitable. Even fuzzing didn’t yield anything useful. But during Recon, one thing caught my attention. The entire platform relies on a single API. I noticed that all real interactions happen on just one subdomain: api.redacted.com. No matter what you do on the front end, everything is executed from here. So I decided to focus on this during my full testing. I started doing extensive fuzzing on it, and the results were clear: 200 → endpoint is working 404 → not found 403 → exists but you don’t have the necessary permissions As expected… most of the sensitive endpoints returned 403. I tried bypassing with several methods: Header changes Capitalization variations Encoding and double encoding None of them worked, unfortunately. That’s when I realized the issue wasn’t the WAF; the issue was with the permissions. ——————————— - Permission differences between accounts - The platform has two main types of accounts: Individual accounts Company accounts So I decided to see if there’s actually a difference. I created a company account, grabbed the token, and started playing around with the 403 endpoints. And sure enough, a few important endpoints opened up immediately 🫣! That’s when the picture became clearer: The difference in roles is the key (which is logical and expected). ——————————— - The actual start of the vulnerability: The Search Endpoint - Among the endpoints I discovered: /api/v2/all-users/search The response returns a list of users, but with very basic information like their name, username, and ID. Generally, there’s nothing interesting. But since I’m used to testing everything, I decided to perform parameter fuzzing on it. That’s when things started to change… ——————————— - Fuzzing the parameters - I started fuzzing the parameters and found many of them: page length sort search username ... and others. I tried the page number, length, sort, etc., but none of them seemed to expose anything useful. But one parameter stood out: "search". I thought I’d try different values on it: username → returned the account display name → returned the account Then I decided to try something that should never be checked… I typed in the first part of my real email: sultansdp And guess what? It returned my account in the response!! Even though this part of the email is never visible to users or anyone else. That’s when I realized that the search doesn’t just search visible data… It also searches deeper, within the backend, specifically in the Model itself. At that point, I adjusted my seating, as this was clear evidence that something was wrong with the search👀 ——————————— - Linking search and profile update - While testing, I noticed that the update profile page returned the same JSON structure I saw in the search endpoint: The same fields The same structure The same names This meant that the backend was using the same Model for both updates and searches. Nice… so what does this mean? It means that the search can see data that it should not be able to see or search for. But there’s still a problem: You can’t directly guess sensitive data, especially email or phone numbers, because you don’t know their length, start, or service provider. And initially, the WAF will handle you if you send too many requests 😂 That’s where your thinking as a Hunter begins 🔥 ——————————— - Discovering Regex support in search - While analyzing JS files, I noticed that the search uses Regex internally. So I thought I’d try: sultan → returns results sul an → no results sul_an → returns results! And here’s the key part… The _ (underscore) worked as a wildcard for a single character. So what do I gain from this, you ask? In short, I can now guess the email one character at a time, with a “yes/no” logic. Just like a Blind SQL Injection, but on the API level. ——————————— - Exploiting the vulnerability - How was the exploitation done? Here’s how the process went: I pick a fixed username for the user via the username parameter I use Regex in the search: If the account shows up → the guess is correct If it doesn’t show up → the guess is wrong And thus, the search becomes an oracle that gives me a "yes" or "no" answer based on the data. I started extracting the email like this: First, I define the service provider: @gmail.com, @anything.com... Then, I define the number of characters: [email protected] [email protected] [email protected] Then, I start guessing each character: [email protected] [email protected] ... until the full email is extracted. The same thing applies for phone numbers, addresses, and more. ——————————— - Automation - In complex vulnerabilities like this, it’s best to automate the process. So I wrote a simple Python script that automates the entire operation. I input the username → and within a minute or two, it extracts all of their data: Email Phone number Address Any information related to the user, even if it’s not shown in the response. This is what makes it not just an IDOR… It’s a Blind IDOR, and it’s much more dangerous 🚨 ——————————— - Backend Explanation - Here’s a mockup of what happened in the backend: In this code, I used the same Blind IDOR logic from the backend. The API relies on search with Regex to guess data like email and username. The Wildcard (_) here lets me guess each character, extracting hidden data just like it happened in the vulnerability. ——————————— - Conclusion - The testing began as something completely normal, but as I understood some details and connected the behavior across endpoints, it became clear that the search feature was directly tied to the user’s data model. This led to an unintended query exposure that allowed me to extract sensitive information through Blind IDOR. I reported the vulnerability, and it was fully patched 👏🏻. The key takeaway here: Most vulnerabilities don’t come from obvious steps. Instead, they come from small observations, and when you connect them, you uncover an entire exploit that wasn’t on your radar 🧠 ——————————— I created a simple challenge to simulate a Blind IDOR vulnerability using Flask. The challenge focuses on exploiting the API with Regex and Wildcard techniques to extract sensitive data. The goal is to find the flag🚩 Flag: Flag{......................................} Challenge URL: http://172.237.155.131:5000/ Let’s see who gets the First blood🩸👀 Thanks for reading… and stay tuned for more powerful vulnerabilities soon, God willing 🫡

🛑 كيف حولت ميزة “بحث بسيط” إلى 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 … بعدها أحدد عدد الحروف: [email protected] [email protected] [email protected] بعدها أبدأ أخمن كل حرف: [email protected] [email protected] … إلى ان يكتمل الإيميل بالكامل. نفس الشي على رقم الجوال، العنوان، إلخ. ————————— - الأتمتة - دائما في الثغرات المعقدة مثل هذي الافضل انك تسوي سكريبت يوضح للترياق ويختصر عليه الثغرة ك 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 🩸👀 شكرًا لقراءتكم… وموعدنا مع رايت اب قادم بإذن الله 🫡