دراسة حالة: ثغرة SSRF واحدة، ونقطة بيانات وصفية واحدة، وحساب سحابي كامل
- Home
- المدونة
أنا جو — خبير أمن سيبراني مقيم في طوكيو. هذه جولة في مهمة حقيقية، بعد حذف تفاصيل العميل والمنتج والإبقاء على الشكل التقني كما هو. وهي هنا لأنها أشيع نتيجة خطيرة ما زلت أراها في التطبيقات السحابية الحديثة، ولأن كل فريق أعرضها عليه تقريبًا يقول الشيء نفسه أولًا: «لكن تلك النقطة داخلية». وتلك هي المشكلة بالضبط. «داخلي» ليس ضابطًا أمنيًا حين يكون خادمك أنت هو من يرسل الطلب.
-
الميزة التي فتحت الباب
أتاح التطبيق للمستخدمين استيراد صورة الملف الشخصي بلصق رابط. فيجلب الخادم ذلك الرابط ويخزّن النتيجة. هذا كل شيء — لا رفع ملفات، ولا محلّل، ولا شيء يبدو خطيرًا في مخطط معماري. لكن عبارة «الخادم يجلب رابطًا يتحكم فيه المستخدم» هي تعريف تزوير الطلب من جانب الخادم، والخادم يجلس داخل شبكة سحابية خاصة لها جيران كثيرون لا يستطيع متصفح الوصول إليهم أبدًا. وأول ما أختبره في أي ميزة كهذه ليس الإنترنت — بل ما يستطيع الخادم رؤيته ولا يستطيع المستخدم.
-
لماذا لم تصمد قائمة السماح
كان الفريق قد فكّر في هذا. فقد وُجدت قائمة حجب تشمل 127.0.0.1 وlocalhost والنطاق 10.0.0.0/8. لكنها فشلت للأسباب المعتادة، وقد استعرضتها واحدًا تلو الآخر: اسم مضيف يُترجم إلى عنوان داخلي يمرّ من فحص نصي؛ ورابط عام يجيب بإعادة توجيه 302 إلى رابط داخلي يُتبَع دون إعادة تحقق؛ وصيغ IPv6 — الاسترجاع المحلي، والعناوين الفريدة المحلية، وعناوين الوصلة المحلية، وIPv4 المُسقطة، وNAT64 — لم تكن في القائمة أصلًا؛ وبادئة معلومات المستخدم (http://trusted.example.com@169.254.169.254/) تخدع أي فحص يحلل المضيف يدويًا. التحقق من سلسلة نصية ليس تحققًا من وجهة.
-
من نقطة البيانات الوصفية إلى بيانات اعتماد حقيقية
كانت الحمولة المهمة مملة: خدمة البيانات الوصفية للمثيل السحابي على العنوان 169.254.169.254. وعلى هذا المضيف كانت لا تزال تجيب على طلبات الإصدار الأول، أي أن طلب GET عاديًا بلا رمز يعيد دور IAM المرتبط بالمثيل ثم مفتاح وصوله المؤقت وسرّه ورمز جلسته. لم أحتج إلى صدفة أوامر، ولا إلى اتصال عكسي، ولا إلى بايت واحد من برمجية خبيثة. احتجت إلى طلب HTTP واحد صُمّم التطبيق ليرسله نيابة عني، وعاد الرد معروضًا داخل رسالة خطأ التطبيق نفسه.
-
قياس نطاق الضرر قبل الإبلاغ عنه
النتيجة لا تفيد إلا بقدر الأثر الذي تستطيع إثباته، وإثبات الأثر يجب ألا يعني إحداثه أبدًا. وبموافقة خطية من العميل، استخدمت بيانات الاعتماد المستخرجة في استدعاءات للقراءة فقط: من أنا، وأي سياسات مرتبطة، وأي حاويات تخزين يستطيع هذا الدور سردها. وتبيّن أن الدور أوسع بكثير مما تحتاجه الميزة — إذ كان يستطيع قراءة مخزن الكائنات الذي يحوي مستندات العملاء. سجّلت استدعاء الهوية، وسرد السياسات، وسرد دليل واحد كأدلة، ثم توقفت. لم تُنزَّل أي بيانات، ولم يُعدَّل شيء، ووُثّق التسلسل كله بطوابع زمنية ليطابقه الفريق الأزرق بسجلاته.
-
الإصلاحات التي أغلقتها فعلًا
أربعة تغييرات، بالترتيب الذي نُشرت به. فرض IMDSv2 بحيث تتطلب خدمة البيانات الوصفية رمز جلسة لا تستطيع ثغرة SSRF إصداره، وضبط حد القفزات على 1. وإعادة تحديد نطاق دور المثيل ليقتصر على الإجراءين اللذين تحتاجهما الميزة بالضبط. وإضافة سياسة حركة صادرة بحيث لا يصل الجالب إلا إلى الإنترنت العام، لا إلى نطاقات الوصلة المحلية أو النطاقات الخاصة أبدًا. وأخيرًا، التحقق وقت الترجمة لا وقت التحليل: ترجم اسم المضيف، وافحص كل عنوان مُعاد مقابل قائمة منع للنطاقات الخاصة وذات الاستخدام الخاص في IPv4 وIPv6 معًا، ثم اتصل بذلك العنوان المترجَم كي لا يستطيع DNS تغيير إجابته بين الفحص والطلب.
-
لماذا حوّلت هذا إلى مكتبة برمجية
ظللت أكتب شفرة التحقق من الروابط نفسها في مهمة بعد مهمة، وظللت أرى الفرق تخطئ فيها بفروق دقيقة — في IPv6 أو في إعادة التوجيه عادةً. فحزمتها: DSSRF، مكتبة JavaScript صغيرة برخصة MIT تتحقق من الرابط وتنقّيه قبل أن يرسل عميلك الطلب. وهي مدرجة الآن لدى مؤسسة OWASP ضمن أدوات أمن التطبيقات المجانية مفتوحة المصدر، ولها ثغرات CVE منشورة خاصة بها، لأنني أواصل مهاجمة مكتبتي وإصلاح ما أجده. وتلك هي الفكرة — أداة دفاع لا يهاجمها أحد ليست سوى افتراض مريح.
-
ما الذي كنت سأفحصه في بيئتك غدًا
اجرد كل موضع يجلب فيه خادمك الخلفي رابطًا يقدّمه المستخدم: استيراد الصور الرمزية، وخطافات الويب، ومولّدات ملفات PDF ولقطات الشاشة، ومعاينات الروابط، واستقبال تلقيمات RSS، وبيانات الدخول الموحّد الوصفية، وفحوص الصحة. واسأل عن كل واحد ثلاثة أسئلة. هل يستطيع الوصول إلى 169.254.169.254 أو أي نطاق خاص؟ وهل يتبع إعادة التوجيه دون إعادة تحقق؟ وهل الهوية التي يعمل بها تملك صلاحيات أكثر مما تحتاجه الميزة؟ إن كان الجواب عن أي منها نعم، فلديك دراسة الحالة نفسها تنتظر الوقوع — ولن تبقى نظرية طويلًا.
التعليقات (5)
-
cloud_arch_maya قبل يومين ردفرضنا IMDSv2 في الربع الماضي بعد قراءة شيء مشابه واستغرق الأمر بعد ظهيرة واحدة. تفصيلة حد القفزات هي ما يفوّته الناس.
-
وكذلك نحن. الجزء الصعب كان العثور على كل جالب، لا الإصلاح نفسه. خدمة معاينة الروابط لدينا كانت تلك التي لم يتذكرها أحد.
-
-
أوقعت بنا حيلة بادئة معلومات المستخدم في مراجعة كود الشهر الماضي. بدا تعبيرنا النمطي معقولًا تمامًا حتى أراه أحدهم ذلك الرابط.
-
أقدّر توقفك عند سرد دليل واحد. تقارير كثيرة جدًا «تثبت الأثر» بتسريب شيء ما كان ينبغي أن تمسّه.
-
دائمًا. نطاق مكتوب أولًا، ثم استدعاءات للقراءة فقط، وطوابع زمنية تُسلَّم للمدافعين. الإثبات يجب ألا يكلّف العميل شيئًا أبدًا.
-