الكشف عن eBPF: تسخير قوتها لحل قضايا العالم الحقيقي

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

في هذا الجزء الثاني، نستخدم إمكانات eBPF لتوضيح سبب فعالية هذا الحل وكيف يمكن أن يساعدنا في الإجابة على الأسئلة التالية:

• هل كانت محاولة الهروب من حاوية قام بها فاعل خبيث؟

• هل تم تنفيذ العملية باستخدام إدخال مأخذ توصيل غير قياسي، مما يمثل هجومًا لتنفيذ التعليمات البرمجية عن بُعد (RCE)؟

• هل كانت هناك محاولة للوصول إلى “/etc/shadow”؟

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

تتيح تقنية eBPF التنفيذ الآمن للبرامج داخل Linux kernel من خلال برامج وضع الحماية. لاستخدام eBPF، يحتاج المرء إلى إصدار Linux kernel 3.18 أو أعلى ويمكنه الرجوع إلى صفحات syscall وman bpf(2) لمزيد من المعلومات. يعمل eBPF كجهاز افتراضي مع مجموعة تعليمات RISC 64 بت. باستخدام eBPF، يمكنك الاتصال بمسارات كود kernel والتقاط أحداث إمكانية ملاحظة الأمان في الوقت الفعلي دون التسبب في أي انقطاع في التطبيق. يمكن إعادة توجيه هذه الأحداث إلى مساحة المستخدم وحفظها للتحليل المستقبلي أو التحقيق في الحوادث أو البحث عن التهديدات أو إنشاء سياسة أمنية.

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

إذًا كيف يمكنك اكتشاف الملفات التنفيذية التي يتم إطلاقها داخل الحاوية؟ إحدى التقنيات للقيام بذلك هي eBPF.

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

التظاهر بأن أحد المتسللين لديه حق الوصول إلى المجموعة، كخطوة تالية للهجوم، كيف يمكنهم الوصول إلى نظام الملفات المضيف؟ من خلال نشر POD مع تعيين امتيازات سياق الأمان على “صحيح”، فإنه يخدع جميع آليات وضع الحماية داخل POD، والتي يتم تمكينها بواسطة Kubernetes افتراضيًا، مما يعني أن الكبسولة يمكنها الوصول إلى موارد المضيف وقدرات kernel (بما في ذلك CAP_SYS_ADMIN: true و CAP_NET_RAW: true = root).

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  hostPID: true
  hostNetwork: true
  containers:
  - name: privileged-pod
    image: nginx:latest
    ports:
    - containerPort: 80
    securityContext:
      privileged: true

تنفيذ وكسر

بمجرد إنشاء الكبسولة، فإن مجرد تنفيذ الأمر kubectl كما يلي سيسمح لك بالهروب من الكبسولة:

➜ ~ kubectl get pods

➜ ~ kubectl exec -it privileged-pod -- nsenter -t 1 -m -u -n -i -p bash  

nsenter --target 1 يسمح لنا بالدخول إلى مساحة اسم المضيف. كما أنه يقوم أيضًا بتثبيت وحدة تخزين المضيف والوصول إلى شبكة المضيف والعمليات ثم تشغيله كـ bash، والخروج من الحاوية بكل طريقة ممكنة.

باستخدام eBPF، يمكننا مراقبة وقت تشغيل الحاوية والمضيف نفسه لأنشطة النظام في الوقت الفعلي.

دعونا نلقي نظرة على سيناريو آخر، من منظور اختبار القلم، لنرى كيف يمكن أن يساعد eBPF في اكتشاف مثل هذه الهجمات.

استطلاع الهجوم

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

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

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

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

بعد الوصول إلى الصفحة في المنفذ غير المشفر، نرى أننا وصلنا إلى تطبيق داخلي مخصص يأخذ المدخلات ويوفر رمز Base64.

من خلال التحقق من الكود المصدري للتطبيق، نرى أنه يفتقد التحقق من صحة الإدخال، لذلك سيقوم التطبيق بتنفيذ أي أوامر من المستخدمين. الآن بعد أن علمنا أن التطبيق المستهدف عرضة لـ RCE، سنستغل هذه الثغرة الأمنية للوصول إلى المضيف.

اختبرنا باستخدام ls الأمر وحصلت على قيمة الإرجاع.

استغلال الثغرة الأمنية

الخطوة الأولى هي إعداد مستمع الصدفة باستخدام netcat الأمر في آلة اختبار القلم الخاصة بنا وتنفيذ الحمولة النافعة، التي تنفذ الصدفة البعيدة (RCE) في التطبيق. فيما يلي مثال لإعداد مستمع الصدفة:

nc - lvp 4444 

تم إنشاء الحمولة لتشغيل أمر الصدفة العكسية Bash على مضيف الضحية للاتصال بجهاز المهاجم، والذي من شأنه أن يبدأ الصدفة التفاعلية وتشغيلها /bin/sh. توضح الشاشة أدناه أننا حصلنا على حق الوصول.

من خلال إجراء مراجعة أولية على هذا المضيف، يمكننا أن نرى أننا حصلنا على إمكانية الوصول إلى عقدة Kubernetes.

تصعيد الامتيازات

للتفاعل مع المجموعة، سنقوم بتنزيل kubectl من جهاز Kali Linux المهاجم الخاص بنا، ومن خلال تشغيل بعض أوامر التعداد البسيطة، يمكننا أن نرى أن لدينا حق الوصول الكامل إلى المجموعة والقدرة على إدراج وإنشاء Pods.

يمكننا قراءة الرمز السري لحساب الخدمة في المجموعة التي تم اختراقها مؤخرًا.

وللقيام بذلك استخدمنا هذا الأمر:

./kubectl get secret admin-service-account-token –o yaml  

الآن، يمكننا إنشاء كبسولات جديدة باستخدام الرمز المميز لحساب الخدمة المحدد كمتغير بيئة.

نحن نركض:

./kubectl get pods –A –token=${TOKEN} 

من المهم التفكير في كيفية منع الخروقات الأمنية مثل هروب الحاويات وهجمات RCE في المقام الأول. فيما يلي بعض التدابير التي يمكن أن تساعد:

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

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

• إمكانية المراقبة والأمن في وقت التشغيل: يمكن أن يساعدنا استخدام eBPF مع إمكانات الحماية في وقت التشغيل والحصول على رؤية كاملة للأنشطة في المجموعة في اكتشاف المهاجم وإيقافه في وقت مبكر من الهجوم.

أصدر Wiz مستشعر وقت التشغيل الذي يستخدم برنامج eBPF لمراقبة Kubernetes والبيئات المعبأة في حاويات في الوقت الفعلي. يجمع المستشعر مكالمات النظام المستهدفة التي تم التقاطها بواسطة eBPF ويرسلها إلى حل SaaS المستند إلى السحابة من Wiz. باستخدام هذه المعلومات، يمكن لـ Wiz تحديد الملفات الضارة وعناوين IP والمجالات والسلوك الضار والكشف عن الحالات الشاذة. تسمح شجرة العمليات لمشغلي الأمن برؤية الاتصالات بين أنشطة العملية وجلسات المستخدم واتصالات الشبكة عبر الحاويات والأنظمة. يكتشف Wiz أيضًا سلوكيات عبء العمل تلقائيًا، مما يجعل من الممكن اكتشاف السلوكيات الجديدة في الوقت الفعلي. في أحد الأمثلة، حدد المستشعر مقبس إدخال غير قياسي لشبكة بعيدة (غطاء عكسي) أثناء الهجوم.

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

اكتشف Wiz Sensor وجود أداة شبكة قيد الاستخدام؛ في هذه الحالة، netcat الأمر بغرض الحصول على Shell:

عندما قمنا بنشر POD الخبيث الخاص بنا، اكتشفنا أيضًا تنفيذ إنشاء Pods والقراءة /etc/shadow ملف:

في هذه المدونة، أظهرنا نواقل الهجوم في Kubernetes وكيف أنه من المحتمل جدًا أن تكون مجموعات Kubernetes الخاصة بك هي الهدف الأساسي للمتسللين. لقد أظهرنا أن الاستفادة من eBPF من أجل أمان وقت التشغيل وإمكانية المراقبة أمر مهم لتقليل مساحة سطح الهجوم في مجموعات Kubernetes وكيف يكتشف Wiz Sensor التقنيات الضارة مثل الهروب من الحاوية، وتنفيذ التعليمات البرمجية عن بعد، والحركة الجانبية، والاستمرارية. لمعرفة المزيد حول مستشعر وقت التشغيل، قم بمراجعة الافراج عن بلوق وظيفة.