보안 카메라 펌웨어에서 나온 깃허브 관리자 토큰, CI 비밀 유출의 전형

엔터프라이즈 환경에서 IP 카메라는 더 이상 단순한 부속 장비가 아니다. 최근 액시스(AXIS)가 자사 카메라에서 리눅스 애플리케이션을 손쉽게 구동하도록 밀어붙이면서, 카메라는 사실상 네트워크에 상시 연결된 소형 리눅스 서버가 됐다. 취약점 관리와 자격 증명 관리 대상에 포함해야 하는 실질적인 공격 표면이라는 뜻이다. 한 보안 연구자가 한화비전(옛 삼성테크윈)의 와이즈넷 XNP-9300RW 카메라 펌웨어를 뜯어본 결과가 이 문제를 상징적으로 보여준다. 로그인 화면을 띄우는 펌웨어 안에, 조직 전체 저장소를 좌우할 수 있는 깃허브 관리자 토큰이 들어 있었다.

암호화를 넘어 도달한 rootfs

한화는 모델별 펌웨어 이미지를 웹사이트에서 내려받을 수 있게 공개해 두고 있었다. 연구자는 이미지를 binwalk로 분석했고, 내부에 AI 관련 파일이 담긴 별도 tarball과 암호화된 것으로 보이는 fwimage.tgz를 발견했다. 첫 번째 계층은 매트 브라운의 기존 분석에 나온 대로 'HTW + 모델명'(즉 HTWXNP-9300RW)이라는 패스프레이즈로 풀렸지만, 그 안에는 다른 방식으로 암호화된 두 번째 fwimage.tgz가 다시 들어 있었다.

두 번째 계층을 여는 열쇠는 함께 들어 있던 fwupgrader 바이너리에 있었다. 이 바이너리는 AES 키를 바이너리 내부의 작은 정적 키 테이블과 XOR 연산해 런타임에 재조립하는 방식으로 난독화되어 있었고, IV는 평문 그대로 박혀 있었다. 실제 복호화는 openssl CLI를 셸에서 호출해 수행했으며, 그 명령 조각들조차 같은 XOR 방식으로 가려져 있었다. 문제는 키와 IV가 하드코딩되어 있고 같은 모델 라인 전체에서 동일하다는 점이다. 하드웨어에 키를 각인하는 방식이었다면 최소한 장비를 물리적으로 소유해야 하는 장벽이 생겼겠지만, 소프트웨어에 고정된 키는 펌웨어 파일 하나만 있으면 누구나 같은 절차를 재현할 수 있다는 의미다.

진짜 사고는 빌드 파이프라인에서 났다

복호화된 rootfs에 trufflehog를 돌리자 하나의 깃허브 토큰이 약 30개 파일에 중복되어 나타났다. 확인해 보니 이 토큰은 해당 조직의 저장소 수백 개에 관리자 권한을 가지고 있었다. 하나의 토큰이 왜 이렇게 많은 파일에 흩어져 있었을까. 원인은 흔하지만 치명적인 실수였다. 카메라 UI를 vite로 빌드하면서 특정 변수에 빌드 시점의 process.env 전체를 그대로 주입했고, 그 결과 CI 잡의 환경 변수 전체가 정적 파일로 구워져 나온 것이다.

이 대목이 한국 실무자들이 가장 새겨야 할 지점이다. vite를 비롯한 프런트엔드 번들러에서 환경 변수를 클라이언트 코드에 노출할 때 개별 키를 골라 넣지 않고 process.env 전체나 넓은 접두어 규칙을 그대로 매핑하면, CI 러너에 주입된 모든 비밀이 브라우저로 배포되는 산출물에 실린다. 연구자는 카메라 관리자 UI에 접속한 사람이라면 이 토큰을 네트워크 너머로 이미 전달받았을 가능성을 지적한다. 실제로 서빙됐는지 아니면 디스크에만 존재했는지는 장비 없이 단정할 수 없지만, 어느 쪽이든 비밀이 배포 산출물 안에 존재했다는 사실 자체가 사고다.

환경 변수에는 또 다른 흥미로운 흔적도 있었다. 미국 국방부에 할당된 IP 대역이 담긴 항목들이 발견된 것이다. 한화비전은 K9 자주포, K10 탄약운반차, K2 흑표 전차 부속 계통, SGR-A1 감시 로봇 등을 만드는 한화그룹의 자회사다. 연구자는 이 IP가 내부 서비스용으로 임의 대역을 쓴 관행일 수도 있고, 모회사나 한화에어로스페이스·한화디펜스USA 같은 계열사가 공유하는 중앙 CI 플랫폼의 흔적일 수도 있다고 추정할 뿐 단정하지 않는다. 다만 공유 CI 환경에서 계열사 간 비밀이 서로의 산출물에 섞여 들어갈 수 있다는 구조적 위험은 눈여겨볼 만하다.

범위와 대응

연구자는 이것이 단발성 실수인지 확인하기 위해 한화 사이트에서 확보 가능한 펌웨어 약 500개를 내려받았다. 전체 약 600여 개 모델 중 펌웨어가 게시된 것을 모았고, 그중 62%를 같은 방식으로 복호화했다. 토큰이 나온 것은 세 개뿐이었으며 모두 동일한 토큰이었다. 나머지가 왜 같은 방식으로 풀리지 않았는지는 규명되지 않았으므로, 노출 규모를 이 표본만으로 일반화하기는 어렵다. 제보를 받은 한화는 보안 신고용 공개 이메일을 운영하고 있었고, 12시간 안에 토큰을 폐기했다고 회신했다. 애초에 토큰이 들어가지 말았어야 하지만, 대응 속도만큼은 이례적으로 빨랐다.

결국 이 사례의 교훈은 카메라 제조사 한 곳의 실수에 머물지 않는다. 빌드 파이프라인에 주입된 비밀을 산출물에서 걸러내지 못하는 구성, 소프트웨어에 고정된 복호화 키, 조직 전체를 여는 광범위한 권한의 장수명 토큰이라는 세 가지 안티패턴이 겹쳤을 때 어떤 일이 벌어지는지를 보여준다. 최소 권한 원칙에 따른 토큰 발급, 클라이언트로 나가는 환경 변수의 명시적 화이트리스트, 배포 산출물에 대한 비밀 스캔 자동화는 카메라 펌웨어뿐 아니라 모든 프런트엔드 배포 파이프라인에 그대로 적용되는 기본기다.