pcrosby-1990/cip-security-pocCVE-2021-22681 की हार्डकोडेड-कुंजी दोष को दोहराने और अनुकरित EtherNet/IP पर प्रति-डिवाइस पारस्परिक TLS/CRL सुधार को मान्य करने वाला प्रूफ-ऑफ-कॉन्सेप्ट, IEC 62443-4-2 मैपिंग के साथ।
छह चलाने योग्य स्क्रिप्ट — वास्तविक EtherNet/IP प्रोटोकॉल ट्रैफ़िक (टेस्ट 1), वास्तविक TLS/PKI तंत्र (टेस्ट 3–6) — श्रृंखला में कहीं भी कोई Rockwell सॉफ़्टवेयर या लाइसेंसिंग नहीं। एक दावे का परीक्षण करने के लिए बनाया गया है लिखने से पहले, न कि उसे विश्वास पर बहस करने के लिए।
उत्पत्ति: 2026-07-31 को निर्मित, Braham, MN के एक समानांतर जाँच के साथ WWTF — जुलाई 26–27, 2026 के समन्वित मिनेसोटा जल-क्षेत्र में सार्वजनिक रूप से खुलासा किए गए चार उपयोगिताओं में से एक घटना। उस घटना का संदर्भ CISA सलाहकार AA26-097A में है (संयुक्त FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury; 2026-04-07 को जारी, 2026-07-22 को विस्तारित), जो चल रहे IRGC-संबद्ध CyberAv3ngers अभियान को कवर करता है। श्रेय सावधानी, सटीक रूप से रखी गई: किसी भी एजेंसी ने मिनेसोटा घटना को विशेष रूप से उस समूह के लिए औपचारिक रूप से जिम्मेदार नहीं ठहराया है — केवल व्यापक चल रहे अभियान को। यह फ़ोल्डर तकनीकी-सुधार पक्ष है, जानबूझकर घटना जाँच से अलग रखा गया है।
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) डिज़ाइन और कार्यान्वयन गाइड की ओर इशारा किया
(PHASED_ROLLOUT.md चरण 1 में उद्धृत) — मौजूदा विक्रेता संसाधन जिसकी ओर यह परियोजना लोगों को
ले जाने की कोशिश करती है, न कि उसकी नकल करने की।
टेस्ट 1 का निष्कर्ष — प्रोटोकॉल की डिफ़ॉल्ट स्थिति में कोई प्रमाणीकरण नहीं — केवल EtherNet/IP के लिए अद्वितीय नहीं है। Modbus TCP, जो अभी भी जल/अपशिष्ट जल नियंत्रण प्रणालियों में सबसे व्यापक रूप से तैनात प्रोटोकॉल में से एक है, प्रोटोकॉल विनिर्देश में कोई प्रमाणीकरण अवधारणा नहीं है; यह 1979 की सीरियल संचार से तारीख रखता है और इसे कभी भी सुरक्षा को ध्यान में रखकर डिज़ाइन नहीं किया गया था। CISA ने बार-बार ICS सलाहकारों में ठीक इसी विफलता का नाम लिया है (जैसे मित्सुबिशी इलेक्ट्रिक की MELSEC iQ-F श्रृंखला: "MODBUS/TCP में उचित प्रमाणीकरण का अभाव है," जो अनधिकृत पढ़ने/लिखने/रोकने की अनुमति देता है)। Modbus संगठन का अपना उत्तर, Modbus/TCP सुरक्षा, X.509 प्रमाणपत्रों के साथ TLS एनकैप्सुलेशन है — संरचनात्मक रूप से वही सुधार श्रेणी जो टेस्ट 3 यहाँ प्रदर्शित करता है, एक विक्रेता के बजाय प्रोटोकॉल-संगठन स्तर पर मानकीकृत। DNP3 में एक वैकल्पिक सुरक्षित प्रमाणीकरण एक्सटेंशन है (SAv5, 2012 में मानकीकृत); स्वतंत्र विश्लेषण और कार्यान्वयनकर्ता खाते दोनों इसे व्यवहार में शायद ही कभी कॉन्फ़िगर किए जाने के रूप में वर्णित करते हैं, OT निर्माताओं के बीच अंतर-संचालन अंतराल और वास्तविक प्रोटोकॉल जटिलता का हवाला देते हुए — वही एक्सपोज़र छोड़ते हुए जो टेस्ट 1 EtherNet/IP के लिए प्रदर्शित करता है।
वास्तुशिल्प बिंदु, सटीक रूप से कहा गया ताकि इसे बेचा न जाए: टेस्ट 3 का सुधार — पारस्परिक TLS, प्रमाणपत्र में बंधी प्रति-डिवाइस पहचान (सिर्फ़ CA वैधता नहीं), CRL के माध्यम से निरसन — पर काम करता है परिवहन परत, ICS अनुप्रयोग प्रोटोकॉल पर नहीं। सिद्धांत समान रूप से लागू है Modbus, DNP3, या एक मालिकाना प्रोटोकॉल के नीचे; जो बदलता है वह रैपर है, सुधार का आकार नहीं। इस रिपो ने Modbus- या DNP3-विशिष्ट PoC नहीं बनाया या चलाया है — यह सार्वजनिक दस्तावेज़ीकरण से एक वास्तुशिल्प सामान्यीकरण है, जिसे यहाँ बाकी सब कुछ के समान "प्रदर्शित बनाम स्रोत" टियरिंग पर रखा गया है, न कि एक नया परीक्षण किया गया दावा।
स्रोत: Modbus/TCP प्रमाणीकरण अंतराल पर CISA ICS सलाहकार — Industrial Cyber · Modbus/TCP सुरक्षा अवलोकन — Veridify · DNP3 SAv5/SAv6 अपनाने की चुनौतियाँ — Step Function I/O
एक प्रकटीकरण पैकेट इन्हें एक साथ न मिलाने पर जीवित या मर जाता है, क्योंकि प्रत्येक का एक अलग सुधार है:
यहाँ प्रदर्शित सुधार — प्रति-डिवाइस पहचान बंधन (टेस्ट 3) — बेड़े-कुंजी विफलता को संबोधित करता है।
| दावा | टियर | क्यों | |
|---|---|---|---|
| वास्तुशिल्प सिद्धांत | "एक बेड़े में एक एकल साझा रहस्य एक रिसाव से बेड़े-व्यापक रूप से समझौता हो जाता है; प्रति-डिवाइस पहचान-बद्ध प्रमाणीकरण इसे बंद करता है" | सिद्ध | वास्तविक चल रहे कोड के साथ प्रदर्शित नकारात्मक नियंत्रण सहित जो साबित करता है कि जाँच आवश्यक है, न कि केवल यह कि यह चालू होती है: एक सख्त एंडपॉइंट डिवाइस B पर वास्तविक CA-मान्य प्रमाणपत्र पहचान पर अस्वीकार किया जाता है (टेस्ट 3 · मामला 3), लेकिन CA-वैधता-केवल एंडपॉइंट पर समान प्रमाणपत्र स्वीकार किया जाता है (मामला 4 — नियंत्रण) → "अकेले वैध रूप से CA-हस्ताक्षरित == बेड़े-व्यापक पहुँच == TLS कपड़ों में टेस्ट 2।" बंधन विपरीत में भी रहता है: एक दुष्ट सर्वर जो एक वैध बेड़े प्रमाणपत्र प्रस्तुत करता है, क्लाइंट द्वारा अस्वीकार कर दिया जाता है (मामला 5)। टेस्ट 1 अलग से व्यापक नो-ऑथ बेसलाइन दिखाता है। |
| Rockwell का विशिष्ट CIP सुरक्षा कार्यान्वयन समान व्यवहार करता है | "वास्तविक Rockwell हार्डवेयर पर CIP सुरक्षा सक्षम करना CVE-2021-22681 को ठीक इसी तरह ठीक करता है" | LEAD, स्रोतित न कि सत्यापित | यह Rockwell का अपना सलाहकार (PN1550) भाषा है — "जब ठीक से तैनात किया जाता है, CIP सुरक्षा इस भेद्यता को ठीक करती है... किसी भी हार्डकोडेड कुंजी का उपयोग नहीं करती है" — ऐसा कुछ नहीं जिसे हमने वास्तविक Logix हार्डवेयर के खिलाफ स्वतंत्र रूप से पुष्टि की है। हमने उस सिद्धांत का परीक्षण किया जो उनका सलाहकार वर्णन करता है, न कि उनके सटीक वायर-स्तरीय कार्यान्वयन का। |
दो पंक्तियों को भ्रमित न करें। सिद्धांत सिद्ध है। विक्रेता का इसका विशिष्ट कार्यान्वयन विश्वसनीय है (यह उनका अपना कहा गया डिज़ाइन इरादा है) लेकिन वास्तविक उपकरणों के खिलाफ हमारे द्वारा परीक्षण नहीं किया गया है।
test1_baseline_vulnerable.py — नो-ऑथ बेसलाइन, लाइवएक वास्तविक EtherNet/IP PLC सिम्युलेटर (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
test3_mutual_tls_fix.py — सुधार, इसके नकारात्मक नियंत्रण और दोनों दिशाओं के साथवास्तविक CA, दो व्यक्तिगत रूप से अद्वितीय डिवाइस प्रमाणपत्र — पहचान SubjectAlternativeName में बंधी है, न कि अप्रचलित CommonName में। पाँच मामले, सभी निष्पादित:
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
test5_rotation.py — जीवनचक्र पैर जो टेस्ट 4 ने बंद नहीं किया: रोटेशनसमान पहचान (engineer-1) के लिए एक प्रतिस्थापन क्रेडेंशियल (v2) जारी करता है जो पहले से एक
मान्य (v1) रखता है। नियंत्रण (मामला 3): v1 को v2 के अस्तित्व में आने के बाद लेकिन v1 के स्पष्ट रूप से सेवानिवृत्त होने से पहले फिर से प्रस्तुत किया जाता है → अभी भी GRANTED — यह साबित करता है कि अकेले पुनः-जारी करना पुराने क्रेडेंशियल को सेवानिवृत्त नहीं करता। केवल v1 को स्पष्ट रूप से CRL में जोड़े जाने के बाद (मामला 4) इसे अस्वीकार कर दिया जाता है; v2 पूरे समय अप्रभावित रहता है (मामला 5) — संक्रमण के दौरान पहचान कभी पहुँच नहीं खोती। CR 1.8 का "प्रतिस्थापन जारी करें और पिछले को सेवानिवृत्त करें" दो क्रियाएँ हैं, और यह दोनों को अलग-अलग दिखाता है।
python test5_rotation.py
test6_tamper_injection.py — वह पैर जिसे CR 3.1 ने केवल "निर्माण द्वारा" नाम दिया: एक समर्पित अखंडता परीक्षणएक रिकॉर्ड-स्तरीय रिले एक वास्तविक पारस्परिक-TLS क्लाइंट और सर्वर के बीच बैठता है, केवल 5-बाइट हेडर को पार्स करके TLS रिकॉर्ड अग्रेषित करता है — यह एन्क्रिप्टेड पेलोड का प्लेनटेक्स्ट कभी नहीं देखता। नियंत्रण: हर बाइट अपरिवर्तित अग्रेषित → संदेश बरकरार वितरित। छेड़छाड़: एक लाइव एप्लिकेशन डेटा रिकॉर्ड के सिफरटेक्स्ट के अंदर एक बिट फ़्लिप → प्राप्त करने वाले TLS स्टैक की AEAD जाँच विफल हो जाती है (SSLV3_ALERT_BAD_RECORD_MAC) और कनेक्शन तोड़ दिया जाता है — दूषित डेटा कभी भी वैध के रूप में वितरित नहीं किया जाता।
कौन सा बाइट, और यह क्यों निर्दिष्ट है: एक TLS 1.2 AEAD रिकॉर्ड बॉडी है
explicit_nonce(8) ‖ ciphertext ‖ auth_tag(16), इसलिए बाइट 0 नॉन्स है, पेलोड नहीं। नॉन्स को फ़्लिप करना
भी AEAD जाँच को ट्रिप करता है — लेकिन बदले हुए पेलोड को पकड़ने वाले टैग के बजाय डिक्रिप्शन को गड़बड़ करके। CR 3.1 अनधिकृत प्रेषित जानकारी के संशोधन के बारे में है, इसलिए फ़्लिप सिफरटेक्स्ट के बीच में एक बाइट को लक्षित करता है, और परीक्षण फिर ठीक उसी वाक्य को प्रदर्शित करता है जो यह दावा करता है।
python test6_tamper_injection.py
maximum_version = TLSv1_2 को पिन करती है दो कारणों से जो अवलोकनीयता के बारे में हैं, सुरक्षा नहीं: TLS 1.2 के तहत एक अनुपस्थित या अस्वीकृत क्लाइंट प्रमाणपत्र हैंडशेक के दौरान विफल हो जाता है, इसलिए परीक्षण को TLS 1.3 की पोस्ट-हैंडशेक विफलता के बजाय एक निर्धारणीय, जिम्मेदार त्रुटि मिलती है; और रिकॉर्ड सामग्री प्रकार स्पष्ट रूप से दिखाई देता रहता है, जिसकी टेस्ट 6 के रिले को एप्लिकेशन डेटा रिकॉर्ड की पहचान करने के लिए आवश्यकता होती है। अपने डिवाइस द्वारा समर्थित उच्चतम TLS संस्करण तैनात करें — जहाँ उपलब्ध हो TLS 1.3। इस रिपो में कुछ भी उत्पादन प्रणाली को 1.2 पर सीमित करने की सलाह के रूप में नहीं पढ़ा जाना चाहिए।presented == KEY, identity in SAN) स्थिर-समय नहीं हैं। यहाँ शोषण योग्य नहीं — तुलना किए गए मान सार्वजनिक-जैसी पहचान स्ट्रिंग हैं और तुलना चलने से पहले TLS पहले ही वास्तविक क्रिप्टोग्राफ़िक प्रमाणीकरण कर चुका है — लेकिन ध्वजांकित किया गया है क्योंकि पैटर्न उन स्थानों पर कॉपी हो जाता है जहाँ यह वास्तव में मायने रखता है।python -m venv venv
venv\Scripts\activate # या: source venv/bin/activate
pip install -r requirements.txt
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]) से पहले:
IEC 62443-4-2:2019 की खरीदी गई प्रति के खिलाफ प्रत्येक CR के मानक पाठ को सत्यापित करें।PHASED_ROLLOUT.md (चरण 0 रक्तस्राव रोकें · 1 खंड · 2
क्षतिपूर्ति नियंत्रण · 3 CIP सुरक्षा/PKI, हार्डवेयर-अनुमति · 4 संचालन)। एक छोटी उपयोगिता के लिए सही आकार;
ईमानदार कि CIP सुरक्षा हार्डवेयर-गेटेड है, इसलिए चरण 0–2 जोखिम कमी को वैसे भी वहन करते हैं।PHASE0_INVENTORY_WORKSHEET.md (एक भरने योग्य डिवाइस इन्वेंट्री, न केवल एक बनाने का निर्देश), RESOURCES.md (मुफ्त CISA / EPA / WaterISAC / AWWA सहायता, लाइव सत्यापित, याद नहीं किया गया), और INCIDENT_RESPONSE_QUICK_REFERENCE.md (एक पहले-60-मिनट कार्ड, स्पष्ट रूप से एक पूर्ण IR योजना नहीं — इसमें संचालन की सुरक्षा हमेशा पहले आती है)।test5_rotation.py CR 1.8 को "सक्षम" से पूरी तरह प्रदर्शित में ले जाता है (रोटेशन, अपने स्वयं के नियंत्रण के साथ); test6_tamper_injection.py CR 3.1 को "निर्माण