취약점을 지워주는 프로그램이 취약점이었다 — 사설 루트 인증서 하나가 뚫린 이야기
취약점을 지워주는 프로그램이 취약점이었다 — 사설 루트 인증서 하나가 뚫린 이야기
분류: Security · 소프트웨어 공급망 · 신뢰체계 붕괴(코드서명) [정보성]
덱. 한국인터넷진흥원(KISA)이 오래된 소프트웨어를 자동으로 최신 버전으로 갱신해 주는 “보안 취약점 클리닝 서비스”를 시범 운영했습니다. 보안 연구팀 티오리(Theori)는 이 서비스가 기존 보안 프로그램에 얹혀 동작하는 과정에서, 시스템 최고 권한(SYSTEM)으로 임의 코드를 실행할 수 있는 구조적 결함을 찾아 KISA에 제보했습니다. 좋은 의도로 만든 자동 업데이트 기능이, 신뢰 기반 자체가 흔들리면 오히려 가장 위험한 진입로가 될 수 있다는 사례입니다.
리드
취약한 소프트웨어를 자동으로 찾아 최신판으로 바꿔주는 서비스는 얼핏 순수한 방어 기능처럼 보입니다. 그런데 “자동으로 업데이트를 설치한다”는 기능 자체가 이미 시스템 최고 권한을 요구하는 위험한 동작입니다. 이 기능이 의존하는 신뢰 검증 한 겹이 무너지면, 방어 도구가 그대로 공격 도구로 뒤집힙니다. 이번 사례는 그 뒤집힘이 실제로 가능했다는 것을 보여줍니다.
핵심 사실 요약
- KISA는 국내 이용자 PC에 남아있는 오래된 취약 소프트웨어를 자동으로 찾아 최신 버전으로 갱신하는 “보안 취약점 클리닝 서비스”를 2025년 7월 1차 시범 운영했고, 2026년 1분기 정식 서비스를 목표로 2차 시범 운영을 발표했습니다. 이 서비스는 독립 프로그램이 아니라, 이용자 PC에 이미 설치된 특정 보안 프로그램의 내부 모듈로 동작하는 구조입니다.
- 티오리 Frontier Squad는 1차 시범 운영 기간 중 이 서비스의 실제 동작을 분석해 KISA에 취약점을 제보했습니다. 발견된 문제의 핵심은 서비스가 사용하는 사설 루트 인증서(Root CA)의 개인 키가 프로그램 안에 그대로 포함된 채 모든 이용자에게 동일하게 배포되고 있었다는 점입니다. 이 서비스는 브라우저와 로컬 보안 모듈 간 통신을 위해 자체 사설 루트 인증서를 시스템에 설치해 두는데, 공개 인증기관은 로컬호스트용 인증서를 발급하지 않기 때문에 이런 방식을 택한 것으로 보입니다.
- 사설 루트 인증서의 개인 키를 추출할 수 있다는 것은, 그 키로 임의 도메인의 정상 인증서를 위조할 수 있다는 뜻입니다. 티오리는 실제로 키를 추출해
google.com인증서를 생성했고, 해당 보안 프로그램이 설치된 환경의 브라우저가 이를 정상 인증서로 처리하는 것을 확인했습니다. - 더 심각한 지점은, 이 루트 인증서가 단순 TLS 통신 신뢰용을 넘어 운영체제 수준의 최상위 신뢰 권한으로 등록되어 있었다는 것입니다. 이는 웹사이트 인증서뿐 아니라 실행 파일의 디지털 서명 검증에도 영향을 줍니다. 티오리는 임의로 제작한 실행 파일에 이 개인 키로 서명해, 해당 PC 환경이 이를 정상 제조사 서명으로 인식한다는 것까지 확인했습니다.
- 서비스의 자동 업데이트 절차는 (1) 최신 설치 파일 다운로드 → (2) 디지털 서명 검증(신뢰 인증기관 발급 여부·서명 주체명 일치 확인) → (3) 검증 통과 시 SYSTEM 권한으로 설치 파일 실행, 이 세 단계로 이뤄져 있었습니다. 다운로드 경로와 서명 검증이 모두 같은 취약한 사설 루트 인증서 신뢰 기반 위에 있었기 때문에, 개인 키를 손에 넣은 쪽은 이 검증 단계를 전부 우회해 위조한 파일을 정상 업데이트로 위장시킬 수 있었습니다. 이 경로 끝에 있는 것이 SYSTEM 권한 임의 코드 실행입니다.
- 티오리는 이 취약점 자체와 더불어, 국내 보안 프로그램 생태계가 오랫동안 “기존 프로그램 위에 새 기능을 계속 얹는” 방식(글에서 “누적식 보안”이라 부름)으로 확장돼 온 구조적 배경을 함께 지적했습니다. 인터넷뱅킹 등에서 요구해 온 여러 겹의 국내 보안 프로그램이 서로 다른 제조사·모듈로 얽혀 있고, 이 조사팀은 관련 환경(원문 표기: Korea Security Application 2.0)의 위험성을 별도로 2025년 8월 Usenix Security에서 발표했다고 밝혔습니다.
대응방안
- 근본 — 취약점은 이미 KISA에 제보·조치됐다고 원문은 밝힙니다. 다만 이 사례가 보여주는 일반 원칙은, 사설 루트 인증서를 시스템 최상위 신뢰 권한으로 등록하는 구조 자체를 최소화하고, 개인 키를 배포 패키지에 평문으로 넣지 않는 것입니다.
- 차선(운영자·개발자 관점). 로컬 통신용 인증서가 꼭 필요하다면 기기별로 서로 다른 키 쌍을 발급하는 구조(고정된 하나의 키를 모든 이용자에게 재사용하지 않는 것)를 검토합니다. 업데이트 서명 검증 체계는 시스템 전역 신뢰 저장소가 아니라 별도의, 더 좁은 신뢰 범위로 분리하는 것이 안전합니다.
- 탐지 관점. 일반 이용자 입장에서는 직접 확인하기 어려운 영역이지만, 기업 보안팀이라면 사내 PC에 설치된 보안 프로그램이 등록한 사설 루트 인증서 목록을 주기적으로 점검하고, 낯선 루트 CA가 “신뢰할 수 있는 루트 인증 기관” 저장소에 들어가 있지 않은지 확인하는 것이 실질적인 방어선이 됩니다.
짧은 논평
이 사례가 흥미로운 지점은, 취약점이 “새로 추가된 기능”이 아니라 “방어를 위해 추가된 기능” 안에 있었다는 것입니다. 자동 업데이트·자동 패치처럼 좋은 의도로 얹는 기능일수록 SYSTEM 권한·전역 신뢰 저장소 같은 강한 권한을 요구하기 쉽고, 그 권한을 지탱하는 신뢰 기반(여기서는 사설 루트 인증서 하나) 한 곳만 무너지면 방어 기능 전체가 뒤집힙니다. 편의·방어 기능이 새로운 신뢰 경계를 만든다는 점에서, 소셜 로그인이나 SSO 연동에서 반복되는 “신뢰 경계 확장” 문제와도 같은 뿌리로 볼 수 있습니다.
References / 참고자료
- 티오리(Theori) Frontier Squad, “누적식 보안의 위험: 취약점 클리닝 서비스에서 발견된 RCE 사례” — 이 글이 재구성한 원 분석. KISA 보안 취약점 클리닝 서비스의 사설 루트 CA 구조 결함과 SYSTEM 권한 RCE 확인 과정을 다룸. https://theori.io/ko/blog/security-risk-of-security-vulnerability-cleaning-service
이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·이미지를 그대로 옮기지 않았으며, 자세한 검증 과정과 스크린샷은 원문을 참고하세요. 코드 레벨 대조·패치 diff 분석은 하지 않았습니다.