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

أربعة نصوص برمجية قابلة للتشغيل. حركة مرور حقيقية لبروتوكول EtherNet/IP، وتشفير حقيقي، وبدون أي برمجيات Rockwell أو تراخيص في أي مكان في السلسلة. صُممت لاختبار ادعاء قبل توثيقه، لا للترويج له على أساس الإيمان المسبق.

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

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

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

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

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

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

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

الأدوات

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

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

python test1_baseline_vulnerable.py

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

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

python test2_shared_secret_fails.py

test3_mutual_tls_fix.py — الإصلاح، مع تحكمه السلبي واتجاهيه

CA حقيقي، وشهادتا جهاز فريدتان كل منهما على حدة — الهوية مربوطة في SubjectAlternativeName، وليس في CommonName المهجور. خمس حالات، نُفذت جميعها:

• [1] شهادة الجهاز A الخاصة → ممنوحة (GRANTED) · [2] بدون شهادة → مرفوضة عند مصافحة TLS · [3] شهادة الجهاز B الصالحة من CA → مرفوضة (DENIED) على أساس الهوية (نقطة نهاية صارمة).
• [4] التحكم (THE CONTROL) — نفس شهادة الجهاز B ضد نقطة نهاية تتحقق من صلاحية CA فقط → ممنوحة (GRANTED). هذا ما يعطي [3] معناه: بدون فحص الهوية، أي شهادة أسطول تفتح أي جهاز (== Test 2، بثوب TLS).
• [5] الاتجاه العكسي (REVERSE) — خادم مارق يقدّم شهادة الجهاز B يُرفض من عميل يربط device-a (check_hostname مقابل SAN حقيقي). متبادل — كلا الطرفين يربط الهوية.

python test3_mutual_tls_fix.py

test4_revocation.py — جزء دورة الحياة: الإبطال

قائمة إبطال شهادات (CRL) حقيقية موقّعة من CA. يُمنح اعتماد عميل (engineer-1)؛ ثم يُضاف رقمه التسلسلي إلى CRL، ويُرفض نفس الاعتماد الذي ما زال صالحًا وغير منتهي الصلاحية وموقّعًا من CA — المحتوى التجريبي لبند الإبطال في CR 1.8 / 1.9. التفرد (Test 3) ≠ قابلية الإبطال؛ وهذا يُظهر أن الاعتماد يمكن استرداده.

python test4_revocation.py

حدود النطاق (ما لا يُدَّعى)

• الإبطال — أصبح مُثبتًا الآن (test4_revocation.py)؛ التدوير — ليس بعد. تفرد كل جهاز (Test 3) ليس هو قابلية الإبطال؛ Test 4 يسد تلك الفجوة — اعتماد ما زال صالحًا وغير منتهي الصلاحية وموقّعًا من CA يُمنح قبل الإبطال ويُرفض بعده، فقط لأن CRL الموقّع من CA يُدرج الآن رقمه التسلسلي. التدوير (إعادة إصدار اعتماد بديل وتقاعد القديم) وثيق الصلة ومُمكَّن بنفس البنية التحتية للمفاتيح العامة (PKI)، لكنه غير مُثبت بشكل منفصل هنا — لذا "ربط الهوية لكل جهاز" يجب ألا يتوسع بصمت إلى "التدوير محلول".
• الوقت الثابت (Constant-time) (شدة منخفضة، ذُكر لأسباب تتعلق بالنظافة). مقارنات سلاسل الهوية (presented == KEY, identity in SAN) ليست ثابتة الوقت. غير قابلة للاستغلال هنا — القيم المُقارنة هي سلاسل هوية شبه عامة، وقد أنجز TLS بالفعل المصادقة التشفيرية الحقيقية قبل تنفيذ المقارنة — لكنها مُشار إليها لأن هذا النمط يُنسخ إلى أماكن يكون فيها الأمر مهمًا.

الإعداد

python -m venv venv
venv\Scripts\activate        # or: source venv/bin/activate
pip install -r requirements.txt

الخطوات التالية (بقي عنصر حقيقي واحد، بالإضافة إلى عنصرين صغيرين اختياريين)

• تخطيط 62443-4-2 SL 2 — مُسوَّد (DRAFTED) → 62443-4-2_SL2_MAPPING.md (CR 1.2 / 1.8 / 1.9 / 1.14 / 3.1، مرتّبة بصدق حسب المستويات، وكل فجوة مُسماة؛ أصبحت CR 1.2 وCR 1.9 وساق الإصدار/التحقق/الإبطال في CR 1.8 مُثبتة الآن). قبل التواصل مع PSIRT ([email protected] / [email protected]): تحقق من النص المعياري لكل CR مقابل نسخة مشتراة من IEC 62443-4-2:2019.
• طرح مرحلي — مُسوَّد (DRAFTED) → PHASED_ROLLOUT.md (المرحلة 0 إيقاف النزيف · 1 تقسيم الشبكة · 2 ضوابط تعويضية · 3 CIP Security/PKI، إذا سمحت العتاد · 4 التشغيل). بحجم مناسب لمرفق صغير؛ وصادق في أن CIP Security مقيدة بالعتاد (hardware-gated)، لذا فالمراحل 0–2 تتحمل تقليل المخاطر في كل الأحوال.
• ما زال مفتوحًا — العنصر المتبقي الفعلي: تسلسل الإفصاح المسؤول. الاتصال بـ PSIRT أولاً، ثم الكتابة العامة / LinkedIn بعد ذلك، بحيث تُوثَّق سلسلة الأصل (provenance) بالترتيب. غير مُسوَّد بعد: رسالة PSIRT نفسها.
• عنصران تقنيان صغيران، مُسميان صراحةً وليسا مُهرَّبين (وفقًا لملخص وثيقة التخطيط نفسها): اختبار تدوير (إعادة إصدار + تقاعد) لنقل CR 1.8 من "مُمكَّن" إلى مُثبت بالكامل، واختبار حقن عبث (tamper-injection) لنقل CR 3.1 من "مضمون بالبناء" إلى مُثبت. ليس أيٌّ منهما أساسيًا للادعاء المركزي؛ وكلاهما صغير إذا ما نُفذ.

الاستشهادات — مسترجعة لا مستذكرة (وأعد السحب قبل التقديم)

كل معرّف خارجي هنا سُحب من مصدر مباشر في 2026-07-31، وليس مسترجعًا من بيانات التدريب: AA26-097A (متعدد المصادر، بما في ذلك WaterISAC / Tenable / SecurityWeek)، براهام كواحدة من الضحايا الأربع المُعلَن عنها، CyberAv3ngers/IRGC، وPN1550 يؤكد نشرة Rockwell الاستشارية الحقيقية مع اقتباس الصف 2 المُتحقق منه حرفيًا ("When properly deployed, CIP Security remediates this vulnerability" + "does not make use of any hardcoded keys")، و"cannot be mitigated with a patch" حرفيًا، وCVSS 10.0 / CRITICAL (v3.1)، وتتبع CISA ICSA-21-056-03، و62443-4-2 CR 1.8 (PKI) + CR 3.1 (سلامة الاتصالات) مؤكدة بدقة. انضباط الحزمة: أعد سحب كل معرّف من المصادر الأولية في وقت التقديم. النشرات الاستشارية يُعاد ترقيمها وتوسيعها واستبدالها — AA26-097A يُظهر بالفعل توسيعًا واحدًا — لذا "تم التحقق في 2026-07-31" ليس "تم التحقق عند التقديم". التخطيط الرسمي الكامل لـ 62443-4-2 متطلبًا بمتطلب أصبح مكتوبًا الآن (62443-4-2_SL2_MAPPING.md) — ما تبقى هو إعادة سحب نصه المعياري المُستشهد به مقابل نسخة معيارية مشتراة قبل التقديم، وليس كتابة التخطيط نفسه.

l0gic — Patrick Crosby · 2026-07-31.

سجل التقوية (Hardening log): عُزز Test 3 ليشمل التحكم السلبي (الحالة 4، التي تُثبت الضرورة لا مجرد الاشتغال)، وحالة الاتجاه العكسي (الحالة 5، الربط المتبادل)، والهوية القائمة على SAN (وليس CN)، ثم أُعيد التحقق منه بإعادة تشغيل الحالات الخمس جميعها؛ وأُضيف Test 4 (إبطال CRL). ضُبطت تسميات Test 1/2 إلى الحجم المناسب لتبقى فئات الإخفاق الثلاث متميزة؛ وخُفّض Test 2 من "اختبار" إلى جسر سردي؛ وأُضيفت حدود نطاق الإبطال والوقت الثابت. استُرجعت سلسلة الاستشهادات من المصادر الأولية وخُتمت لإعادة السحب عند التقديم.