cip-security-poc — CVE-2021-22681 के पीछे के फिक्स सिद्धांत को प्रमाणित करना (केवल इसकी कमज़ोरी नहीं)

चार रन करने योग्य स्क्रिप्ट। वास्तविक EtherNet/IP प्रोटोकॉल ट्रैफ़िक, वास्तविक क्रिप्टोग्राफी, श्रृंखला में कहीं भी शून्य Rockwell सॉफ़्टवेयर या लाइसेंसिंग। किसी दावे का परीक्षण करने के लिए लिखने से पहले बनाया गया, न कि केवल विश्वास के आधार पर उसके पक्ष में तर्क देने के लिए।

उत्पत्ति: 2026-07-31 को निर्मित, Braham, MN WWTF की समानांतर जांच के साथ — 26–27 जुलाई, 2026 की समन्वित Minnesota जल-क्षेत्र घटना में सार्वजनिक रूप से खुलासा किए गए चार उपयोगिताओं में से एक। उस घटना का संदर्भ CISA सलाहकार AA26-097A में है (संयुक्त FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury; 2026-04-07 को जारी, 2026-07-22 को विस्तारित), जो चल रहे IRGC-संबद्ध CyberAv3ngers अभियान को कवर करता है। आरोपण चेतावनी, सटीक रूप से धारित: किसी भी एजेंसी ने विशेष रूप से Minnesota घटना का औपचारिक रूप से उस समूह पर आरोप नहीं लगाया है — केवल व्यापक चल रहे अभियान का। यह फ़ोल्डर तकनीकी-फिक्स पक्ष है, जानबूझकर घटना जांच से अलग रखा गया है।

तीन अलग-अलग विफलताएँ — इन्हें अलग रखें

एक प्रकटीकरण पैकेट इन्हें आपस में मिलाने न करने पर टिकता या गिरता है, क्योंकि प्रत्येक का फिक्स अलग है:

• कोई प्रमाणीकरण नहीं / अनुपस्थित प्रमाणीकरण (टेस्ट 1) — एक डिवाइस जिसमें कोई क्रेडेंशियल परत ही नहीं है। वह व्यापक आधार-रेखा जिस पर CyberAv3ngers अभियान ने भरोसा किया (कई पीड़ित अनुपस्थित या डिफ़ॉल्ट क्रेडेंशियल से पहुंच योग्य थे)।
• एक हार्डकोडेड / साझा कुंजी पूरे fleet में (CVE-2021-22681 का विशिष्ट रूप, टेस्ट 2 द्वारा मॉडलित) — एक बार वह एक कुंजी निकालें, पूरे fleet में जालसाज़ी करें। यह वास्तविक CVE है।
• डिफ़ॉल्ट क्रेडेंशियल — फ़ैक्टरी क्रेडेंशियल कभी नहीं बदले गए। यहाँ मॉडलित नहीं; नाम दिया गया ताकि इसे उपरोक्त दो से न जोड़ा जाए।

यहाँ प्रदर्शित फिक्स — प्रति-डिवाइस पहचान बाइंडिंग (टेस्ट 3) — fleet-कुंजी विफलता को संबोधित करता है।

कठोर सीमा (इसे पहले पढ़ें)

दोनों पंक्तियों को आपस में न मिलाएँ। सिद्धांत सिद्ध है। विक्रेता का इसका विशिष्ट कार्यान्वयन विश्वसनीय है (यह उनका अपना कथित डिज़ाइन इरादा है) लेकिन वास्तविक उपकरणों के विरुद्ध हमारे द्वारा परीक्षित नहीं है।

उपकरण

test1_baseline_vulnerable.py — नो-ऑथ आधार-रेखा, लाइव

एक वास्तविक EtherNet/IP PLC सिम्युलेटर (cpppo, एक Allen-Bradley ControlLogix का अनुकरण करता हुआ) शुरू करता है और शून्य क्रेडेंशियल के साथ एक नियंत्रण टैग को पढ़ता और लिखता है। (दायरा: यह व्यापक नो-प्रमाणीकरण आधार-रेखा है जिस पर अभियान ने भरोसा किया — नहीं CVE-2021-22681 का विशिष्ट हार्डकोडेड-कुंजी तंत्र। जानबूझकर अलग रखा गया; ऊपर "तीन अलग-अलग विफलताएँ" देखें।)

python test1_baseline_vulnerable.py

test2_shared_secret_fails.py — fleet-कुंजी दोष का आकार (कथात्मक सेतु, परीक्षण नहीं)

दो एंडपॉइंट एक स्थिर कुंजी रखते हैं; डिवाइस A का क्रेडेंशियल डिवाइस B को अपरिवर्तित खोल देता है — CVE-2021-22681 की एक-कुंजी-सभी-के-लिए दोष का निकटतम संरचनात्मक एनालॉग। लेकिन यह पुनरुक्तिपूर्ण है: दोनों हैंडलर उस कुंजी को स्वीकार करने के लिए निर्मित हैं, इसलिए कोई निष्पादन पथ नहीं है जिसमें यह विफल हो सके। यह ऐसा कुछ भी प्रदर्शित नहीं करता जिसे कोड स्वयं अस्तित्व में परिभाषित न करता हो। टेस्ट 1 से टेस्ट 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] नियंत्रण — केवल-CA-वैधता एंडपॉइंट के विरुद्ध वही डिवाइस B प्रमाणपत्र → GRANTED। यही [3] को सार्थक बनाता है: पहचान जाँच के बिना, कोई भी fleet प्रमाणपत्र किसी भी डिवाइस को खोल देता है (== टेस्ट 2, TLS वेश में)।
• [5] उल्टा — एक दुष्ट सर्वर जो डिवाइस B का प्रमाणपत्र प्रस्तुत करता है, उसे एक क्लाइंट द्वारा अस्वीकृत किया जाता है जो device-a को बाँधता है (एक वास्तविक SAN के विरुद्ध check_hostname)। पारस्परिक — दोनों छोर पहचान बाँधते हैं।

python test3_mutual_tls_fix.py

test4_revocation.py — जीवनचक्र पैर: निरसन

एक वास्तविक CA-हस्ताक्षरित CRL। एक क्लाइंट क्रेडेंशियल (engineer-1) को प्रदान किया जाता है; फिर इसका सीरियल CRL में जोड़ा जाता है, और वही अभी भी वैध, असमाप्त, CA-हस्ताक्षरित क्रेडेंशियल अस्वीकृत हो जाता है — CR 1.8 / 1.9 निरसन खंड की अनुभवजन्य सामग्री। विशिष्टता (टेस्ट 3) ≠ निरसनीयता; यह दर्शाता है कि क्रेडेंशियल वापस लिया जा सकता है।

python test4_revocation.py

दायरा सीमाएँ (क्या दावा नहीं किया गया है)

• निरसन — अब प्रदर्शित (test4_revocation.py); रोटेशन — अभी नहीं। प्रति-डिवाइस विशिष्टता (टेस्ट 3) निरसनीयता के समान नहीं है; टेस्ट 4 उस अंतर को बंद करता है — एक अभी भी वैध, असमाप्त, CA-हस्ताक्षरित क्रेडेंशियल निरसन से पहले प्रदान किया जाता है और बाद में अस्वीकृत, केवल इसलिए क्योंकि CA-हस्ताक्षरित CRL अब उसका सीरियल सूचीबद्ध करता है। रोटेशन (एक प्रतिस्थापन क्रेडेंशियल पुनः जारी करना और पुराने को सेवानिवृत्त करना) निकट से संबंधित है और उसी PKI द्वारा सक्षम है, लेकिन यहाँ अलग से प्रदर्शित नहीं है — इसलिए "प्रति-डिवाइस पहचान बाइंडिंग" को अभी भी चुपचाप "रोटेशन हल हो गया" में विस्तारित नहीं होना चाहिए।
• कॉन्स्टेंट-टाइम (कम गंभीरता, स्वच्छता के लिए नामित)। पहचान स्ट्रिंग तुलनाएँ (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 मैपिंग — प्रारूपित → 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 की खरीदी गई प्रति के विरुद्ध सत्यापित करें।
• चरणबद्ध रोलआउट — प्रारूपित → PHASED_ROLLOUT.md (चरण 0 रक्तस्राव-रोक · 1 खंड · 2 प्रतिपूरक नियंत्रण · 3 CIP सुरक्षा/PKI, हार्डवेयर-अनुमति · 4 संचालन)। एक छोटी उपयोगिता के लिए सही आकार; ईमानदार कि CIP सुरक्षा हार्डवेयर-गेटेड है, इसलिए चरण 0–2 जोखिम कमी का भार वैसे भी वहन करते हैं।
• अभी भी खुला — वास्तविक शेष मद: जिम्मेदार-प्रकटीकरण अनुक्रमण। पहले PSIRT संपर्क, बाद में सार्वजनिक लेख / LinkedIn, ताकि उत्पत्ति-श्रृंखला क्रम में दस्तावेज़ित हो। अभी तक प्रारूपित नहीं: PSIRT ईमेल स्वयं।
• दो छोटे तकनीकी मद, नामित न कि छिपाए गए (मैपिंग दस्तावेज़ के अपने सारांश के अनुसार): एक रोटेशन परीक्षण (पुनः-जारी + सेवानिवृत्त) CR 1.8 को "सक्षम" से पूर्ण रूप से प्रदर्शित करने के लिए, और एक छेड़छाड़-इंजेक्शन परीक्षण CR 3.1 को "निर्माण द्वारा" से प्रदर्शित करने के लिए। न तो केंद्रीय दावे के लिए भार-वहन करने वाला है; यदि उठाए जाएँ तो दोनों छोटे हैं।

उद्धरण — पुनर्प्राप्त, स्मरण नहीं (और सबमिशन से पहले फिर से खींचें)

यहाँ का प्रत्येक बाहरी पहचानकर्ता 2026-07-31 को एक लाइव स्रोत से खींचा गया था, प्रशिक्षण से स्मरण नहीं: AA26-097A (बहु-स्रोत, सहित WaterISAC / Tenable / SecurityWeek), चार प्रकट पीड़ितों में से एक के रूप में Braham, CyberAv3ngers/IRGC, PN1550 ने वास्तविक Rockwell सलाहकार की पुष्टि की और इसकी Row-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 पर सत्यापित" "सबमिट के समय सत्यापित" नहीं है। पूर्ण औपचारिक CR-दर-CR 62443-4-2 मैपिंग अब लिखी जा चुकी है (62443-4-2_SL2_MAPPING.md) — जो शेष है वह सबमिशन से पहले उसके उद्धृत मानक पाठ को एक खरीदी गई मानक प्रति के विरुद्ध फिर से खींचना है, न कि मैपिंग स्वयं लिखना।

l0gic — Patrick Crosby · 2026-07-31.

सख्तीकरण लॉग: टेस्ट 3 को नकारात्मक नियंत्रण (केस 4, केवल चालू होने के बजाय आवश्यकता साबित करना), उल्टी-दिशा मामला (केस 5, पारस्परिक बाइंडिंग), और SAN-आधारित पहचान (CN नहीं) शामिल करने के लिए मजबूत किया गया, फिर सभी पाँच मामलों को फिर से चलाकर पुनः सत्यापित किया गया; टेस्ट 4 (CRL निरसन) जोड़ा गया। टेस्ट 1/2 कैप्शन को तीन विफलता वर्गों को अलग रखने के लिए सही आकार दिया गया; टेस्ट 2 को "परीक्षण" से कथात्मक सेतु में अवनत किया गया; निरसन और कॉन्स्टेंट-टाइम दायरा सीमाएँ जोड़ी गईं। उद्धरण श्रृंखला प्राथमिक स्रोतों से पुनर्प्राप्त की गई और सबमिशन पर फिर से खींचने के लिए स्टांप की गई।