cip-security-poc — CVE-2021-22681 이면의 수정 원칙 입증 (결함 자체만이 아닌)

실행 가능한 스크립트 4개. 실제 EtherNet/IP 프로토콜 트래픽, 실제 암호화, 체인 어디에도 Rockwell 소프트웨어나 라이선스가 전혀 없음. 주장을 문서로 정리하기 전에 검증하기 위해 만들어진 것이지, 맹목적으로 옹호하기 위한 것이 아님.

출처: 2026-07-31 제작, 미네소타주 브레이햄(Braham, MN) WWTF(폐수처리시설)에 대한 병행 조사와 함께 — 2026년 7월 26~27일 미네소타 물 부문 합동 공격 사건에서 공개적으로 알려진 4개 시설 중 하나. 해당 사고의 맥락은 CISA 권고 AA26-097A(FBI/CISA/NSA/EPA/DOE/USCYBERCOM/재무부 합동; 2026-04-07 발행, 2026-07-22 확장)에 있으며, 이는 진행 중인 IRGC 연계 CyberAv3ngers 캠페인을 다룹니다. 귀속 주의사항, 정확히 유지함: 어떤 기관도 특히 미네소타 사고를 해당 그룹으로 공식적으로 지목하지 않았습니다 — 오직 더 넓은 범위의 진행 중인 캠페인만이 그렇습니다. 이 폴더는 기술 수정 측면이며, 의도적으로 사고 조사와 분리되어 있습니다.

세 가지 서로 다른 실패 — 구별해서 유지하세요

공개 패킷의 성패는 이 셋을 한데 뭉개지 않느냐에 달려 있습니다. 각각 다른 수정 방법을 갖고 있기 때문입니다:

• 인증 없음 / 부재 (Test 1) — 자격 증명 계층이 전혀 없는 채로 노출된 장치. CyberAv3ngers 캠페인이 기댄 광범위한 기준선(많은 피해자가 인증 부재 또는 기본 자격 증명으로 접근 가능했음).
• 플릿 전반의 단일 하드코딩 / 공유 키 (CVE-2021-22681의 구체적 형태, Test 2로 모델링됨) — 키 하나를 한 번 추출하면 플릿 전체를 위조할 수 있음. 이것이 실제 CVE입니다.
• 기본 자격 증명 — 공장 출하 시 자격 증명을 변경하지 않은 경우. 여기서는 모델링하지 않음; 위 두 가지와 혼동되지 않도록 명명만 함.

여기서 입증하는 수정 — 장치별 신원 바인딩 (Test 3) — 플릿 키 실패를 해결합니다.

엄격한 경계 (먼저 읽어주세요)

두 행을 혼동하지 마십시오. 원칙은 입증되었습니다. 공급업체의 특정 구현은 신뢰할 만하지만(그들이 명시한 설계 의도 자체이므로) 실제 장비에 대한 우리의 검증은 이루어지지 않았습니다.

도구

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의 만능 키(one-key-fits-all) 결함과 가장 구조적으로 유사한 형태입니다. 하지만 이는 동어반복입니다: 두 핸들러 모두 해당 키를 수락하도록 구성되어 있으므로 실패할 수 있는 실행 경로가 없습니다. 코드가 존재로 정의하지 않는 어떤 것도 증명하지 않습니다. Test 1에서 Test 3으로 가는 내러티브 다리로 유지됩니다; 증거적 가치가 없으며 의도적으로 증명 근거로 삼지 않습니다.

python test2_shared_secret_fails.py

test3_mutual_tls_fix.py — 수정, 음성 대조군 및 양방향 포함

실제 CA, 개별적으로 고유한 두 장치 인증서 — 신원은 폐기 예정(deprecated) CommonName이 아닌 SubjectAlternativeName에 바인딩됨. 5가지 케이스, 모두 실행됨:

• [1] 장치 A의 자체 인증서 → 허용(GRANTED) · [2] 인증서 없음 → TLS 핸드셰이크에서 거부 · [3] 장치 B의 CA 유효 인증서 → 신원 확인에서 거부(DENIED) (엄격한 엔드포인트).
• [4] 대조군(THE CONTROL) — 동일한 장치 B 인증서를 CA 유효성-만 확인하는 엔드포인트에 제시 → 허용(GRANTED). 이것이 [3]이 의미를 갖게 하는 핵심입니다: 신원 검사가 없으면 어떤 플릿 인증서로도 모든 장치가 열립니다(== TLS 옷을 입은 Test 2).
• [5] 역방향(REVERSE) — 장치 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 폐기 조항의 경험적 내용입니다. 고유성(Test 3) ≠ 폐기 가능성; 자격 증명을 되돌릴 수 있음을 보여줍니다.

python test4_revocation.py

범위 경계 (주장하지 않는 것)

• 폐기 — 이제 입증됨(test4_revocation.py); 교체 — 아직 아님. 장치별 고유성(Test 3)은 폐기 가능성과 같지 않습니다; Test 4가 그 격차를 메웁니다 — 여전히 유효하고 만료되지 않은 CA 서명 자격 증명이 폐기 전에는 허용되고 폐기 후에는 거부됩니다. CA 서명 CRL이 이제 해당 일련번호를 나열하기 때문입니다. 교체(대체 자격 증명을 재발급하고 이전 것을 폐기)는 밀접하게 관련되어 있으며 동일한 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

다음 단계 (남은 실제 항목 1개, 작은 선택 항목 2개)

• 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])에 제출하기 전: 구매한 IEC 62443-4-2:2019 사본으로 각 CR의 규범적 본문을 대조 검증하십시오.
• 단계적 롤아웃 — 초안 작성됨 → PHASED_ROLLOUT.md (0단계 출혈 멈추기 · 1단계 망 분리 · 2단계 보완 통제 · 3단계 CIP Security/PKI, 하드웨어 허용 시 · 4단계 운영). 소규모 유틸리티에 적합한 규모; CIP Security가 하드웨어에 의해 제한된다는 점을 정직하게 명시하므로 0~2단계가 어쨌든 위험 감소를 담당합니다.
• 여전히 열려 있음 — 실제 남은 항목: 책임 있는 공개(disclosure) 순서. PSIRT에 먼저 연락하고, 그다음 공개 글 / LinkedIn을 작성하여 출처 체인이 순서대로 문서화되도록 합니다. 아직 초안 작성되지 않음: PSIRT 이메일 자체.
• 작은 기술 항목 2개 — 숨기지 않고 명시적으로 명명함 (매핑 문서 자체 요약에 따름): CR 1.8을 "활성화됨"에서 완전히 입증됨으로 끌어올리기 위한 교체 테스트(재발급 + 폐기)와 CR 3.1을 "구성상 충족"에서 입증됨으로 끌어올리기 위한 변조 주입 테스트. 둘 다 핵심 주장을 뒷받침하는 필수 요소는 아닙니다; 작업으로 수행한다면 둘 다 작습니다.

인용 — 회상이 아닌 검색으로 확보 (그리고 제출 전 다시 검색할 것)

여기에 있는 모든 외부 식별자는 훈련 데이터에서 기억해낸 것이 아니라 2026-07-31에 실제 소스에서 직접 가져온 것입니다: AA26-097A(다중 출처, WaterISAC / Tenable / SecurityWeek 포함), 공개된 4개 피해 시설 중 하나인 Braham, 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(통신 무결성) 정확성 확인. 패킷 작성 규율: 제출 시점에 모든 식별자를 1차 출처에서 다시 검색하십시오. 권고는 번호가 다시 매겨지고, 확장되고, 대체됩니다 — AA26-097A는 이미 한 차례 확장된 바 있습니다 — 따라서 "2026-07-31에 검증됨"은 "제출 시점에 검증됨"이 아닙니다. CR별 공식 62443-4-2 매핑 전체는 이제 작성되었습니다(62443-4-2_SL2_MAPPING.md) — 남은 것은 매핑 자체를 작성하는 것이 아니라, 제출 전에 구매한 표준 사본으로 인용된 규범적 본문을 다시 대조 확인하는 것입니다.

l0gic — Patrick Crosby · 2026-07-31.

강화 기록: Test 3은 음성 대조군(case 4, 단순 발동이 아닌 필요성 증명), 역방향 케이스(case 5, 상호 바인딩), SAN 기반 신원(CN이 아님)을 포함하도록 강화되었으며, 이후 5개 케이스를 모두 재실행하여 재검증되었습니다; Test 4(CRL 폐기)가 추가되었습니다. Test 1/2 설명은 세 가지 실패 클래스를 구별할 수 있도록 규모를 조정했습니다; Test 2는 "테스트"에서 내러티브 다리로 강등되었습니다; 폐기 및 상수 시간 범위 경계가 추가되었습니다. 인용 체인은 1차 출처에서 검색되었으며 제출 시 재검색하도록 스탬프가 찍혔습니다.