[분석가] 분석 — CVE-2026-15683

• 심각도 high · CVSS 7.5 · EPSS 0.00096 · 악용난이도 hard

• 공격자는 동일 LAN·Wi‑Fi에 존재하며, 카메라 관리 서버와 TLS 핸드쉐이크 시 위조된 인증서를 제시합니다.
• 서버는 인증서 검증 로직이 부실해 이를 수락하고 암호화 채널을 확립합니다.
• 추정: 인증서 회피 후, 관리 API(예: /admin/runCommand)에 전달되는 command 파라미터가 OS 쉘에 그대로 실행되어 루트 권한 RCE가 이루어질 가능성이 있습니다.
• 사용자 개입이 전혀 필요 없으며, 네트워크 인접성만 확보하면 단계별로 진행할 수 있습니다.

악용 가능성: 이 취약점은 AV:A (Adjacent Network) 조건에 따라 공격자가 카메라가 속한 LAN 등 물리적으로 인접한 네트워크에 존재해야만 이용할 수 있습니다. AC:H (High Attack Complexity) 는 인증서 검증 우회를 위해 TLS 핸드쉐이크를 조작하거나 추가적인 취약점과 연계하는 등 복합적인 기술이 요구된다는 의미이며, 이를 구현하기 위한 전문 지식 및 사전 준비가 필요합니다. PR:N (Privileges Required None) 와 UI:N (User Interaction None) 에도 불구하고, 공격자는 별도의 권한 상승 단계 없이 바로 루트 컨텍스트에서 코드를 실행할 수 있습니다. EPSS 값이 0.00096 으로 매우 낮게 측정된 점은 현재까지 실전 악용 사례가 거의 없으며, KEV 목록에 등재되지 않은 점도 동일하게 관측된 위협이 제한적임을 뒷받침합니다. 공격 표면은 카메라의 장치 관리 서버(보통 HTTPS 포트 443)에서 제공되는 인증서 검증 로직이며, 이 엔드포인트가 네트워크에 노출될 경우 인접한 공격자가 위 조작을 시도할 수 있습니다. 따라서 실제 위험성은 낮지만, 네트워크 경계 내부의 접근 권한이 확보된 상황에서는 높은 복잡도의 공격이 가능함을 염두에 두어야 합니다.

• 기술적 위험
  • 루트 권한 원격 코드 실행 → 펌웨어 변조·백도어 삽입·시스템 재부팅·다른 내부 장치로의 횡적 이동.
  • 영상 스트리밍 차단, 녹화 파일 삭제·변조, 서비스 거부(DoS) 등 카메라 기능 전면 마비.
• 비즈니스 리스크
  • 물리 보안 체계 상실 → 규제·프라이버시 컴플라이언스 위반 위험 증가.
  • 영상 데이터 신뢰성 및 가용성 손실로 인한 운영 차질, 기업 이미지 훼손 및 법적 책임 발생 가능.
• 노출 규모
  • 영향을 받는 제품은 “Lorex 2K Indoor Wi‑Fi Security Camera”의 Device Management Server이며, 동일 네트워크에 배치된 모든 카메라가 동일 취약점에 노출될 수 있습니다.
  • 다중 소스에서 일관성이 확인됐으며(교차검증 신뢰도 1.0) 현재 EPSS = 0.00096(백분위 0.00847)로 실측 악용 가능성은 매우 낮지만, CVSS 7.5·AV:A·PR:N·UI:N·C:H·I:H·A:H 라는 높은 기술적 심각도가 존재합니다.

• 본 결함은 ZDI‑CAN‑26851에 보고된 “Improper Certificate Validation”과 동일하며, 인증서 회피 후 OS Command Injection(추정) 등 다른 취약점과 연계될 경우 원격 루트 RCE가 실현됩니다.

• TLS 핸드쉐이크 로그에서 기대되는 Lorex CA와 일치하지 않는 self‑signed 혹은 변조된 인증서 식별.
• 내부 IP → 관리 포트(보통 443) 접속 시 http.uri "/admin/runCommand" 와 같이 명령어 메타문자(;, &&)가 포함된 요청 탐지 (예: dst_port 443 && http.request.body contains ";).
• 카메라 OS 로그에서 비정상적인 execve 또는 루트 권한 프로세스 생성 이벤트 모니터링.

1. 즉시 조치
   • 관리 인터페이스에 대한 TLS 인증서 검증을 강제하고, 신뢰할 수 없는 서버와의 연결을 차단합니다.
   • 해당 포트를 VLAN 등으로 분리하고 내부망에서만 접근 가능하도록 방화벽 ACL 적용; 원격 관리 기능이 불필요하면 비활성화합니다.
2. 근본 해결
   • 제조사 제공 최신 펌웨어(인증서 검증 강화 패치)가 있으면 즉시 적용합니다.
   • 공식 패치가 없을 경우 TLS termination 프록시를 두어 자체 인증서를 검증하고, 위험 API 호출(/admin/runCommand 등)을 차단하거나 파라미터 화이트리스트 적용합니다.
3. 추가 방어
   • API 입력값에 대한 서버‑사이드 검증(특히 command 파라미터) 구현 및 정기적인 코드 리뷰 수행.
   • 로그·네트워크 트래픽에 대한 지속적 모니터링과 취약점 스캐닝으로 유사 시도 조기에 탐지합니다.

• 조치: scheduled (이번 주 내)
• 근거: CVSS=7.5 · non-KEV · EPSS=0.00096 · exploit=hard · in_scope=None