احتواء بيانات اعتماد EC2 المخترقة دون تعطيل الأمور (على أمل ذلك)

توجد أساليب متعددة لاحتواء بيانات اعتماد المثيلات المخترقة. الأساليب السهلة هي الأكثر احتمالاً لتعطيل الأمور، لكن هناك خيارات مبتكرة لإغلاق الباب أمام المهاجمين دون تعطيل التطبيقات.

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

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

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

وخلفية سريعة لمن لا يعرف: عند تخصيص دور IAM لمثيل ما، يُزوَّد ذلك المثيل ببيانات اعتماد تُدوَّر تلقائيًا وتمنحه أذونات ذلك الدور. لكن إذا تمكّن المهاجم من الوصول إلى المثيل بطريقة ما، مثل هجوم SSRF أو التخمين القسري لـ SSH، فبإمكانه نسخ بيانات الاعتماد تلك واستخدامها خارج AWS أو من حساب AWS يخضع لسيطرته.

وللإعداد، كتب Will تطبيقًا صغيرًا يحاول إنشاء اتصال داخلي بحاوية S3 ويُبلغ عمّا إذا كانت بيانات الاعتماد صالحة (لا، عناوين IP الظاهرة لم تعد صالحة):

الخيار الأول: إضافة سياسة رفض شامل إلى الدور

هذا هو الخيار الأسهل والأسرع بفارق كبير. فبإضافة سياسة رفض شامل إلى دور IAM، ستفشل جميع استدعاءات واجهة برمجة التطبيقات ولن يتمكن المهاجم من إحداث مزيد من الضرر.

إنه سريع وسهل، وطريقة سريعة جدًا لتعطيل تطبيقكم أيضًا، لأنه سيوقف أي استدعاءات مشروعة لواجهة برمجة التطبيقات:

تذكّروا، هدفنا هو إبقاء المهاجم خارجًا دون تعطيل تطبيقاتنا المشروعة قيد التشغيل.

عفوًا.

الخيار الثاني: إبطال الجلسة

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

الآن، بافتراض أنكم منعتم المهاجم من اختراق الجلسة الجديدة، فمن الناحية النظرية سيؤدي ذلك إلى إغلاق الباب أمامه بإنهاء صلاحية بيانات الاعتماد المسروقة والسماح لتطبيقكم بالعمل ببيانات اعتماد جديدة. لكن…

كلا. الزلة رقم 2. لماذا؟

لن تحدّث خدمة IMDS بيانات الاعتماد إلا عند انتهاء صلاحيتها. فـ IMDS خدمة مختلفة عن IAM ولا تعلم أنكم أبطلتم بيانات الاعتماد، وليس لديها سبب أو دافع لسحب بيانات الاعتماد الجديدة وتقديمها إلى المثيل. ستستمر في تقديم بيانات الاعتماد المُبطَلة حتى نهاية الجلسة.

الخيار الثالث: تغيير دور IAM ورفض الدور القديم

الآن نبدأ بالتعقيد قليلاً. ماذا لو أنشأنا دورًا جديدًا وغيّرنا المثيل لاستخدام الدور الجديد وحجبنا القديم؟ كما في السابق، لن ينجح ذلك إلا إذا كنتم على يقين من أن المهاجم لا يستطيع ببساطة سرقة بيانات اعتماد الدور الجديد.

كلا. الزلة رقم 3. إذن ما الذي يحدث هنا؟

تنشئ معظم الشيفرات وحزم SDK جلسة IAM عند بدء التشغيل وتسحب بيانات الاعتماد من خدمة البيانات الوصفية. ولهذه البيانات مدة جلسة، أشبه بمدة البقاء (TTL). وتُحفظ بيانات الاعتماد في الذاكرة وتُستخدم حتى قرب نهاية المدة. على سبيل المثال، عند استخدام مكتبة Boto في Python (وهو ما فعلناه في هذا العرض التوضيحي) لن تبحث الشيفرة عن بيانات اعتماد جديدة إلا قبل 15 دقيقة من انتهاء صلاحية بيانات الاعتماد.

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

لا تزال الشيفرة داخل المثيل تحاول استخدام الدور القديم لأنها لا تعرف غير ذلك. في الخيار الثاني عطّلنا الأمور لأن IMDS لم تكن تعرف أن عليها المراجعة مع IAM لتحديث بيانات الاعتماد. وهذه المرة لا تعرف الشيفرة أن عليها التواصل مع IMDS للحصول على بيانات اعتماد جديدة.

الخيار الرابع: إدراج نقطة نهاية VPC

هذا الخيار من ابتكاري، وهو الأكثر تعقيدًا بفارق كبير، لكنه يعمل بكفاءة عالية. تعيش جميع المثيلات داخل VPC (سحابة خاصة افتراضية) وهي شبكتها الافتراضية في AWS. وفي الوضع الطبيعي، تخرج جميع استدعاءات واجهة برمجة التطبيقات عبر الإنترنت للوصول إلى نقاط نهاية AWS العامة. بل إنه إذا كان لديكم مثيل في شبكة فرعية خاصة من دون مسار صادر إلى الإنترنت، فستفشل تلك الاستدعاءات.

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

يُعرف حل Amazon باسم نقطة نهاية الخدمة. وهي هياكل توجيه داخلية معرّفة بالبرمجيات يمكنكم إعدادها للسماح للموارد داخل VPC بالتواصل مع نقاط نهاية واجهة برمجة التطبيقات (وأشياء أخرى، لكن هذه ليست المقالة المناسبة للتوسع فيها) بالكامل عبر شبكة Amazon الداخلية. والأمر اللافت أنه عند استخدام نقطة نهاية VPC، تُدرج AWS سياقًا إضافيًا في حركة الشبكة لأنها تستطيع الآن تضمين بيانات في ترويساتها الخاصة، ويمكننا استخدام ذلك كشروط في سياسات IAM لدينا!

أولاً نضيف نقطة نهاية VPC لخدمة S3 إلى الشبكة الفرعية التي يوجد فيها مثيلنا:

ثم نضيف شرطًا إلى سياسة IAM لدينا يرفض كل حركة المرور إذا لم تأتِ من VPC المتوقعة. وهكذا نفعل ذلك في مختبر التدريب:

إذا نجح ذلك، ستظل استدعاءات واجهة برمجة التطبيقات من مثيلنا تعمل، لكن بيانات الاعتماد ستفشل إذا استُخدمت من أي مكان آخر خارج هذه الـ VPC (فلنأمل ألا يكون لدى المهاجم وصول إلى مورد آخر داخل الـ VPC).

رائع! لن تعمل بيانات اعتمادنا إلا من داخل الـ VPC، والمهاجم محجوب. وهذه بالضبط هي آلية عمل سياسة التحكم في الخدمات التي ذكرتها أعلاه. المشكلة في SCP أن نقاط نهاية الخدمة تضيف تكلفة وتعقيدًا، وتفعيل تلك السياسة من دون توفير جميع نقاط النهاية الصحيحة سيعطّل الأمور، لكن على نطاق المؤسسة هذه المرة.

سلوك غير متوقع

كما ذكرت، أنشأنا هذا المختبر قبل نحو عامين ودرّبنا فيه بضع مئات من الطلاب. في الأسبوع الماضي نشر Andre Rall من Uptycs ما يلي في أحد مجتمعات أمن السحابة التي نشارك فيها معًا (منشور بإذن منه):

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

تبيّن أننا نصطدم مرة أخرى بذلك التفاعل بين الخدمات. خلف الكواليس، ملف تعريف المثيل هو ما تستخدمه AWS لربط الدور بالمثيل في خدمة البيانات الوصفية. لقد أزال Adre الدور من ملف تعريف المثيل، لكن الدور لا يزال موجودًا وملف تعريف المثيل لا يزال موجودًا.

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

لاحتواء بيانات اعتماد IAM تفاصيل دقيقة كثيرة، وهذه مجرد مجموعة أمثلة من خدمة واحدة (EC2). لكن بمجرد أن تتبيّنوا تدفق تفاعل خدمة IAM مع IMDS ومع حزم SDK، ستمتلكون أساسًا متينًا في بعض المبادئ الجوهرية التي يمكنكم استخدامها في مواقف أخرى.

ولا تنسوا الاطلاع على الإصدار المجاني من FireMon Cloud Defense الذي أطلقناه للتو.