العميل الأحمر بوف: كيف فكر في طريقه إلى SSRF

في أول مدونة متعمقة في سلسلة Red Agent POV، سنركز على استغلال تزوير الطلب من جانب الخادم (SSRF) الذي اكتشفه Red Agent، والذي يعد أحد فئات الأخطاء الأكثر شيوعًا وتأثيرًا في التطبيقات السحابية الحديثة. في هذا الاستغلال، عثر العميل الأحمر على سلسلة هجوم مهمة متعددة الخطوات سمحت بقراءة الملف المحلي SSRF على واجهة برمجة تطبيقات GCP Cloud Run.

أولا، ما هو SSRF؟

يحدث تزوير الطلب من جانب الخادم (SSRF) عندما يقوم أحد التطبيقات بتقديم طلب شبكة صادر بناءً على الإدخال المقدم من المستخدم دون التحقق من الصحة بشكل صحيح. غالبًا ما يكون جلب الموارد البعيدة هو سلوك التطبيق المقصود – ولكنه يصبح خطيرًا عندما يكون الخادم داخل شبكة ذات امتيازات. يمكن للمهاجم إساءة استخدام موضع الشبكة الموثوق به للخادم لإجباره على التفاعل مع الخدمات الداخلية فقط (مثل قواعد البيانات أو لوحات الإدارة)، أو الاستعلام عن نقاط نهاية البيانات الوصفية السحابية لاستخراج بيانات الاعتماد، أو حتى قراءة الملفات المحلية باستخدام أنظمة URI البديلة مثل file:// في الواقع، يقوم المهاجم بتحويل الخادم إلى وكيل لجواهر التاج الخاصة بالمنظمة.

ماذا اكتشف العميل الأحمر؟

اكتشف العميل الأحمر ثغرة أمنية في SSRF حيث قبلت خدمة GCP Cloud Run للإنتاج ملف ?url= المعلمة واستخدمها لجلب ملف نيابة عن المستخدم. كان المطورون يعلمون أن أداة جلب عناوين URL خطيرة، لذا قاموا بإغلاقها: فالمعلمة قد تكون خطيرة فقط قبول عنوان URL صالح هيكليًا لـ GitHub blob. أي شيء لم يبدو كذلك https://github.com/{owner}/{repo}/blob/{branch}/{path} تم رفضه.

قام Red Agent بتحويل أداة جلب “GitHub فقط” إلى قراءة غير مصادق عليها لنظام الملفات المحلي للمضيف – حيث قام بسحب بيانات اعتماد حساب خدمة GCP المباشرة من /proc/self/environ وإلقاء كود المصدر الكامل للتطبيق. كانت بيانات الاعتماد حقيقية، وعملت ضد واجهات برمجة تطبيقات Google Cloud Platform المباشرة.

كيف وجدت الاستغلال؟ منهجية الذكاء الاصطناعي للمهاجم

يقوم Red Agent بالفحص في عمليات التشغيل والتكرارات حيث ينفذ استراتيجيات هجوم مختلفة بالتوازي بما في ذلك اختبار اجتياز المسار، وارتباك عنوان URL، وتقنيات الحقن. بين التكرارات، يعكس Red Agent ما نجح، وما تم حظره، وما يكشفه سلوك التطبيق عن منطقه. تعتمد كل جولة على الجولة الأخيرة مما يسمح للعميل الأحمر بصقل فرضياته وتطوير حمولاته.

الهدف

كان هدف Red Agent هو خدمة GCP Cloud Run: <redacted>.run.app/f. حددت في البداية أن نقطة النهاية قبلت أ ?url= المعلمة، وبعد ذلك كان عليه أن يفكر فيما فعله التطبيق بهذه المعلمة.

المرحلة 1: الاستطلاع والتحقق من خط الأساس

تلقى العميل الأحمر نقطة النهاية المستهدفة /f إلى جانب البيانات الوصفية التي تشير إلى أنها خدمة GCP Cloud Run التي تقبل ملف ?url= المعلمة. تعد معلمة جلب عنوان URL في حاوية Cloud Run مرشحًا كلاسيكيًا لـ SSRF حيث تم تصميم التطبيق لتقديم طلبات صادرة نيابة عن المتصل، ويمكن لحاويات Cloud Run الوصول إلى خادم البيانات التعريفية لـ GCP للحصول على الرموز المميزة لحساب الخدمة وبيانات اعتماد المشروع. لذلك كانت خطوتها الأولى هي اختبار ما إذا كان بإمكانها إعادة توجيه هذا الجلب إلى خادم البيانات التعريفية لـ GCP على http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token– أسرع طريق لسرقة بيانات الاعتماد إذا ثبت نجاحه. ومع ذلك، لم يتم التحقق من صحة واجهة برمجة التطبيقات (API) من أن عنوان URL يشير إلى GitHub، مما أدى إلى حظر المحور المباشر للبيانات التعريفية. الآن عرف العميل الأحمر القيد وأن أي تقنية سيحاول تجربتها بعد ذلك ستحتاج إلى تلبية مدقق عنوان URL المرتبط بـ GitHub.

المرحلة الثانية: اجتياز المسار الكلاسيكي

منذ ?url= تتمثل مهمة المعلمة في جلب محتويات الملف، وافترض Red Agent أن الواجهة الخلفية تقوم في النهاية بتحليل عنوان URL إلى نظام ملفات محلي للقراءة، وتنزيل ملف GitHub على القرص (أو ملف /tmp المسار في الحاوية) قبل إعادته. إذا كان هذا صحيحًا، فإن إدخال تسلسلات الاجتياز في عنوان URL قد يؤدي إلى الهروب من الدليل المقصود وقراءة ملفات عشوائية. تم رش ?url= معلمة ذات متغيرات اجتياز، تم تصميم كل منها لتجاوز فئة مختلفة من مرشح التعقيم:

• معيار: ../../../../etc/passwd

• عنوان URL المشفر: %2f..%2f..%2ffetc%2fpasswd 

• مزدوج التشفير %252f..%252f

• بايت فارغ: ..%00/etc/passwd

• شرطة مائلة عكسية: ..%5c..%5c

• يونيكود الطويل: ..%c0%af..%c0%af

• الالتفافية غير العودية: ....//....//

استهدفت مسارات خاصة بالحاوية: /app/main.py (نقطة دخول التطبيق)، /proc/self/environ (بيانات اعتماد وقت التشغيل ومتغيرات البيئة)، و /app/requirements.txt (بيان التبعية) لأن هذه هي الأماكن التي توجد فيها البيانات ذات القيمة العالية في حاوية Cloud Run. تم حظر جميع المحاولات – لم يكن مدقق عنوان URL يتحقق من النطاق فحسب، بل كان يرفض أي شيء لا يبدو وكأنه عنوان URL ثنائي كبير الحجم لـ GitHub.

المرحلة 3: ارتباك عنوان URL وSSRF

أثبت اجتياز المسار عدم نجاحه، حيث لم يكن المدقق يفحص مكون المسار فحسب – بل كان يحلل بنية عنوان URL بالكامل. لذلك غيّر Red Agent أسلوبه: فبدلاً من التلاعب بمكان قراءة الملف على القرص، قرر محاولة خداع محلل URL ليجلبه من مضيف مختلف تمامًا. ال ?url= يتم تمرير المعلمة إلى عميل HTTP الخاص بالواجهة الخلفية، والذي يحل اسم المضيف ويقدم طلبًا صادرًا. إذا قام المدقق وأداة الجلب بتحليل عنوان URL بشكل مختلف، وهو تفاضل محلل كلاسيكي، فقد يؤدي ذلك إلى جعل المدقق يرى “github.com” بينما يتصل الجلب فعليًا بخادم البيانات الوصفية لـ GCP (`metadata.google.internal`). لقد تم اختبار العديد من تقنيات الارتباك ضد ?url= المعلمة:

لكن لم ينجح أي منها، وكان المدقق صارمًا بشأن كلا المخططين (https://) واسم المضيف الذي تم حله. أخبر هذا العميل الأحمر بشيء مهم: يقوم الخادم بإرسال طلبات HTTP حقيقية صادرة إلى أي مضيف يحل عنوان URL له. منطق الجلب ليس مزيفًا أو وكيلًا – إنه عميل HTTP حقيقي. خلص العميل الأحمر إلى أنه يحتاج فقط إلى طريقة لإرضاء المدقق أثناء توجيه عملية الجلب إلى مكان مفيد.

المرحلة 4: حقن اسم الريبو

قام العميل الأحمر أيضًا باختبار حقن اسم الريبو. لقد افترضت أن الواجهة الخلفية قد تقوم ببناء مسار محلي من اسم المستودع الذي تم تحليله، لذلك قامت بحقن سلاسل الاجتياز مباشرة في مكون الريبو: – github.com/owner/..%2f..%2fapp/blob/main/main.py – github.com/owner/..%2f..%2fetc/blob/main/passwd.

المرحلة 5: تعداد الريبو الحقيقي

لفهم التطبيق الذي كان يهاجمه بشكل أفضل، بدأ العميل الأحمر في أخذ بصمات البيئة من خلال اختبار مستودعات حقيقية مرتبطة بـ Google Cloud Platform (على سبيل المثال، GoogleCloudPlatform/graph-explorer, googleapis/graph-explorer, google/graph-explorer). وقد ساعد ذلك في تخمين اصطلاحات التسمية الداخلية ذات الصلة، مثل graph-explorer-file-reader.

المرحلة 6: الاختراق – المسار المطلق ذو الشرطة المائلة المزدوجة

عند هذه النقطة، كان العميل الأحمر قد بنى نموذجًا عقليًا تفصيليًا للتطبيق من أكثر من 80 محاولة فاشلة:

• ال ?url= يجب أن تحتوي المعلمة على عنوان URL صالح من الناحية الهيكلية لـ GitHub blob (المخطط، المجال، المالك، الريبو، /blob/، فرع ، مسار)

• يتم رفض أي شيء آخر حتى قبل حدوث الجلب (يتم تعلمه في المراحل 1-3)

• تقوم الواجهة الخلفية بتقديم طلب HTTP حقيقي إلى عنوان URL الذي تم حله

• لا يقتصر الأمر على تحليل المسار محليًا (تم تعلمه في المرحلة 3)

• التطبيق مرتبط ب graph-explorer ويعمل على Cloud Run باستخدام كود المصدر في /app/ (تم تعلمه في المراحل 4-5)

لذلك، كان على العميل الأحمر معرفة ما يلي: هل يمكنه إنشاء عنوان URL الذي يجتاز التحقق من صحة GitHub ولكنه يتسبب في أن يقوم منطق قراءة الملف بحل المسار المحلي بدلاً من ذلك؟ هذا هو المكان الذي تجتمع فيه طبقتان من الاستغلال:

• الطبقة 1 – إرضاء المدقق: يجب أن يبدو عنوان URL كمرجع GitHub blob شرعي: https://github.com/{owner}/{repo}/blob/{branch}/{path}. يتم قتل أي طلب ينحرف عن هذه البنية.

• الطبقة الثانية – تقنية الالتفافية: اكتشف الوكيل الأحمر تلك الإضافة // متبوعًا بمسار مطلق لنظام الملفات بعد أن تسببت بنية URL الصالحة لـ GitHub في قيام منطق جلب الملف بتفسير الجزء اللاحق كمسار مطلق محلي، بينما قام المدقق بالتحقق من البادئة فقط. ال // ليست الحمولة نفسها – إنها آلية الالتفافية التي تسمح للحمولة الحقيقية (/proc/self/environ, /app/graph_api.py) تنزلق من خلال. يرى المدقق عنوان URL صالحًا لـ GitHub بينما يرى الجلب مسارًا مطلقًا.

الحمولات الفائزة:

• ?url=https://github.com/x/y/blob/z//proc/self/environ (تم إرجاع 4,096 بايت)

• ?url=https://github.com/x/y/blob/z//var/task/graph_api.py (تم إرجاع 25000 بايت)

هذا هو ما يبدو عليه تكيف المسح: بدلاً من مجرد تجربة المزيد من الحمولات، قام العميل الأحمر بتجميع القيود المكتشفة عبر العشرات من التحقيقات الفاشلة في تقنية أرضت المدقق واستغلت أداة الجلب في وقت واحد.

مسار القرار

النتائج المؤكدة

بمجرد أن أنشأ العميل الأحمر قراءة الملف بدائية، لم يتوقف الأمر عند الترشيح – بل تحقق من صحة التأثير من البداية إلى النهاية. وإليكم ما تم استخراجه وتأكيده:

لماذا هذا مهم

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

الحمولة النهائية, github.com/x/y/blob/z//proc/self/environ، غير موجود في أي قائمة كلمات أو قاعدة بيانات للتوقيع، وفي الوقت نفسه لا يمكن العثور عليه بالقوة الغاشمة. كشف استغلال العميل الأحمر هذا عن الفهم والتفكير المطلوبين.

يتطلب الأمر إدراك أن المدقق يفرض بنية عنوان URL لـ GitHub، وأن أداة الجلب تحل المسارات بشكل مختلف عن المدقق الذي يوزعها، وأن // بمثابة مرساة المسار المطلق الذي ينزلق عبر الفجوة بين الاثنين. تم بناء هذا الفهم بشكل تدريجي عبر 96 طلبًا للاختبار والفشل والتعلم والتكيف.

في كل مرة واجه فيها العميل الأحمر محاولة محجوبة، كان ذلك عائقًا أدى إلى تضييق مساحة الحل لاستكشافه. كشف اجتياز المسار المحظور عن تحليل صارم لعنوان URL، وأكد ارتباك عنوان URL المحظور أن أداة الجلب تجري مكالمات HTTP حقيقية، وأكد حقن اسم الريبو المحظور وجود إنشاء مسار محلي. تقع حمولة الاختراق عند تقاطع كل هذه الملاحظات.

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

تأثير هذه المخاطر القابلة للاستغلال، في هذا المثال، هو الوصول غير المصادق إلى بيانات اعتماد Google Cloud Platform وشفرة المصدر الكاملة – وهي سلسلة تسوية كاملة من معلمة عنوان URL واحدة.

هل تريد رؤية المزيد من العميل الأحمر؟

سنشارك المزيد من الأمثلة على المخاطر التي يكشف عنها Red Agent. إذا كنت ترغب في معرفة أنواع المخاطر التي يمكن أن تجدها في بيئتك، فتعرف على المزيد حول Red Agent (يتطلب تسجيل الدخول) أو قم بجدولة عرض توضيحي مباشر مع فريقنا.