cip-security-poc — إثبات مبدأ الإصلاح وراء CVE-2021-22681 (وليس مجرد ثغراته)

ستة نصوص برمجية قابلة للتشغيل — حركة مرور حقيقية لبروتوكول EtherNet/IP (الاختبار 1)، وآليات حقيقية لـ TLS/PKI (الاختبارات 3–6) — بدون أي برمجيات أو تراخيص من Rockwell في أي مكان في السلسلة. بُني لاختبار ادعاء قبل توثيقه، وليس للجدال فيه على أساس الإيمان.

المصدر: بُني في 2026-07-31، بالتوازي مع تحقيق موازٍ في محطة معالجة مياه الصرف الصحي في براهام، مينيسوتا — واحدة من أربع مرافق تم الكشف عنها علنًا في الحادث المنسق لقطاع المياه في مينيسوتا في 26–27 يوليو 2026. سياق ذلك الحادث موجود في نشرة CISA الاستشارية AA26-097A (مشتركة بين FBI/CISA/NSA/EPA/DOE/USCYBERCOM/وزارة الخزانة؛ صدرت في 2026-04-07، وتم توسيعها في 2026-07-22)، والتي تغطي حملة CyberAv3ngers المستمرة المرتبطة بـ IRGC. تحفظ بشأن الإسناد، مع الدقة الكاملة: لم تنسب أي جهة رسميًا حادث مينيسوتا تحديدًا إلى تلك المجموعة — فقط الحملة الأوسع المستمرة هي المنسوبة. هذا المجلد هو جانب الإصلاح التقني، ويُحفظ منفصلاً عن تحقيق الحادث عن قصد.

حالة البائع (مُحدّث في 2026-08-03)

تم التواصل مع Rockwell PSIRT ([email protected]) و RA Secure Mail ([email protected]) في 2026-07-31، قبل نشر هذا المستودع والكتابة (~30 دقيقة قبل ذلك، حسب الطوابع الزمنية للملفات). راجع فريق هندسة الأمان في Rockwell المستودع ورد في 2026-08-03. مقتبس مباشرة، وليس مُعاد صياغته في ادعاء أقوى مما ذكروه:

لا تؤيد Rockwell Automation تفسيرك، أو تعيينك لمعيار IEC 62443-4-2، أو أي استنتاجات مستخلصة من إثبات المفهوم. يرجى عدم تقديم العمل على أنه مُراجع، أو معتمد، أو مُصرح به من قبل Rockwell Automation... النصوص البرمجية توضح مبادئ التشفير والمصادقة العامة بدلاً من أي شيء خاص بـ CIP Security أو بـ CVE-2021-22681.

لم تتم مراجعة هذا العمل أو الموافقة عليه أو التصريح به من قبل Rockwell Automation، نقطة انتهى الكلام. توصيفهم الفني — مبادئ عامة، وليست خاصة بـ CIP Security — هو نفس التمييز الذي يرسمه جدول "الحد الصارم" أدناه بالفعل حول ادعاءات هذا المستودع نفسه؛ مراجعتهم تؤكده بشكل مستقل بدلاً من الطعن فيه. بالنسبة للمرافق التي تعمل على أجهزة لا تصل إلى CIP Security، أشارت Rockwell إلى دليلهم الخاص Converged Plantwide Ethernet (CPwE) Design and Implementation Guide (المُشار إليه في PHASED_ROLLOUT.md المرحلة 1) — المورد الحالي من البائع الذي يحاول هذا المشروع توجيه الناس إليه بدلاً من تكراره.

هذا الشكل ليس خاصًا بـ Rockwell

نتيجة الاختبار 1 — عدم وجود مصادقة في الحالة الافتراضية للبروتوكول — ليست فريدة لـ EtherNet/IP. Modbus TCP، الذي لا يزال أحد أكثر البروتوكولات انتشارًا في أنظمة التحكم في المياه/مياه الصرف الصحي، ليس لديه مفهوم مصادقة في مواصفات البروتوكول على الإطلاق؛ يعود تاريخه إلى اتصالات تسلسلية عام 1979 ولم يُصمم أبدًا مع وضع الأمان في الاعتبار. سمّت CISA مرارًا هذا الفشل بالضبط عبر النشرات الاستشارية ICS (مثل سلسلة Mitsubishi Electric MELSEC iQ-F: "MODBUS/TCP يفتقر إلى المصادقة المناسبة"، مما يسمح بالقراءة/الكتابة/الإيقاف غير المصرح به). إجابة منظمة Modbus نفسها، Modbus/TCP Security، هي تغليف TLS مع شهادات X.509 — هيكليًا نفس فئة الإصلاح التي يوضحها الاختبار 3 هنا، موحّدة على مستوى منظمة البروتوكول بدلاً من بائع واحد. DNP3 لديه امتداد مصادقة آمن اختياري (SAv5، تم توحيده في 2012)؛ تصف التحليلات المستقلة وحسابات المنفذين كلاهما بأنه نادرًا ما يتم تكوينه عمليًا، مع الاستشهاد بفجوات التشغيل البيني بين مصنعي OT والتعقيد الحقيقي للبروتوكول — مما يترك نفس التعرض الذي يوضحه الاختبار 1 لـ EtherNet/IP.

النقطة المعمارية، مُذكورة بدقة حتى لا يتم المبالغة في بيعها: إصلاح الاختبار 3 — TLS متبادل، هوية لكل جهاز مرتبطة في الشهادة (وليس مجرد صلاحية CA)، والإبطال عبر CRL — يعمل على طبقة النقل، وليس بروتوكول تطبيق ICS. المبدأ قابل للتطبيق بالتساوي تحت Modbus أو DNP3 أو بروتوكول خاص؛ ما يتغير هو الغلاف، وليس شكل الإصلاح. لم يقم هذا المستودع ببناء أو تشغيل PoC خاص بـ Modbus أو DNP3 — هذا تعميم معماري من الوثائق العامة، مُخضع لنفس التصنيف "مُثبت مقابل مُوثق" مثل كل شيء آخر هنا، وليس ادعاءً جديدًا مُختبرًا.

المصادر: نشرات CISA الاستشارية ICS حول فجوات مصادقة Modbus/TCP — Industrial Cyber · نظرة عامة على أمان Modbus/TCP — Veridify · تحديات تبني DNP3 SAv5/SAv6 — Step Function I/O

ثلاثة إخفاقات مختلفة — أبقها متميزة

حزمة الإفصاح تنجو أو تموت على عدم خلط هذه معًا، لأن لكل منها إصلاحًا مختلفًا:

• لا مصادقة / مصادقة غائبة (الاختبار 1) — جهاز مكشوف بدون أي طبقة بيانات اعتماد على الإطلاق. الخط الأساسي الواسع الذي اعتمدت عليه حملة CyberAv3ngers (العديد من الضحايا كانوا قابلين للوصول ببيانات اعتماد غائبة أو افتراضية).
• مفتاح واحد مضمّن / مشترك عبر أسطول (الشكل المحدد لـ CVE-2021-22681، المُنمذج بواسطة الاختبار 2) — استخرج المفتاح الواحد مرة واحدة، وزيّف على مستوى الأسطول. هذا هو CVE الفعلي.
• بيانات اعتماد افتراضية — بيانات اعتماد المصنع لم تتغير أبدًا. غير مُنمذجة هنا؛ مُذكورة حتى لا يتم الخلط بينها وبين الاثنين أعلاه.

الإصلاح المُثبت هنا — ربط الهوية لكل جهاز (الاختبار 3) — يعالج فشل مفتاح الأسطول.

الحد الصارم (اقرأ هذا أولاً)

	الادعاء	التصنيف	لماذا
المبدأ المعماري	"سر مشترك واحد عبر أسطول يتم اختراقه على مستوى الأسطول بتسريب واحد؛ المصادقة المرتبطة بالهوية لكل جهاز تسد ذلك"	مُثبت	مُثبت بكود حقيقي يعمل بما في ذلك التحكم السلبي الذي يثبت أن الفحص ضروري، وليس فقط أنه يعمل: على نقطة نهاية صارمة، شهادة الجهاز B الصالحة فعلاً من CA يتم رفضها على أساس الهوية (الاختبار 3 · الحالة 3)، ولكن على نقطة نهاية فقط لصلاحية CA، نفس الشهادة يتم قبولها (الحالة 4 — التحكم) → "التوقيع الصالح من CA وحده == وصول على مستوى الأسطول == الاختبار 2 في ثياب TLS." الربط يصمد أيضًا في الاتجاه العكسي: خادم مارق يقدم شهادة أسطول صالحة يتم رفضه من قبل العميل (الحالة 5). يُظهر الاختبار 1 بشكل منفصل خط الأساس الأوسع بدون مصادقة.
تنفيذ Rockwell المحدد لـ CIP Security يتصرف بشكل مماثل	"تمكين CIP Security على أجهزة Rockwell الحقيقية يعالج CVE-2021-22681 بهذه الطريقة بالضبط"	افتراض رائد، مُوثق وليس مُتحققًا	هذه لغة نشرة Rockwell الاستشارية نفسها (PN1550) — "عند نشره بشكل صحيح، يعالج CIP Security هذه الثغرة... ولا يستخدم أي مفاتيح مضمّنة" — وليس شيئًا أكدناه بشكل مستقل ضد أجهزة Logix حقيقية. اختبرنا المبدأ الذي تصفه نشرتهم الاستشارية، وليس تنفيذهم الدقيق على مستوى الأسلاك.

لا تخلط بين الصفين. المبدأ مُثبت. التنفيذ المحدد للبائع له موثوق (إنها نية التصميم المعلنة من قبلهم) لكنه غير مُختبر من قبلنا ضد معدات حقيقية.

الأدوات

test1_baseline_vulnerable.py — خط الأساس بدون مصادقة، مباشر

يشغّل محاكي PLC حقيقي لـ EtherNet/IP (cpppo، يحاكي Allen-Bradley ControlLogix) و يقرأ ويكتب علامة تحكم مع صفر بيانات اعتماد. (النطاق: هذا هو خط الأساس الواسع بدون مصادقة الذي اعتمدت عليه الحملة — وليس آلية المفتاح المضمّن المحددة لـ CVE-2021-22681. يُحفظ متميزًا عن قصد؛ انظر "ثلاثة إخفاقات مختلفة" أعلاه.)

python test1_baseline_vulnerable.py

test2_shared_secret_fails.py — شكل خلل مفتاح الأسطول (جسر سردي، وليس اختبارًا)

نقطتا نهاية تحملان مفتاحًا ثابتًا واحدًا؛ بيانات اعتماد من الجهاز A تفتح الجهاز B دون تغيير — أقرب تماثل هيكلي لخلل المفتاح الواحد للجميع في CVE-2021-22681. لكنه حشو منطقي: كلا المعالجين مُصممان لقبول ذلك المفتاح، لذلك لا يوجد مسار تنفيذ يمكن أن يفشل فيه. إنه لا يثبت شيئًا لا يعرّفه الكود إلى الوجود. يُحفظ كـ جسر سردي من الاختبار 1 إلى الاختبار 3؛ لا يحمل أي وزن إثباتي وهو عمدًا ليس ساق إثبات.

python test2_shared_secret_fails.py