ثغره Vertical Privilege Escalation (VPE)

تحليل لثغره Vertical Privilege Escalation (VPE)

في البداية اريد ان اقول مرحباً بكم جميعاً، ومرحباً في مقال جديد عن ثغره مصنفه Broken Access Control وهي Vertical Privilege Escalation، ربما ستظن انها ليست ثغره، لكن يا صديقي بالفعل هي ثغره ويتم اعتمادها، وهذا ما سنعرفه الأن، كما نعرف عن تصنيف broken access control هو التصنيف الذي يهيمن على فائمة OWASP TOP 10 لعام 2025، اساس هذا الخلل هي ان جميع المستخدمين لديهم امتيازات محدوده (Low-privileged User) ويستطيع المهاجم يتجاوز الحواجز الأمنية ويصعط مستويات إداريه اعلى مثل Administrator أو Root، نحن لا نتكلم عن خطأ برمجي عابر هو فشل في البنيه تحديداً في تصميم Security Design Flaw وهذا يجعل المهاجم يسيطير بالكامل على الخدمات المهمه، ويصل الى جميع البيانات الهامه. 

الجذور التقنية: ليه أصلاً بنلاقي ثغرات في نظام الصلاحيات؟

لكي نفهم سبب نجاح المهاجم، فيجب ان نبدأ من البداية والسبب هو فجوه بين عملتين الأولى هي Authentication إثبات الهوية، والعملية الثانية هي Authorization وهي منح الصلاحية، النظام يكتفي بأن يعرف من انت، لكن لا يسأل ما المسموح لك بفعله، وهذا بداية اي ثغره Broken Access. 

دعنا نبني السيناريو بشكل بسيط بسيط بدايته من مفهوم وهو Missing Function-Level Access Control، المبرمج يكتفي ان يقوم بإخفاء الأزرار الأداريه (المقصود بيها الـ Endpoint كمستخدم عادي) في واجهه UI، ظناً منه انها هكذا محمية رغم وجودها في البرمجية الخلفية ومازالت تعمل وتقبل الطلبات من أي مستخدم لديه Token (الموضوع شبه Hidden Paramter) من دون اي مراجعه من رتبته، وتزيد المشكلة أكثر اذا كان السيرفر يقبل أي بيانات مهماً كانت، بيانات لا يتم مراجعتها ولم يتم المراجعه من صحتها، ومن نوعها، هذا يولد شيء اسمه ثقه عمياء في طبيعه البيانات التي تذهب للسيرفر ويتم تنفيذها Insecure Trust in Client-Side Parameter

السيناريوهات التطبيقية: إزاي الـ Bug بيتحول لاختراق كامل؟

بمجرد وجود أساس الخلل، المهاجم يبدأ العمل ويبدأ الاعتماد على اكثر من سيناريوا لكي يرفع صلاحياته وأهم ثلاث سيناريوهات هي:

السيناريو الاول Mass Assignment 

بداية السيناريو بميزه برمجية تبدو عادية جداً، مثل تحديث بيانات حسابك، الـ Bug هنا ان المبرمج يستخدم ربط تلقائي للبيانات (Object Binding) من دون تحديد أي Whitelist التطبيق العملي هنا ان المهاجم يفتح الحساب الخاص به لكي يغير أسمه، بالطبع كما نعلم ان عندما تقوم بالضغط على حفظ فإن الطلب سيتم ارساله الى الويب، لا سوف نستخدم Burp قبل الضغط لكي نعرض الطلب، الطلب الأصلي كمثال سيكون بهذا الشكل 

{"username":"ahmed","email":"a@mail.com"}

 

المهاجم هنا سوف يضع اضافه مع الطلب من عنده مثلاً سيكون بهذا الشكل "isAdmin":"true" هذا بالطبع اذا كان الـ Backend يستخدم json ويقوم بتسجيله في قاعده البيانات فوراً المميز هنا يا صديقي ان الحساب هنا فوراً يتحول الى admin 

السيناريو الثاني HTTP Header Overriding

في هذا السيناريو الوضع مختلف قليلاً، يبدأ السيناريو عندما يستخدم الموقع طبقة حماية خارجية يتم تسميتها بـ Reverse Proxy هدفه هو اغلاق اي روابط الخاصه بالأدمن "admin/"، حسناً يا صديقي اين الـ Bug، سأخبرك، الخطأ هنا هو حدوث تضارب، البروكسي يرى الطلب من الخارج والسيرفر يفهمه من الداخل بشكل مختلف. 

عملياً: المهاجم يبدأ بأرسال طلب لصفحة عادية مسموح مثل الـ Homepage، لكن يضيف Header HTTP مخصص مثلـ:

X-Original-URL: /admin/deleteUser?id=1

البروكسي هنا يرى الطلب موجه تحديداً لـ / ويسمح بتمريره، لكن عندما الطلب يوصل للسيرفر، السيرفر هنا يقرأ الـ Header المخصص، وفي الـ Header امر حذف والمطلوب من السيرفر ان يقوم بتنفيذه وبما ان التحقق من الصلاحيات يحدث فقط في الـ Proxy، فطبيعي ان يتم تنفيذ الأمر بشكل كامل

السيناريو الثالث كسر خدمات في API (BFLA)

في الأنظمة الحديثه التي تعتمد على الـ APIs، في الأستغلال يتم التركيز على الفعل وليس في البيانات وهذا بالطبع يرجع الى طبيعة الـ Bug، المبرمج هنا يحمي طرق الوصول للبيانات، لكن ينسى حماية الخدمة نفسها.

عملياً: المهاجم يبحث عن روابط مخفية Enumeration ويجدث رابط مثل

GET /api/v1/user/123

وهو مسموح له ان يرى البيانات، المهاجم يقوم بتجربه ان يغير HTTP Method لـ DETELE أو PUT على نفس الرابط، او يخمن رابط في Management مثل:

api/v1/admin/upgrade

ويرسل الطلب بـ Token الخاص به كـ User، اذا السيرفر وافق فهذا يدل ان بمجرد امتلاك الـ Token صالح يجعلك مدير، لأن الكود لم يراجع هل صلاحياتك صحيحه اما لا. 

السيناريو الثالث Prototype Pollution 

هذا السيناريو يستهدف التطبيقات التي تعتمد على Node.Js، الـ Bug هنا يا صديقي هو عباره عن دمج بين inputs users و الـ oops في للغه js بشكل غير آمن وسنشرح هذا عملياً الأن. 

 

عملياً: المهاجم يرسل طلب json بداخل الطلب مفتاح اسمه __proto__ وبداخله خاصية وهي {"isAdmin":"true"}، يتم حقن هذه الخاصية في اصل الـ oops في الـ Memory، فكل كائن جديد يقوم بتوريثها فوراً (يعني في اي كائن جديد بيكون فيه نفس الخاصية) وعندما يحاول الـ system تأكيد صلاحيات المهاجم اذا كان المستخدم هو الأدمن فرد الكائن هو True، وهذا ليس لأن هو الادمن بالفعل لكن حدثت عملية تلوث بين الكائنات واصبح ردها دوماً هو True وهذا بالكامل من الـ Memory وهكذا اصبح المهاجم هو الأدمن بشكل صامت في نظر النظام فقط 

 

السيناريو الرابع Cloud IAM Chaining 

 في البيئات السحابيه مثل AWS لا يكون الخطأ في الكود البرمجي، بكل هي لعبه في الصلاحيات، الـ Bug هنا عباره عن اعطاء صلاحيات وسيطة تبدو عادية جداً لكن النتائج كارثية عملياً المهاجم سيبدأ البحث عن الـ Users التي معها صلاحية iam:PassRole وقدره على إنشاء Lambda Funcation، بعدها إنشاء خدمة خبيثة ومصممه إنها ترسل لنفسها صلاحيات الـ Administrator، يقوم بربطها بـ Role إداري متاح مسبقاً في الحساب، وبما ان هناك صلاحيه بالفعل سيقوم بالتمرير الدور PassRole، الخدمة ستعمل بصلاحيات الـ Admin كامله والمهاجم سيحصل على السيطره الكامله من خلال الحساب

 

 

منهج الأستكشاف الثغره 

 المهاجم يعتمد على خطوات ومراحل للأستكشاف الثغره ويقوم بتنفيذها، وطبيعه البئه بحد ذاتها تحدد السيناريو المناسب الذي سوف يتم استخدامه: 

 

اختبار Multi-User Context Testing 

تخيل معي يا صديقي ان نظامك هو عباره عن فندق كبير ومزدحم والـ Backend هو موظف الأستقبال ويومياً يستقبل ألف طلب في الثانية الواحده ما رأيك، هذا كثير وربما يكون عدد الطلبات اكثر من ألف طلب في الثانية الواحده، وهذا تحديداً هو اختبار الـ Mutli-User Context، ومن خلال هذا الأختبار نتأكد اذا كان السيرفر يعمل بشكل جيد اما، هل سيتحمل هذا العدد من الطلبات، ومن دون اي اختلاط في الطلبات. 

 

اختبار الأمر عملياً هو عباره عن تنفيذ سيناريو هو ان سيتم وضع السيرفر بالكامل تحت ضغط هائل، لنفترض ان معنا هو flash sale على موقع اونلاين، وهناك منتج واحد فقط، ونقوم بتشغيل Test Script يقوم بعمل Virtual Users في نفس اللحظة بالضبط، اولاً User A وهذا صلاحياته VIP و User B وهذا Guest والأثنين يقوموا بأرسال Post Request لكي يقوموا بشراء المنتج في نفس اللحظة. 

هنا السيرفر يتم أختباره في الـ Context Isolation لأن اذا كان النظام غير مناسب أو ضعيف الـ Bug موجوده، فممكن يحدث اختلاط بين Session الخاص بـ User A على الـ Session الخاص بـ User B ونجد الـ Shipping Address أصبح VIP على مستخدم Guest، ليس هذا فقط فربما تجد ان حتى المال تم نقله لحسابات خطأ. 

 

هناك Validation Points واضحه يجب التأكد منها اثناء الاختبار (هيفيدك لو كنت Bug Hunter):

 

• اولاً نتأكد من الـ JWT الموجوده في الـ Request Header لأنها المرتبطه بالـ UserID في الـ Response
•  ثانياً: نتأكد من Database Lock ونتأكد اذا أغلق المنتج على User A في البداية وظهر رساله User B ان المنتج انتهى (وهذا يسمى HTTP 409 Conflict من ان يخطأ النظام في البيانات)  

• في النهاية نقوم بعمل Cleanup Verification لكي نضمن إن الـ Cache ليس بها أي Session قديمه.  

 اذا الأختبار تم وانتهى بسلام، هكذا ضمنت ان كل مستخدم لديه الـ Context الخاص به، حتى اذا الموقع حدث له مشكلة من كثر الطلبات او في حاله حدوث اي تداخل، فهذا يعني ان الـ Bug في الـ Memory Management او الـ State Handling، (عايز اضيف ان في الحالات دي لو حصلت لم المستخدم يعمل Ticket او يشتكي بالمشكلة)

 

 

 استكشاف الوظائف المستترة (Hidden Functions Discovery)

 هنا المشكلة نوعاً ما مختلفه، لأنها ليست في الزر المختفي في الواجهه، لكن المشكلة متواجده في الـ Backend Logic المتواجد ومنتظر اي طلب يستلمه، احياناً المطورين يقوموا ببناء خدمات للأداره او أدوات Debug Tools، ويتم أخفاء الروابط في الـ Frontend على اساس انها حماية، وهذا يسمى بـ Security By Obscurity وبالطبع لها مجال للأستكشاف:

 

أولاً تحليل الـ API Routes: وهو ليس الأكتفاء بالذي تراه وانت تفحص الموقع، او وانت تفحص الـ Target الذي تعمل عليه، ستبدأ بعمل revers لملفات الـ Js الذي يقوم بتحميلها المتصفح (استخدم Chromium)، وفي داخلها ستجد الـ APIs الذي من المفترض ان لا تظهر للمستخدم العادي مثل: /api/v1/internal/promote-user أو debug/get-logs

 

 ثانياً استخدام مفهوم Fuzzing: بمعنى يا صديقي استخدام الـ Wordlists ضخمة لمسارات شائعه مثل root او manage او config وتجرب على الـ endpoint رئيسيه 

 

تقنيات Tampering Techniques 

 هم ثلاث تقنيات (نفس القسم على فكره، والجزء ده في ثلاث تقنيات هشرحهم دلوقتي): 

 

اولاً Verb Switching: هنا المهاجم يأخد الطلب الـ GET (كـ مستخدم عادي) ويحوله PUT او POST ويضيف بيناتات تعديل الصلاحيات في الـ Body، واذا النظام بدأ في التحقق من الصلاحية بناءً على الـ Path فقط من دون ما يرى الـ Method سيقوم بتنفيذ الطلب (ودي مشكلة ده كده Bug)

 

ثانياً الـ  Method Overriding: هناك بعض من الـ Frameworks تسمح للماهجم بأستخدام Headers مثل X-HTTP-Method-Overriding اذا السيرفر يعتمد على هذا الـ Header، من الممكن اذا ارسل طلب Post عادي وأجبر انه يعامله كـ DELETE او PATCH من الممكن ان يحدث تجاوز لطبقات الحماية (طبقات الحمايه يعني الحماية الموجوده في الموقع مهما كانت طبيعتها)

 

ثالثاً استغلال الـ Statelessness: في انظمة الـ RESET API من المتفرض ان كل طلب يكون مستقل، لكن اذا المطور قام بعمل Authorization على مستوى Controller للـ Post فقط، فمن الممكن أن اي Method اخر سيمر كأنه Backdoor 

 

 

تحليل التوكنات وتلاعب البيانات الوصفية (JWT Analysis)

 

 المواقع التي تستخدم JWT، المختبر هنا يحاول ان يقوم بتفكيك تشفير الـ Token ويراجع الصلاحيات مثل Role او Scopes ويجرب تغيير القيمة يدوياً (زي من User الى admin) ويقوم بإرسال التوكن المعدل، واذا قبله السيرفر فهذا يعني ان هكذا هذا Bug لأنه فشل في التأكد من Signature قبل التأكيد من الطلب، واذا حدث استخدام مفاتيح تشفير ضعيفه فهذا ايضاً Bug، لأنه هيقدر يحعل نفسه Admin 

 

 

بصمات الـ Escalation: إزاي تلاحظ إن فيه 'مستخدم عادي' بيستهدف صلاحيات الـ Admin 

 

كفريق SoC دوماً يراقب علامات يراقبها في السجلات: 

 

  

•  نمط الأستكشاف الأداري: مستخدم طبيعي دوماًً يظهر له Forbidden 403 كثير وبشكل مستمر على روابط تخص الادمن، وبشكل مفاجأ يظهر له 200 Ok على رابط منهم 

• تغيير رتب مريبة: مستخدم عادي user تم اضافته لجروب sudoers او الـ Domain Admins من دون اي طلب رسمي 

• لعب في السجلات: وجود فجوات زمنية في الـ Logs او ملفات تم حذفها، وهذه محاوله في من المهاجم لكي يخفي التقدم في الصلاحيات  

  الخلاصة الاستراتيجية: بناء حصون رقمية مرنة

 تصعيد في الصلاحيات هو صراع السياده داخل النظام الرقمي، ونجاحك في الحماية ليس معتمد على الحماية الذي تضعها، لكن مدى الدقه في ترتيب الصلاحيات في أعمق طبقات الكود هو السر، ومن خلالها تستطيع التعيير في منهجية الفحص لدى المهاجم وفرض الرقابه عليه من جانبك انت كا ادمن للموقع، وسوف تستطيع تضييق على المهاجم في اقل مستوى صلاحيات وسوف تستطيع ان تحمي بيانات موقعك من اي خطر، لكن كمهاجم لن تستمر كثيراً