다층 암호화로 감춘 펌웨어도 LLM 앞에서는 종이 상자다 — process.env 한 줄이 만든 국방부 IP와 조직 전체 admin 토큰의 노출
목차
- 요약 (TL;DR)
- Key Judgments
- 시작하는 말 — "난독화는 지루함에만 통했다"
- 사건 타임라인
- 기술 분석 — 이중 암호화 계층과 LLM 보조 리버싱
- 근본 원인 —
process.env한 줄이 CI 전체를 결과물에 새기다 - MITRE ATT&CK / CWE 매핑
- 노출 자산 위험 평가 — 토큰과 국방부 IP
- 전수 조사 결과 — 약 500개 펌웨어, 3개의 동일 토큰
- 신고·대응 평가 — 12시간의 신속 대응과 정정 보도
- 한국 관점 — 국내 방산 계열사와 CTI 함의
- 탐지·완화·대응 권고
- 결론
- 참고 문헌
1. 요약 (TL;DR)
2026년 7월 24일, 보안 연구자(블로그명 hhh.hn, 필명 Austin)가 한화비전(Hanwha Vision, 옛 삼성테크윈) 네트워크 카메라 펌웨어를 분석해 웹 관리 UI 빌드 결과물 약 30개 파일에서 동일한 GitHub 개인 액세스 토큰을 발견했다고 공개했다. 이 토큰은 한화 GitHub 조직 내 수백 개 저장소에 대한 관리자(admin) 권한을 보유하고 있었다. 원인은 단순했다 — 카메라 관리 UI를 빌드하는 Vite 설정에서 환경 변수 하나가 process.env 전체로 지정되어, CI/CD 잡의 전체 환경변수(빌드 시스템 주소, 사내 인프라 IP, GitHub 토큰 포함)가 클라이언트 결과물에 그대로 기록됐다.
연구자는 펌웨어 자체도 2중으로 암호화되어 있었으나, fwupgrader 바이너리를 Ghidra와 Claude Code로 분석해 XOR로 난독화된 AES-256-CBC 키·IV 복원 로직을 수 시간 만에 해제했다고 밝혔다. 이는 "코드 난독화가 예산이 아니라 시간만 벌어주던 시대가 끝났다"는 점을 보여주는 사례다.
노출된 CI 환경변수에는 미국 국방부(DoD) 할당 대역으로 보이는 IP 주소 3개도 포함돼 논란이 됐으나, 한화 측은 확인 후 삼성테크윈 시절부터 내부망 주소 체계로 관행적으로 사용해 온 것이며 DoD 할당 사실을 인지하지 못했다고 공식 회신했고, 연구자는 이 부분의 추측성 서술을 철회·정정했다(2026-07-27). 실제 공격에 의한 것이 아니라 레거시 내부 주소 체계 오용으로 확인된 사안이다.
한화는 신고 접수 후 12시간 이내에 토큰을 폐기해 신속 대응 사례로 평가되나, 근본 원인인 "빌드 시 전체 CI 환경변수를 클라이언트 결과물에 삽입하는 구성"은 시정 여부가 공개되지 않았다.
⚠️ 조사 범위의 한계 — 본 리포트는 연구자 개인 블로그(1차 출처)와 GeekNews 요약 보도에 기반한 분석이다. 한화비전의 공식 보안 공지는 확인되지 않았으며, 실제 카메라 관리 UI에서 토큰이 네트워크로 전송됐는지(공격 표면화 여부)는 연구자 본인도 실기기 부재로 검증하지 못했다고 명시했다.
Key Judgments
| # | 판단 | 신뢰도 |
|---|---|---|
| KJ-1 | 노출 원인은 공격이 아니라 빌드 설정 결함(Vite 환경변수가 process.env 전체로 바인딩)이며, CI 잡의 전체 환경이 부수적으로 클라이언트 결과물에 노출됐다. |
High |
| KJ-2 | 노출된 GitHub 토큰은 조직 admin 권한을 가진 단일 자격증명으로, 하나의 빌드 설정 실수가 조직 전체 코드 자산의 기밀성·무결성 리스크로 직결되는 단일 장애점(SPOF) 구조를 드러낸다. | High |
| KJ-3 | 펌웨어의 이중 암호화(1차: 모델명 기반 패스프레이즈, 2차: 바이너리 내 XOR 난독화 AES 키)는 예전에는 유의미한 방어선이었으나, LLM 보조 리버싱(Claude Code + Ghidra)으로 사람이 수 시간 만에 해제할 수 있게 되어 방어 효과가 사실상 소멸했다. | High |
| KJ-4 | 노출된 CI 환경변수 중 국방부(DoD) 할당 IP 대역 사용은 한화-미 국방부 간 실질적 연계가 아니라, 삼성테크윈 시절부터 이어진 내부 주소 체계 관행의 우연한 충돌로 한화 측 회신과 연구자의 정정을 통해 확인됐다. | High |
| KJ-5 | 약 500개 중 62%의 펌웨어에서 동일 방식의 해독이 성공했고, 토큰이 발견된 3개 펌웨어 모두 동일한 토큰을 포함했다 — 하나의 CI 파이프라인 산출물이 다수 모델 라인에 재사용되는 구조임을 시사한다. | Medium-High |
| KJ-6 | 신고 후 12시간 내 토큰 폐기는 신속했으나, 공개된 정보만으로는 근본 원인(빌드 스크립트의 process.env 전체 노출)이 시정되었는지 확인되지 않는다 — 재발 가능성이 남아 있다. |
Medium |
| KJ-7 | 한화비전은 감시 카메라 외에 자주포·장갑차 하위 시스템·경계로봇 등을 생산해온 한화그룹 계열사로, 이번 사안은 단일 IoT 벤더 리스크가 아니라 방위산업 연관 기업의 소프트웨어 공급망 보안 성숙도 문제로 확장해 볼 여지가 있다. | Medium |
2. 시작하는 말 — "난독화는 지루함에만 통했다"
이 사건이 CTI 관점에서 흥미로운 지점은 유출 그 자체보다 유출에 이르는 경로의 붕괴 속도다. 한화는 펌웨어 보호를 위해 최소 두 겹의 암호화를 적용했다 — 모델명 기반 패스프레이즈로 외부 tarball을 감싸고, 내부 fwimage.tgz는 별도의 AES-256-CBC로 다시 감쌌다. 키와 IV는 바이너리 내부에 평문으로 두지 않고 정적 테이블과의 XOR 연산으로 흩어 놓았다. 2023년 기준으로는 개인 연구자의 시간과 인내심을 소진시키기에 충분한 장벽이었다.
그러나 연구자는 이 난독화 로직을 사람이 직접 Ghidra에서 추적하는 대신 Claude Code에 바이너리 분석을 맡기고 자리를 비웠다고 서술한다. 저녁 식사를 마치고 돌아왔을 때는 이미 복호화 로직 설명과 완전한 루트 파일시스템이 준비되어 있었다. 이는 GeekNews 댓글 스레드에서도 핵심 논쟁거리로 다뤄졌다 — "난독화는 공격자를 막는 게 아니라 지루하게 만들어 포기시키는 장치였을 뿐이며, 국가 배후 조직이나 전문 범죄집단은 애초에 그 수고를 감수해왔다. 이제는 LLM이 그 지루함마저 대신 견뎌준다."
펌웨어 난독화의 경제학이 바뀌었다. 방어자 입장에서 난독화에 들이는 엔지니어링 비용 대비, 공격자(또는 연구자)가 이를 해제하는 데 드는 비용이 LLM 보조 리버싱으로 인해 구조적으로 낮아졌다. 이는 이번 사건 하나에 국한된 교훈이 아니라, 하드코딩된 자격증명·키 은닉에 의존하는 모든 임베디드/IoT 벤더에 적용되는 위협 모델 변화다.
3. 사건 타임라인
| 일시 (2026) | 사건 | 비고 |
|---|---|---|
| (미상, 7월 중) | 연구자, 한화비전 웹사이트에 공개된 카메라 모델별 펌웨어 이미지를 다운로드해 분석 착수 | AXIS의 리눅스 애플리케이션 지원 확대 논의 중 계기로 관심 전환 |
| (미상) | binwalk로 이미지 분석 → 1차 암호화된 fwimage.tgz 확인, Matt Brown의 사전 공개 분석(모델명 기반 패스프레이즈)으로 1차 해제 |
HTWXNP-9300RW 패스프레이즈로 성공 |
| (미상) | 내부에 존재하는 2차 암호화된 fwimage.tgz 발견 — 기존 방식 재사용 불가 |
|
| (미상) | fwupgrader 바이너리를 Ghidra + Claude Code로 분석, XOR 난독화 해제 → AES-256-CBC 키·IV 복원 및 루트 FS 획득 |
저녁 시간 대에 완료 (연구자 서술 기준) |
| (미상) | trufflehog로 루트 FS 스캔 → 약 30개 파일에서 동일 GitHub 토큰 중복 발견, 조직 admin 권한 확인 |
|
| (미상) | 원인 분석 — Vite 빌드 변수가 process.env 전체로 설정되어 CI 환경 전체가 결과물에 기록됨을 확인 |
GITHUB_NPM_TOKEN 등 다수 변수 포함 |
| (미상) | 약 500개 카메라 모델 펌웨어 전수 수집·해독 시도 — 62% 추출 성공, 그중 3개에서 동일 토큰 재확인 | |
| (미상) | 한화 공개 보안 신고 채널로 최소 정보만 담은 이메일 발송 | |
| (미상, 신고 후 12시간 이내) | 한화, 토큰 폐기 완료 회신 | 신속 대응 사례로 평가 |
| 2026-07-24 | 연구자, hhh.hn 블로그에 전체 분석 공개 ("My security camera shipped a GitHub admin token…") | 국방부 IP 관련 추측 포함 (원문) |
| 2026-07-25 | GeekNews, 국내 요약 보도 (xguru) | 국내 개발자 커뮤니티 확산 |
| 2026-07-27 | 한화, DoD IP 관련 문의에 공식 회신 — "삼성테크윈 시절부터의 내부 주소 체계, DoD 할당 사실 인지 못함, 주소 체계 변경 계획" | 연구자, 원문의 추측성 서술을 취소선 처리하여 정정 |
타임라인에서 짚을 점: 원문에는 각 기술적 단계의 정확한 날짜가 명시돼 있지 않다. 다만 신고폐기(12시간)와 공개정정(약 3일)이라는 두 개의 대응 사이클 모두 한화 측이 실질적으로 응답했다는 점에서, 앞서 다룬 TVING 사례(신고 기한 1분 전 소진형 대응)와는 다른 결의 사고 대응 문화로 평가할 수 있다.
4. 기술 분석 — 이중 암호화 계층과 LLM 보조 리버싱
4.1 1차 암호화 — 모델명 기반 패스프레이즈
한화비전 웹사이트는 모델별 펌웨어 이미지를 공개 다운로드로 제공한다. binwalk 분석 결과 내부에 AI 구성요소 tarball과 암호화된 fwimage.tgz가 확인됐다. 사전 공개된 제3자 분석(Matt Brown)에 따르면 암호는 HTW + 모델번호 조합이며, 해당 모델(HTWXNP-9300RW)에서 실제로 작동했다. 이는 패스프레이즈 구성 규칙 자체가 이미 공개적으로 알려진 상태였다는 뜻이며, 이 계층은 사실상 방어력을 상실한 상태였다.
4.2 2차 암호화 — 바이너리 내 XOR 난독화
1차 해제 후에도 내부에 또 다른 fwimage.tgz가 존재했고, 이번에는 다른 방식으로 암호화돼 있었다. fwupgrader 바이너리 분석 결과:
- AES 키는 바이너리 내 작은 정적 키 테이블과 XOR 연산 후 런타임에 재조립됨
- IV는 바이너리에 평문으로 저장
- 복호화는
fwupgrader가opensslCLI를 셸아웃(shell-out)하는 방식이며, 이 명령 문자열 조각들도 동일하게 XOR 난독화됨 - 복원된 명령 형태:
openssl enc -md sha256 -aes-256-cbc -d \ -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT> - 실제 키/IV (연구자가 공개, 동일 모델 라인에서 공통 사용):
KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0 IV = 53f926801b81454a4f889c9a390db6e6
4.3 LLM 보조 리버싱의 함의
연구자는 이 난독화 해제 작업을 Ghidra 정적 분석과 Claude Code를 결합해 수행했다고 명시했으며, 결과적으로 사람이 전통적 방식으로 며칠 걸릴 작업을 크게 단축했다. CTI 관점에서 이는 다음을 시사한다:
- 방어 비용 비대칭의 역전: 하드코딩된 키를 코드/바이너리 내부에 "숨기는" 접근은 리버스 엔지니어링 비용을 높여 지연시키는 효과에 의존해왔다. LLM 보조 도구는 이 비용을 크게 낮춰, 난독화만으로는 더 이상 유의미한 시간 지연 효과를 기대하기 어렵다.
- 국가 배후·전문 조직에는 원래도 낮은 장벽이었다는 점에서, 이번 사건의 진짜 뉴스는 "전문성이 낮은 개인 연구자도 하룻저녁 만에 도달할 수 있는 난이도로 방어선이 낮아졌다"는 데 있다.
- 방어책은 난독화 강화가 아니라 애초에 장기 자격증명을 클라이언트/펌웨어에 내장하지 않는 아키텍처로 이동해야 한다(§8 권고 참조).
5. 근본 원인 — process.env 한 줄이 CI 전체를 결과물에 새기다
토큰 노출의 실제 원인은 암호화 계층과 무관한, 훨씬 평범한 빌드 설정 결함이었다. 카메라 관리 UI는 Vite로 빌드되며, 빌드 변수 하나가 process.env 객체 전체로 설정돼 있었다. 그 결과 CI 잡이 보유한 전체 환경변수가 고스란히 클라이언트 번들에 하드코딩됐다:
var W = {
DATAPORT: "9090",
GIT_LFS_SKIP_SMUDGE: "1",
npm_command: "run-script",
KUBERNETES_SERVICE_PORT_HTTPS: "443",
GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",
npm_config_userconfig: "/home/docker/.npmrc",
// etc
}
이 패턴은 CWE-798(Use of Hard-coded Credentials)의 전형이지만, 발생 지점이 애플리케이션 코드가 아니라 빌드 도구 설정(Vite define/env 처리)이라는 점에서 일반적인 시크릿 스캐닝 관행이 놓치기 쉬운 영역이다. 소스 저장소 자체에는 토큰이 없었을 가능성이 높고(CI 잡 환경에 주입된 값), 문제는 "빌드 결과물"이라는 시크릿 스캐닝의 사각지대에서 발생했다.
같은 환경변수 묶음에는 내부 인프라 식별 정보(예: SWARM_MASTER_NFS_ADDRESS, OTEL_ELASTIC_URL, CIMIP 등 사내 네트워크 주소)도 포함돼 있었다. 즉 이번 사고는 GitHub 토큰 단일 건이 아니라 CI/CD 파이프라인 전체의 내부 구성 정보가 대량으로 클라이언트 제품에 유출된 사건으로 봐야 한다.
6. MITRE ATT&CK / CWE 매핑
| 범주 | 매핑 | 비고 |
|---|---|---|
| 취약점 유형 | CWE-798 Use of Hard-coded Credentials | 빌드 결과물(클라이언트 UI)에 CI 시크릿 하드코딩 |
| 취약점 유형 | CWE-312 Cleartext Storage of Sensitive Information | 바이너리 내 평문 IV, 노출된 토큰이 암호화 없이 저장 |
| 잠재적 공격 기법 | T1552.001 Unsecured Credentials: Credentials In Files | 카메라 UI 파일 약 30개에서 반복 발견된 토큰 |
| 잠재적 공격 기법 | T1078.004 Valid Accounts: Cloud/SaaS Accounts (GitHub) | 토큰 탈취 시 조직 저장소 전체에 admin 권한으로 접근 가능 |
| 잠재적 후속 기법 | T1195.002 Supply Chain Compromise: Compromised Software Dependencies | admin 토큰 악용 시 코드 저장소 변조를 통한 공급망 오염 가능성(미발생, 이론적 리스크) |
| 방어 실패 지점 | 시크릿 스캐닝 범위 — 소스 저장소는 포함, CI 빌드 결과물(client bundle)은 미포함 추정 | 근본 원인 §5 참조 |
본 사건은 실제 침해가 발생한 사고(incident)가 아니라 사전 노출 취약점의 발견 및 신고(vulnerability disclosure) 사례다. 따라서 공격자의 실제 TTP가 관측된 것이 아니라, "만약 악용됐다면" 가능했을 잠재 경로를 매핑한 것임에 유의해야 한다.
7. 노출 자산 위험 평가 — 토큰과 국방부 IP
| 노출 자산 | 성격 | 악용 시 파급력 | 실제 확인 상태 |
|---|---|---|---|
GitHub 토큰 (GITHUB_NPM_TOKEN) |
장기 PAT(개인 액세스 토큰) 추정 | 조직 내 수백 개 저장소 admin 권한 — 코드 유출, 백도어 삽입, 릴리스 변조 등 공급망 공격 가능 | 신고 후 12시간 내 폐기 확인. 실제 악용 흔적은 보고되지 않음 |
사내 인프라 변수 (SWARM_MASTER_NFS_ADDRESS 등) |
내부망 식별 정보 | 내부 인프라 지도 작성(reconnaissance) 자료로 활용 가능 | 공개 여부·조치 불명 |
| DoD 할당 IP 대역 3건 | 내부 주소 체계 재사용 정황 | 최초 추측: 한화-미 국방부 실질 연계 → 한화 공식 회신으로 반박, 레거시 주소 관행으로 확인 | 한화 회신 및 연구자 정정으로 소명 완료 |
| 관리 UI 자체 노출 범위 | 검증 불가 | 관리 UI 접속 시 토큰이 네트워크로 실제 전송됐는지는 미확인 | 연구자 실기기 미보유로 검증 불가 (블로그 원문 명시) |
DoD IP 항목에 대한 평가: 초기 블로그 원문은 이 주소들이 미 국방부 할당 대역이라는 점을 근거로 "한화가 미 국방부와 직접적 연계가 있는가"라는 추측을 제기했고, GeekNews 댓글에서도 "한국산 보안 제품 회피" 등 과잉 해석이 이어졌다. 그러나 한화 측 공식 회신에 따르면 이는 삼성테크윈 시절부터 이어진 내부 주소 체계 관행이며, 자사가 사용 중인 대역이 DoD에 공식 할당된 사실 자체를 인지하지 못하고 있었다는 것이 실제 원인이다. 연구자는 이를 확인 후 원문의 추측 단락에 취소선을 긋고 정정 문구를 추가했다(2026-07-27). CTI 리포트 작성 시 이러한 소명 이후의 사실관계 갱신을 반드시 원 서술과 분리해 명시해야 하며, 본 리포트는 이 원칙에 따라 정정된 사실을 KJ-4에 반영했다.
다만 "국방부에 할당된 IP 대역을 내부 주소로 임의 재사용"하는 관행 자체는 그 자체로 IP 주소 충돌·라우팅 오작동 리스크를 내포한 잘못된 네트워크 설계 관행이며, 한화도 이를 인정하고 주소 체계 변경 계획을 밝혔다는 점은 별도로 기록해 둘 가치가 있다.
8. 전수 조사 결과 — 약 500개 펌웨어, 3개의 동일 토큰
연구자는 우연한 단일 사례인지 확인하기 위해 한화비전 웹사이트에 공개된 약 600개 카메라 모델 중 펌웨어가 제공되는 약 500개를 전량 수집해 동일한 방식으로 해독을 시도했다.
| 지표 | 값 |
|---|---|
| 수집 대상 모델 수 | 약 600개 (펌웨어 제공 모델 기준 약 500개) |
| 해독 성공률 | 약 62% |
| GitHub 토큰 발견 펌웨어 수 | 3개 |
| 발견된 토큰의 동일성 | 3개 모두 동일 토큰 |
이 결과는 두 가지를 시사한다. 첫째, 해독 실패(38%)의 원인이 명시되지 않았으나 이는 모델 세대별로 암호화 방식이 상이할 가능성을 시사하며, 조사되지 않은 다른 모델군에 별도의 노출이 존재할 가능성을 배제할 수 없다. 둘째, 토큰이 발견된 3개 모델 모두 동일 토큰이라는 점은 하나의 CI 파이프라인/빌드 스크립트가 다수 모델 라인의 UI 빌드에 재사용되는 구조임을 뒷받침하며, 이는 하나의 설정 결함이 제품 라인 전체로 확산되는 전형적인 공급망형 리스크 패턴이다.
9. 신고·대응 평가 — 12시간의 신속 대응과 정정 보도
연구자는 토큰 위치를 식별할 수 있는 최소 정보만 담아 한화의 공개 보안 신고 채널로 이메일을 발송했고, 한화는 12시간 이내에 응답하며 토큰 폐기를 완료했다. 연구자 본인도 "이런 실수는 없어야 했지만, 이렇게 신속한 대응·해결은 드물었다"고 평가했다.
이후 DoD IP 관련 문의에도 한화는 구체적 근거(삼성테크윈 시절부터의 내부 주소 체계, 미인지 사실 인정, 향후 변경 계획)를 담아 회신했고, 연구자는 이를 근거로 원문의 추측 서술을 공개적으로 철회했다. 취약점 신고 대응과 사후 언론 대응 모두에서 실질적이고 투명한 커뮤니케이션이 관측된 사례로, 이는 §7의 TVING 사례(신고 기한 1분 전 소진형 대응, 통지 다크패턴)와 대비되는 참고 사례로 기록할 가치가 있다.
다만 두 가지는 미확인 상태로 남는다.
- 근본 원인인 Vite 빌드 설정(
process.env전체 노출)이 실제로 수정되었는지 여부 - 이미 배포되어 현장에 설치된 카메라들의 펌웨어에 남아있는 구버전 UI 결과물에 대한 조치(재배포·강제 업데이트) 여부
10. 한국 관점 — 국내 방산 계열사와 CTI 함의
- 감시장비-방산 계열사 구조. 한화비전은 삼성테크윈에서 출발해 한화그룹에 편입된 영상 감시 기업이며, 과거 K9 자주포, K10 탄약운반장갑차, K2 전차 하위 시스템, SGR-A1 경계로봇 등을 생산한 이력이 있다. 이번 사안 자체는 방산 제품이 아닌 민수용 CCTV의 웹 UI에서 발생했지만, 한화 그룹 산하에 Hanwha Aerospace·Hanwha Defense USA 등 방산 계열사가 존재한다는 점에서, 그룹 공용 CI 인프라를 사용하는 계열사 간 소프트웨어 공급망 보안 경계 설계가 향후 점검 대상이 될 수 있다.
- 국내 IoT/임베디드 벤더 공통 리스크. GeekNews 댓글에서도 지적됐듯, 하드코딩된 자격증명·위험한 기본값은 국내외를 막론한 IoT 업계의 고질적 문제다. 다만 이번 사례는 "신고 후 12시간 대응"이라는 상대적으로 양호한 벤치마크를 제공하며, 국내 벤더의 보안 신고 대응 프로세스 설계에 참고할 만하다.
- 감시 카메라의 엔터프라이즈 자산화. 원문에서 언급되듯, AXIS 등 업계가 카메라를 "리눅스를 구동하는 엔터프라이즈 네트워크 자산"으로 재정의하는 흐름 속에서, 국내 CCTV 벤더들도 자격증명 수명주기 관리·SBOM(소프트웨어 자재명세서)·시크릿 스캐닝을 빌드 파이프라인 표준 항목으로 채택할 필요성이 커지고 있다.
11. 탐지·완화·대응 권고
제조사 / 임베디드-IoT 벤더 일반
- 빌드 결과물 시크릿 스캐닝 확대 — 소스 저장소뿐 아니라 빌드 산출물(client bundle, 펌웨어 이미지, 컨테이너 이미지)에 대해서도 trufflehog류 시크릿 스캐너를 CI 파이프라인 마지막 단계에 강제 실행한다. 소스에 시크릿이 없어도 빌드 도구 설정 결함으로 산출물에 유입될 수 있다는 점을 이번 사건이 보여준다.
- 빌드 변수 화이트리스트화 — Vite/Webpack 등 번들러의
define/env관련 설정에서process.env전체를 클라이언트에 노출하는 패턴을 금지하고, 명시적으로 필요한 변수만 개별 화이트리스트로 주입한다. - 장기 자격증명 제거 — GitHub PAT 등 장기(long-lived) 토큰을 CI 환경에 상시 배치하지 않고, GitHub Actions OIDC/Fine-grained PAT/짧은 TTL 토큰으로 전환한다. 조직 admin 권한을 가진 단일 토큰이 다수 CI 잡에서 공유되는 구조 자체를 제거한다.
- 펌웨어 암호화의 재설계 — 바이너리 내 XOR 난독화된 키 재조립 방식은 더 이상 유효한 방어선으로 간주하지 않는다. 하드웨어 보안 모듈(HSM/TPM/Secure Element) 기반 키 유도, 디바이스별 고유 키 발급으로 전환한다.
- 내부 주소 체계 감사 — 사내 인프라에 공인 IP 대역(특히 정부·국방 기관 할당 대역)을 내부 주소로 임의 재사용하는 레거시 관행을 전수 점검하고 RFC 1918 사설 대역으로 이관한다.
- LLM 보조 리버싱을 위협 모델에 반영 — 코드/바이너리 난독화를 "시간 지연"이 아닌 방어 대책으로 설계하는 관행을 재검토한다. 위협 모델링 시 "숙련된 개인이 LLM 보조 도구로 하룻밤 안에 난독화를 해제할 수 있다"는 전제를 기본값으로 채택한다.
보안 신고 프로세스 (참고 사례로서)
- 이번 사건의 12시간 내 토큰 폐기 대응과 공개 문의에 대한 구체적 근거를 담은 회신은 타 기업의 취약점 신고 대응 프로세스 벤치마크로 참고할 가치가 있다.
카메라 구매·운용 기업 (엔터프라이즈)
- 네트워크 분리 — IoT/CCTV 장비는 별도 VLAN에 격리하고 인터넷 아웃바운드 접근을 원칙적으로 차단한다.
- 관리 UI 접근 통제 — 카메라 관리 웹 UI 접근을 내부망으로 한정하고, 가능하다면 ONVIF 등 표준 프로토콜 기반의 별도 NVR 경유 운용을 검토한다.
- 펌웨어 업데이트 추적 — 벤더의 보안 공지를 구독하고, 이번 사건과 관련된 펌웨어 패치가 공개되는지 지속 확인한다.
12. 결론
이번 사건의 본질은 "정교한 공격"이 아니라 평범한 빌드 설정 실수(process.env 전체 노출)와 낡은 방어 가정(펌웨어 난독화가 시간을 벌어줄 것이라는 전제)의 동시 붕괴다. 두 겹의 암호화로 감싼 펌웨어는 LLM 보조 리버싱 앞에서 하룻저녁의 장벽에 불과했고, 그 안에서 발견된 것은 조직 전체에 admin 권한을 가진 단일 GitHub 토큰이었다. 국방부 할당 IP라는 자극적인 서브플롯은 실제로는 레거시 내부 주소 체계의 우연한 충돌로 소명됐지만, 그 소명 과정 자체가 — 신고 후 12시간 내 대응, 공개 문의에 대한 근거 있는 회신, 원 저자의 신속한 정정 — 이번 사건에서 가장 인상적인 요소로 남는다.
CTI 관점에서 남는 질문은 두 가지다. 당신의 빌드 파이프라인은 클라이언트 결과물에 무엇을 새기고 있는지 실제로 확인해본 적이 있는가? 그리고 당신의 난독화는 사람을, 아니면 LLM을 막도록 설계되었는가?
13. 참고 문헌
- hhh.hn (Austin) — "My security camera shipped a GitHub admin token in its login page" (2026-07-24, 2026-07-27 정정) — https://hhh.hn/hanwha-github-token/
- GeekNews — "한화비전 보안 카메라의 웹 UI 로그인 페이지에 GitHub 관리자 토큰이 포함돼 출하됨" (2026-07-25, xguru 요약) — https://news.hada.io/topic?id=31784
- Matt Brown — "Hanwha firmware file decryption" (1차 암호화 계층 분석, 원문 참조) — https://brownfinesecurity.com/blog/hanwha-firmware-file-decryption
- Wikipedia — "Hanwha Vision" (연혁, 구 삼성테크윈, 방산 계열사 정보) — https://en.wikipedia.org/wiki/Hanwha_Vision
- NBC News — "Future Tech: Autonomous killer robots are already here" (SGR-A1 관련, 원문 인용) — https://www.nbcnews.com/tech/security/future-tech-autonomous-killer-robots-are-already-here-n105656
- CWE-798: Use of Hard-coded Credentials — MITRE CWE
- CWE-312: Cleartext Storage of Sensitive Information — MITRE CWE
- MITRE ATT&CK — T1552.001, T1078.004, T1195.002
변경 이력
| 버전 | 일자 | 내용 |
|---|---|---|
| v1.0 | 2026-07-28 | 최초 발행 — 원문 및 GeekNews 요약 기반 기술 분석, DoD IP 정정 반영 |
© 2026 Dennis Kim (김호광) · Cyber Threat Intelligence Division [email protected] · github.com/gameworkerkim
본 리포트는 공개 OSINT 자료(연구자 개인 블로그, GeekNews 요약 보도) 기반의 독립 분석이며, 한화비전 또는 관련 기관의 공식 입장을 대변하지 않습니다. 본 사건은 실제 침해(breach)가 아닌 연구자의 책임 있는 취약점 공개(responsible disclosure) 사례이며, 한화 측은 신고 접수 후 신속히 대응했음을 명시합니다. 교육·방어·연구 목적으로만 사용해야 합니다. TLP:GREEN — 커뮤니티 내 공유·대외 공개 가능.