سكربت كشف حالة التصحيح لانتحال وكيل Veeam Service Provider Console

أداة كشف آمنة وغير مصادق عليها لثغرات KB4893 في Veeam Service Provider Console (نُشرت في 2026-08-04). تجيب على سؤال واحد لكل هدف، قبل أي مصادقة أو TLS: هل إصلاحات KB4893 موجودة على هذه الكونسول؟

الزوج الرئيسي هو سلسلة. CVE-2026-58073 (CVSS 9.5) تسمح لنظير شبكة غير مصادق عليه بانتحال وكيل إدارة متصل والحصول على شهادة ذلك الوكيل الحقيقية، لأن مصافحة الوكيل تحدد التفويض من GUID الذي كتبه النظير في شهادته الخاصة. CVE-2026-58072 (CVSS 9.0) هي كتابة ملفات تعسفية يمكن الوصول إليها بمجرد امتلاك هوية وكيل. عند ربطهما، تشكلان تنفيذ كود عن بُعد غير مصادق عليه على الكونسول التي تدير نسخ احتياطية لكل مستأجر. نفس النشرة تصلح أيضًا CVE-2026-58071 (CVSS 8.2، واجهة برمجة تطبيقات الأجهزة عبر وكيل كمسؤول بوابة) وCVE-2026-58067 (CVSS 8.7، رفض خدمة غير مصادق عليه باستنزاف الذاكرة). تم الإبلاغ عن CVE-2026-58073 وCVE-2026-58072 إلى Veeam عبر HackerOne؛ النشرة لا تذكر اسم المُبلِّغ.

هذا السكربت لا يحاول الانتحال، أو طلب شهادة، أو كتابة ملف. يقرأ جيل البروتوكول المُعلن عنه من الموجّه ولا شيء آخر.

هل من الآمن تشغيله؟

نعم. صُمم المكتشف للاستخدام في الإنتاج والتقييم:

• لا تتم محاولة أي مصادقة، ولا يتم استغلال أي من الثغرتين. يرسل فقط مصافحة Connector تسمي مستقبلًا لن يكون موجودًا. لا يتم التفاوض على جلسة TLS، ولا يتم تقديم شهادة، ولا يتم استدعاء SaveFiles أبدًا.
• لا تتغير حالة الهدف. الإجراء الوحيد للخادم هو بحث قاموس فاشل في ChannelHostProxy.m_multiplexers. لا يتم تسجيل مستقبل، ولا يتم بناء قناة أو مضاعِف، ولا يتم لمس سجل وكيل. مصافحة من نوع Receiver ستسجل اسمًا؛ هذه الأداة لا ترسلها أبدًا.
• بصمة السجل موثقة ويمكن نسبها. اتصالان TCP وستة أسطر في ConnectionHub.log، يحمل كل منها اسم المستقبل bf-probe-<uuid4> حتى يتمكن المدافع من تمييز الفحص عن الهجوم. الأسطر الدقيقة أدناه.
• حارس النتائج الإيجابية الخاطئة. لا يتم الإبلاغ عن الهدف أبدًا على أنه VULNERABLE إلا بعد إثبات أنه ConnectionHub لـ VSPC (انظر أدناه)، لذا لا يمكن الخلط بين خدمة TCP صامتة وكونسول غير مصحح.

ما يتركه على الهدف

لكل هدف تفتح الأداة اتصالين TCP وترسل مصافحة ConnectionHub واحدة على كل منهما، تسمي مستقبلًا bf-probe-<uuid4> لن يكون موجودًا.

تحت النقل الافتراضي --transport auto، الهدف الذي لا يكون نقله هو النقل المُشار إليه بمنفذه يكلف اتصالًا إضافيًا واحدًا: يتم رفض فحص النقل الخاطئ أثناء المصافحة، قبل قراءة أي اسم مستقبل، ثم يُستخدم النقل الصحيح لكلا الفحصين الحقيقيين. ثبّت --transport direct أو --transport gateway لإبقائه على اتصالين بالضبط — وهو أمر يستحق القيام به إذا كنت قد حددت عدد اتصالات في طلب تغيير.

الحالة المتغيرة على الخادم: لا شيء. مسار كود Connector ينفذ بحث قاموس في ChannelHostProxy.m_multiplexers، يفشل، ويعيد خطأ. لا يتم تسجيل مستقبل، ولا يتم إنشاء مضاعِف أو قناة، ولا يتم التفاوض على جلسة TLS، ولا يتم لمس سجل وكيل. هذه الأداة لا ترسل أبدًا مصافحة من نوع Receiver، وهي التي ستسجل اسمًا.

تُكتب إدخالات السجل إلى %ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log. حرفيًا من ConnectionHub حي 9.2.1.33875، مع اقتطاع الطوابع الزمنية وJSON النطاق:

الفحص 1 (الإصدار 6)، كل من البنيات المصححة وغير المصححة:
    [INFO] ChannelHostProxy: Accept connection begin {"RemoteEndPoint":"<ip>:<port>","Line":"1"}
    [INFO] ChannelHostProxy: Accept connection end   {"RemoteEndPoint":"<ip>:<port>","Line":"2",...}
    [WARN] ChannelHostProxy: Cannot connect transmitter. Requested receiver not found
           (receiver name:bf-probe-<uuid>) {"RemoteEndPoint":"<ip>:<port>","Line":"3",...}

الفحص 2 (الإصدار 7)، البنيات المصححة فقط:
    نفس الأسطر الثلاثة

الفحص 2 (الإصدار 7)، البنيات غير المصححة:
    [INFO] ChannelHostProxy: Accept connection begin
    [WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
    [INFO] ChannelHostProxy: Accept connection end

اتصالان، ستة أسطر، لا إدخالات أخرى ولا تغيير حالة — مؤكد على مضيف حي.

السلسلة الحرفية bf-probe- في ConnectionHub.log تحدد حركة مرور هذه الأداة، لذا يمكن للمدافع نسبها ويمكن لفريق الفحص إثبات ما أرسلوه. غيّر RECEIVER_PREFIX في المصدر إذا كنت بحاجة إلى علامة مختلفة.

كيف يعمل

يقرأ موجّه وكيل إدارة ConnectionHub مصافحة العميل قبل أي مصادقة أو TLS، وRequest.Read يتحقق من إصدار البروتوكول المُعلن من العميل مقابل نطاق مكتوب في الكود. ال إصلاح وسّع ذلك النطاق في نفس البنية التي أصلحت CVEs:

البنية	الفحص	يقبل
<= 9.2.1.33875 (قابل للاستغلال)	(uint)(versionByte - 3) <= 3	3، 4، 5، 6
>= 9.3.0.35057 (مصحح)	(uint)(versionByte - 3) <= 4	3، 4، 5، 6، 7

لذا فإن مصافحة تعلن الإصدار 7 هي مميز ثنائي نظيف. يرسل المكتشف فحصين لكل هدف، بهذا الترتيب لسبب (كشف النقل يمكن أن يضيف ثالثًا — انظر أدناه):

الفحص	يُعلن	الغرض
1	الإصدار 6	يجب أن يعيد Requested receiver not found، مما يثبت أن الهدف هو حقًا ConnectionHub لـ VSPC
2	الإصدار 7	الرد يعني PATCHED؛ الصمت يعني VULNERABLE

بدون بوابة المرحلة الأولى، الصمت في الفحص 2 يطابق أيضًا أي خدمة TCP صامتة على الإنترنت، وسيتم الإبلاغ عن جدران الحماية ككونسولات Veeam قابلة للاستغلال.

كلا النقلين، مُكتشف لكل هدف

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

النقل	المنفذ	التعرض
مباشر إلى ConnectionHub	9999	داخلي عادةً
عبر بوابة Veeam Cloud Connect	6180	مواجه للإنترنت بالتصميم

مسار البوابة يحتاج مقدمة ترحيل لا يجب أن يمتلكها المسار المباشر، لذا الفحص 1 يعمل مزدوجًا ككشف نقل. تحت --transport auto الافتراضي يحاول نقلًا واحدًا، وإذا لم تمر بوابة البصمة، يحاول الآخر. أيًا كان ما يمر يتم تثبيته، والفحص 2 يعيد استخدامه — ملف أهداف مختلط لا يحتاج تعليقًا لكل مضيف.

التثبيت حاسم. إذا كان الفحص 2 يمكنه إعادة المحاولة على النقل الآخر، فلن يكون الصمت بعد الآن قابلًا للنسبة إلى فحص الإصدار، فقط إلى "أحد مساري البايت لم يرد"، وهو كيف يُصنع VULNERABLE خاطئ.

أي نقل يُحاول أولًا يُقرر بالمنفذ، وهذا ليس تجميليًا — ال عدم التطابقان يفشلان بسرعات مختلفة جدًا:

عدم التطابق	كيف يقرأه الطرف البعيد	التكلفة
مقدمة الترحيل → مركز مباشر	int16 بيانات وصفية لـ hostType 44 / versionByte 0، يفشل فحص نطاق Request.Read	يُتخلص منه في رحلة ذهاب وإياب واحدة
مصافحة مباشرة → بوابة	int32 طول إطار 1,012,729,346	البوابة تنتظر بايتات لا تصل أبدًا؛ تحرق المهلة الكاملة

لذا auto يبدأ بالخدمة التي تملك المنفذ: بوابة أولًا على 6180، مباشر في كل مكان آخر. هذا يبقي الحالة الشائعة عند محاولة واحدة وعدم التطابق المكلف خارج المسار السريع. الفحص الذي يفشل في فتح TCP تمامًا يقصر الدائرة دون محاولة النقل الثاني، لذا المضيفون الميتون في مسح واسع يكلفون مهلة واحدة، لا اثنتين.

يبلغ عن جيل البروتوكول، ليس بنية دقيقة

VULNERABLE تعني "إصلاحات KB4893 غير موجودة"، ليس "هذه 9.2.1.33875". البنيات الأقدم من 9.2.1 تشارك نفس فحص الإصدار، لذا يجب أن تبلغ البروتوكول 6 وتُبلغ كقابلة للاستغلال أيضًا (مستنتج من الكود، ليس مقاسًا — انظر القيود)، لكن الأداة لا تستطيع فصل 9.2.1 عن 9.1 أو 8.1. أكد البنية الدقيقة في واجهة الكونسول إذا كنت بحاجة إليها.

المتطلبات

• Python 3.8+، المكتبة القياسية فقط — لا حزم طرف ثالث.

الاستخدام

# مضيف واحد (TCP/9999 الافتراضي)
./cve_2026_58073_check.py vspc.example.com

# منفذ صريح، عدة مضيفين
./cve_2026_58073_check.py vspc.example.com:9999 10.0.0.5

# مسح قائمة، هدف واحد لكل سطر (تعليقات '#' مسموحة)، إخراج مضغوط
./cve_2026_58073_check.py -f targets.txt --brief

# إخراج قابل للقراءة آليًا للأنابيب
./cve_2026_58073_check.py -f targets.txt --json > results.json

# بوابة Veeam Cloud Connect — نقل الترحيل يُكتشف تلقائيًا
./cve_2026_58073_check.py cc-gw.example.com:6180

# تثبيت النقل لتخطي الكشف (المنفذ يصبح 6180 افتراضيًا)
./cve_2026_58073_check.py --transport gateway cc-gw.example.com

# التحقق من ترميزات الأسلاك بدون وصول شبكة
./cve_2026_58073_check.py --self-test

الخيارات