كيف قدرنا نكتشف ثغرة؟ 🔴Chaining Fortinet WAF Bypass and Microservice Architecture Exploitation to Compromise 6+ Internal Domains With @Mohnad @stuipds مساكم الله بالخير جميعا , مقالة اليوم عن استغلال عدة ثغرات وصلنا من خلاله بتحكم كامل على احد اكبر الشركات - بيانات +40 ألف موظف وشركات متعاقدة (بكامل التفاصيل) - فصل أي موظف وإغلاق بصمة الوجه وبطاقات الدخول للفروع - Fortinet WAF bypass through path Confusion - Microservice Compromise Lateral Movement to 10+ Internal Domains # البداية في بداية فحصنا طلعنا عدة ثغرات، وبعد وقت من الفحص صادفنا Error والواضح من الخطأ إنه قاعد يستقبل الـ username كبراميتر ويحطه بالـ URL path الى Internal domain فالي قاعد يصير إنه يستقبل المدخل من المستخدم، والـ front-end API يرسل طلب والـ back-end API يأخذ القيمة ويحطه بالمسار، ومن خلاله يرجّع معلومات المستخدم. وبديهي أول سؤال بيجي ببالك هل ممكن نشوف معلومات شخص آخر؟ والإجابة ايه بمجرد ما نسوي path traversal راح نتخطى عملية التحقق الي تكون من ال front-end API ونجيب معلومات أي مستخدم بشكل كامل لكن هذا ما يهمنا، كان هدفنا الأساسي إننا نوصل إلى Internal domain وبعد عدة محاولات، توصلنا إلى إننا نوصل إلى مسار داخلي ويحتوي على Swagger Documentation تحتوي على مسارات لأكثر من عملية. ومن خلال المسارات اللي وصلنا لها، قدرنا نطلع ثغرات حرجة وكثيرة جدًا، مثل ما راح نستعرض لكم الحين (;

من ثغرة بسيطة في الـ API إلى صلاحيات تتحكم بميزانية بملايين فحص على الطاير مع @Mohnad @N4waF_Almutairi نسمي بالله ونبدأ عالخفيف 🔴 Parameter confusion result in full employee account takeover. طريقة وصولنا لجميع حسابات الموظفين أثناء فحصنا للموقع، لاحظنا أن كل شيء يعتمد على UUIDs، لذلك كنا مستبعدين وجود ثغرات Access Control. لكن بعد اكتشافنا لبعض الثغرات، طحنا على مسار يرجّع معلومات لطلبات العملاء من خلال UUID (المستخدم)، مثل ما كنا متوقعين. خلال الفحص، اكتشفنا خدمة تنشئ طلب، وبعده يتم إنشاء رقم لهذا الطلب. الريكوست هذا كان مسؤول عن إرجاع بيانات الطلب اللي سويناه. وقفنا شوي عند الريكوست وقلنا لازم نلقى له تخطي. ليش؟ لأن ال Response فيه UUID الخاص بالمستخدم. طيب، عمر مافهمت؟ تجيب UUID من خلال UUID؟ وش الفايدة؟ المسار هذا كان يرجع تفاصيل الطلب، لكن كان يحتوي أيضًا على بيانات المستخدم بالكامل، من ضمنها الـUUID. بعد ما فكرنا شوي في العملية، استوعبنا إنه من غير المنطقي يرجع معلومات بناءً على UUID المستخدم فقط، لأن لو جينا نلغي الطلب، بيستخدم OrderNumber Parameter، وهو عبارة عن رقم بسيط. فكرة إنه يرجع بيانات الطلب من خلال UUID للمستخدم، بدل UUID خاص بالطلب نفسه، خلتنا نشك في العملية الي قاعد تصيير. تخيلنا الكود وكيف ممكن يكون شغال في الـBackend، وفكرنا إن العملية ممكن تصير كالتالي: السيرفر يستقبل UUID. يشيّك على الطلبات التابعة له. يترجم الطلب إلى OrderNumber. يرجّع البيانات. فقلنا نجرب نحذف ال UUID تمامًا، ونضيف OrderNumber بداله في نفس الريكوست اللي يرجع بيانات المستخدم. ويوم جربناه… وفعلًا، قدرنا نتخطى الـUUID، وتسربت معلومات حساسة جدًا، منها UUID. إلى الآن ما وصلنا للثغرة الأساسية رغم إن البيانات حساسة، لكن كنا مهتمين بالـUUID أكثر لأنه بيفتح لنا أبواب أكبر. وبعد بحث طويل، لقينا مسار ياخذ UUID لكن لازم يكون خاص بموظف. وبما إن عندنا ريكوست يسرب UUIDs، سوينا سكربت بسيط يجرب يخمن على ال OrderNumber، ويطلع أي UUID موجود، ثم يرسله على المسار والمسار هذا كان محدود فقط للموظفين لذللك لابد ان يستقبل UUID لأدمن account /api/GetransactionsInfo/UUID-HERE ومن خلال الثغرة السابقة والسكربت اللي ضبطناه، قدرنا نستغل الـUUID المسرب بشكل أكبر ونوصل الى UUID خاص بأحد الموظفين. والبيانات الي كانت ترجع لنا... مثل ما هو واضح بالصورة، قدرنا نوصل لـJWT. ومن خلال الـJWT token، قدرنا نوصل لجميع حسابات الموظفين ونتحكم بتفاصيل حساسة ما نقدر نذكرها.

انتظرو المقالة الجاية 🔥🔥 مع @Mohnad @stuipds