[기술 블로그] 누적식 보안의 위험: 취약점 클리닝 서비스에서 발견된 RCE 사례

 

---

티오리 Frontier Squad 팀의 「누적식 보안의 위험: 취약점 클리닝 서비스에서 발견된 RCE 사례」를 읽고, 보안 프로그램이 사용자 PC에서 어떤 권한으로 동작하는지, 그리고 그 권한이 잘못 설계되었을 때 얼마나 큰 위험으로 이어질 수 있는지를 다시 생각하게 되었다.

 

이번 글에서 가장 인상적이었던 부분은 ‘누적식 보안’이라는 개념이었다. 처음 접한 개념이었는데, 새로운 보안 위협이 생길 때마다 기존 시스템 위에 보안 기능을 하나씩 더 추가하는 방식이 오히려 시간이 지나면서 새로운 공격 표면이 될 수 있다는 점이 흥미로웠다.

 

보안 취약점 클리닝 서비스는 사용자 PC에 설치된 오래된 소프트웨어나 취약한 버전을 찾아내고, 이를 최신 버전으로 업데이트하도록 돕는 서비스다. 취지 자체는 분명히 필요하다. 사용자가 자신이 어떤 프로그램을 오래된 버전으로 사용하고 있는지 일일이 확인하기는 어렵고, 취약한 소프트웨어가 방치되면 악성코드 감염이나 침해 사고로 이어질 수 있기 때문이다.

다만 이번 사례에서 중요하게 봐야 할 부분은, 보안을 강화하기 위해 추가된 기능이 오히려 높은 권한을 가진 공격 경로가 될 수 있었다는 점이다.

 

※ 본 글은 티오리 Frontier Squad 팀의 「누적식 보안의 위험: 취약점 클리닝 서비스에서 발견된 RCE 사례」를 참고하여 작성하였습니다. 

https://theori.io/ko/blog/security-risk-of-security-vulnerability-cleaning-service

누적식 보안의 위험: 취약점 클리닝 서비스에서 발견된 RCE 사례 - Theori 블로그

 

 

---

1. 이 글을 선정한 이유

• 이 사례를 선정한 이유는 단순히 “어떤 보안 프로그램에서 취약점이 발견되었다”는 이야기에 그치지 않기 때문이다.
• 보안 기능을 추가할 때 단순히 기능의 목적만 볼 것이 아니라, 그 기능이 기존 시스템과 어떤 방식으로 연결되는지, 어떤 권한으로 실행되는지, 그리고 어떤 신뢰 체계에 의존하는지까지 함께 봐야 한다는 점을 보여주는 기술 블로그라고 생각하였다. 
• 특히 보안 프로그램은 일반 프로그램보다 높은 권한을 가지는 경우가 많다. 사용자를 보호하기 위해 시스템 깊은 곳에서 동작해야 하기 때문이다.
• 하지만 바로 그 점 때문에, 보안 프로그램의 업데이트 기능이나 인증서 처리 방식에 문제가 생기면 일반 프로그램보다 훨씬 큰 피해로 이어질 수 있다고 생각하였다. 

 

이번 사례도 결국 “패치를 해주는 기능” 자체가 문제가 된 것이 아니라, 패치 파일을 내려받고 검증하고 실행하는 과정에서 신뢰 체계가 무너질 수 있었다는 점이 핵심이라고 생각하였다. 

 

2. 보안 취약점 클리닝 서비스란?

• 보안 취약점 클리닝 서비스는 사용자 PC에 설치된 취약 소프트웨어를 탐지하고, 사용자가 이를 안전하게 업데이트할 수 있도록 안내하는 서비스다.
• 원래 목표는 명확하다. 사용자 PC에 오래된 보안 프로그램이나 취약한 소프트웨어가 남아 있으면, 공격자는 이미 알려진 취약점을 이용해 악성코드를 실행하거나 시스템에 침투할 수 있다.
• 사용자가 직접 모든 프로그램의 버전을 확인하고 업데이트하기는 어렵기 때문에, 이를 보안 프로그램이 대신 확인하고 조치하도록 돕는 구조다.

이미지 출처: Theori 기술 블로그

 

이 구조만 보면 매우 합리적으로 보인다.

• 문제는 이 서비스가 완전히 독립적인 별도 프로그램이 아니라, 이미 사용자 PC에 설치되어 있던 기존 보안 프로그램의 내부 모듈로 동작했다는 점이다.
• 즉, 새로운 보안 서비스를 위해 완전히 독립된 구조를 만든 것이 아니라, 기존 보안 프로그램 위에 패치 안내와 실행 기능을 추가한 형태에 가까웠다.

3. 정상적으로 기대한 업데이트 흐름

1차 시범 운영 당시 서비스의 흐름은 대략 다음과 같이 이해할 수 있다.

• 사용자가 PC를 켜면 보안 프로그램이 설치된 소프트웨어를 확인한다.
• 취약한 버전이 발견되면 사용자에게 보안 업데이트 팝업을 보여준다.
• 사용자가 “취약점 해결하기”를 누르면, 보안 프로그램은 제조사 서버에서 최신 설치 파일을 다운로드한다.
• 이후 다운로드한 파일의 디지털 서명을 검증하고, 정상 파일이라고 판단되면 SYSTEM 권한으로 실행한다.

이미지 출처: Theori 기술 블로그

정상적인 상황에서 이 흐름은 다음과 같다.

단계                                                정상 업데이트에서의 역할

 

취약 소프트웨어 탐지	사용자 PC에 설치된 프로그램 중 취약한 버전이 있는지 확인
업데이트 안내	사용자에게 보안 업데이트 필요성을 팝업으로 알림
패치 파일 다운로드	제조사 업데이트 서버에서 최신 설치 파일을 다운로드
디지털 서명 검증	다운로드한 파일이 신뢰할 수 있는 제조사의 파일인지 확인
SYSTEM 권한 실행	검증된 설치 파일을 실행하여 취약한 소프트웨어를 업데이트

• 겉으로 보면 일반적인 업데이트 방식과 비슷하다.
• 파일을 HTTPS로 다운로드하고, 디지털 서명을 확인한 뒤 실행하기 때문이다.
• 일반적으로 HTTPS는 통신 상대가 정상 서버인지 확인하기 위한 장치이고, 디지털 서명은 파일이 신뢰할 수 있는 제조사에서 제공한 것인지 확인하기 위한 장치다.

하지만 이번 사례에서 중요한 점은, HTTPS와 디지털 서명 자체가 문제가 아니라 그 검증이 의존하는 신뢰 기반이 안전하지 않았다는 점이다.

 

4. 핵심 문제: 사설 Root CA와 Private Key

• 이번 취약점의 핵심은 보안 프로그램이 자체적으로 설치한 사설 Root CA에 있었다.
• Root CA는 쉽게 말하면 “이 인증서를 믿어도 된다”고 판단하는 최상위 신뢰 기준이다. 일반적으로 브라우저나 운영체제는 신뢰할 수 있는 인증기관의 인증서를 기준으로 HTTPS 연결을 검증한다.

그런데 이번 사례에서는 보안 프로그램이 브라우저와 로컬 보안 모듈 간 통신을 위해 자체 사설 Root CA를 시스템에 설치했다.

문제는 이 사설 Root CA의 Private Key가 프로그램 내부에 포함된 상태로 배포되었다는 점이다.

• Private Key는 인증서 신뢰 체계에서 절대 외부에 노출되면 안 되는 값이다.
• 그런데 이 키가 프로그램 안에 포함되어 있고, 모든 사용자에게 동일하게 배포되었다면 공격자가 이를 추출했을 때 문제가 커진다.
• 공격자는 해당 키를 이용해 임의의 도메인에 대한 인증서를 만들 수 있고, 보안 프로그램이 설치된 PC에서는 이를 정상 인증서처럼 인식할 수 있기 때문이다.

 

이미지 출처: Theori 기술 블로그

 

• 기술 블로그에서는 실제로 추출한 Private Key를 이용해 google.com 도메인에 대한 인증서를 생성했고, 보안 프로그램이 설치된 환경에서 브라우저가 이를 정상 인증서로 처리하는 것을 확인했다고 설명한다.
• 이 부분이 중요한 이유는 단순히 “가짜 사이트를 만들 수 있다”는 수준을 넘어서기 때문이다. 해당 Root CA가 운영체제 수준에서 최상위 신뢰 권한으로 등록되어 있었기 때문에, TLS 통신뿐 아니라 실행 파일의 디지털 서명 검증에도 영향을 줄 수 있었다.

5. 기술적으로 보면 핵심은 무엇이었을까?

이번 사례의 핵심은 업데이트 기능 자체보다, 업데이트 과정에서 사용된 신뢰 체계가 안전하지 않았다는 점에 있다.

개념                                  의미

 

HTTPS	서버와 사용자 PC 사이의 통신이 안전한지 확인하는 방식
Root CA	인증서를 신뢰할 수 있는지 판단하는 최상위 기준
Private Key	인증서나 서명을 만들 수 있는 핵심 비밀값
디지털 서명	실행 파일이 신뢰할 수 있는 제조사에서 제공된 것인지 확인하는 장치
SYSTEM 권한	Windows에서 매우 높은 수준의 실행 권한

• 문제는 사설 Root CA의 Private Key가 프로그램 내부에 포함되어 있었고, 이 키를 추출할 경우 공격자가 정상 인증서와 정상 서명처럼 보이는 결과물을 만들 수 있었다는 점이다.
• 즉, 보안 프로그램은 검증 절차를 아예 생략한 것이 아니었다. 오히려 HTTPS 연결도 확인하고, 디지털 서명도 확인했다.
• 하지만 검증의 기준이 되는 신뢰 기반 자체가 이미 무너져 있었기 때문에, 공격자의 파일을 정상 파일로 받아들일 수 있었다.

이 부분이 이번 사례에서 가장 중요한 기술적 포인트라고 생각했다. 보안 절차가 “존재하는 것”과 그 절차가 “안전하게 설계되어 있는 것”은 다르기 때문이다.

 

6. 공격 흐름을 단계별로 보면

이번 사례에서 공격 흐름은 아래처럼 정리할 수 있다.

단계                                 보안 프로그램(A)이 기대한 동작                      실제 발생한 동작

 

HTTPS 연결	제조사 업데이트 서버와 통신	공격자 서버 연결
파일 다운로드	제조사가 제공한 최신 패치 수신	공격자가 제작한 악성 파일 수신
디지털 서명 검증	파일의 디지털 서명 유효성 검사	공격자가 생성한 서명을 정상으로 인식
실행	최신 패치 설치	SYSTEM 권한으로 공격 코드 실행

 

• 이 표에서 가장 중요한 지점은 보안 프로그램이 각 단계를 수행하지 않은 것이 아니라, 각 단계를 수행했음에도 신뢰 기준이 무너져 있었기 때문에 공격자의 파일을 정상 파일로 받아들였다는 점이다.
• 즉, 보안 프로그램은 나름대로 HTTPS 연결도 하고, 파일도 다운로드하고, 디지털 서명도 확인했다.
• 하지만 공격자가 동일한 Root CA의 Private Key를 이용할 수 있다면, 이 검증 절차는 더 이상 충분한 보호 장치가 되기 어렵다.

 

이미지 출처: Theori 기술 블로그

• 사용자 입장에서는 단순히 보안 업데이트 알림을 보고 “취약점 해결하기”를 누른 것뿐이다.
• 하지만 내부적으로는 공격자가 만든 파일이 정상 패치 파일처럼 다운로드되고, 서명 검증까지 통과한 뒤, SYSTEM 권한으로 실행될 수 있었다.

 

7. 왜 SYSTEM 권한 실행이 위험한가

• 이 사례에서 특히 위험한 부분은 최종 실행 권한이 SYSTEM 권한이었다는 점이다.
• SYSTEM 권한은 Windows 환경에서 매우 높은 수준의 권한이다. 일반 사용자 권한으로 실행되는 프로그램과 달리, 시스템 핵심 영역에 접근하거나 중요한 설정을 변경할 수 있는 권한을 가진다.
• 따라서 공격자가 만든 파일이 SYSTEM 권한으로 실행된다는 것은 단순히 하나의 프로그램이 실행되는 문제가 아니다. 공격자가 사용자 PC에서 매우 강한 권한을 확보할 수 있다는 의미에 가깝다.
• 이 때문에 보안 업데이트 기능은 일반 기능보다 훨씬 엄격하게 설계되어야 한다. 업데이트 기능은 외부에서 파일을 가져오고, 이를 검증한 뒤 실행하는 구조이기 때문이다.
• 특히 보안 프로그램처럼 높은 권한을 가진 프로그램이 업데이트 파일을 실행한다면, 그 검증 과정은 더 보수적으로 설계되어야 한다.

8. 이 사례가 보여주는 “누적식 보안”의 문제

• 이번 글에서 가장 인상적이었던 표현은 “누적식 보안”이었다.
• 처음에는 단순히 보안 기능이 많이 쌓여 있다는 의미인가 싶었는데, 원문을 읽어보니 조금 더 구조적인 문제를 가리키는 개념에 가까웠음을 알게 되었다. 

누적식 보안은 새로운 보안 위협이 등장할 때마다 기존 시스템 위에 보안 프로그램이나 기능을 하나씩 더 얹는 방식으로 이해할 수 있다. 예를 들어 키로깅 위험이 생기면 키보드 보안 프로그램을 설치하고, 위변조 위험이 생기면 무결성 검증 프로그램을 설치하고, 오래된 소프트웨어 문제가 생기면 취약점 클리닝 기능을 추가하는 식이다.

 

• 물론 이런 방식은 단기적으로는 효과가 있을 수 있다. 빠르게 문제를 줄이고, 사용자가 직접 하기 어려운 보안 조치를 대신해줄 수 있기 때문이다.
• 하지만 시간이 지나면 문제가 생긴다. 여러 제조사의 보안 프로그램이 사용자 PC에 누적되고, 각 프로그램이 높은 권한으로 동작하며, 그 위에 또 다른 기능이 추가된다.
• 이렇게 구조가 복잡해질수록 전체 시스템을 검증하기 어려워지고, 예상하지 못한 공격 경로가 생길 가능성도 커진다.

이미지 출처: Theori 기술 블로그

 

이번 사례도 비슷하다.

• 오래된 취약 소프트웨어 문제를 해결하기 위해 보안 취약점 클리닝 서비스가 추가되었다. 그런데 그 서비스는 높은 권한으로 패치 파일을 다운로드하고 실행하는 기능을 포함하고 있었다.
• 그리고 그 과정에서 사설 Root CA와 Private Key 관리 문제가 겹치면서, 보안 기능 자체가 공격 표면으로 바뀔 수 있었다.
• 즉, 문제는 “보안 서비스를 만들면 안 된다”가 아니라, 기존 구조 위에 기능을 계속 추가하는 방식이 정말 장기적으로 안전한지 점검해야 한다는 데 있다.

9. 누적식 보안을 구조로 정리해 보면

기술 블로그에서 말하는 누적식 보안의 흐름은 다음과 같이 정리할 수 있다.

흐름                                                     설명

  

새로운 보안 위협 등장	키로깅, 위변조, 취약한 소프트웨어 방치 등 새로운 문제가 발생
보안 프로그램 또는 기능 추가	문제를 빠르게 해결하기 위해 높은 권한을 가진 보안 프로그램이나 기능 도입
시간이 지나며 구조 복잡화	여러 보안 모듈이 PC에 누적되고, 유지보수와 검증이 어려워짐
추가된 보안 기능이 공격 표면화	보안을 위해 도입된 기능이 오히려 공격자가 노릴 수 있는 지점이 됨
다시 새로운 보안 기능 추가	기존 문제를 해결하기 위해 또 다른 기능을 덧붙이는 순환 발생

 

• 이 구조를 보고 나니, 보안은 단순히 “기능을 더 많이 넣으면 안전해진다”는 방식으로 설명하기 어렵다는 생각이 들었다.
• 오히려 보안 기능이 많아질수록 그 기능들이 서로 어떻게 연결되어 있는지, 어떤 권한을 갖는지, 어떤 신뢰 체계에 의존하는지를 함께 봐야 한다는 생각이 들었다.
• 결국 보안에서 중요한 것은 기능의 개수보다, 전체 구조가 검증 가능하고 실패했을 때 피해가 제한되도록 설계되어 있는지가 아닐까 생각하게 되었다. 

10. 조치된 부분과 남는 의미

• 다행히 이 취약점은 실제 공격으로 이어지기 전에 제보되었고, KISA는 관련 내용을 바탕으로 조치를 진행했다.
• 기술 블로그에 따르면 이후 2차 시범 운영 단계에서는 기존의 패치 업데이트 기능이 취약한 소프트웨어를 제거하는 기능으로 변경되었다.

이 부분은 중요하다.

• 현재 동일한 방식의 공격이 그대로 재현된다는 의미가 아니라, 1차 시범 운영 당시 발견된 구조적 위험이 조치되었다는 의미로 이해해야 한다.
• 다만 이 사례를 통해, 보안 프로그램은 사용자를 보호하기 위해 높은 권한을 가지지만 그 권한은 동시에 공격자가 노릴 수 있는 강력한 목표가 될 수 있다는 점을 알 수 있었다.

11. 개인정보보호 관점에서도 생각해볼 점

• 개인정보 보호나 보안에서는 흔히 “더 많은 보호 장치”를 추가하는 방식으로 문제를 해결하려고 한다. 하지만 보호 장치가 많아지는 것만으로 항상 안전해지는 것은 아니다.
• 보호 장치가 높은 권한을 가지고, 사용자 PC 깊은 곳에서 동작하며, 중앙 서버나 인증서 체계와 연결되어 있다면 그 자체가 새로운 위험 요소가 될 수 있기 때문이다. 
• 특히 보안 프로그램이 사용자 PC의 소프트웨어 목록을 확인하고, 취약 여부를 판단하고, 파일을 다운로드하고, 실행까지 수행한다면 이는 단순한 안내 기능을 넘어 시스템 운영에 직접 개입하는 기능이다. 이런 기능은 편리하지만, 그만큼 신뢰 체계와 권한 관리가 매우 중요하다는 생각이 들었다. 

이미지 출처: Theori 기술 블로그

 

결국 개인정보보호와 보안 운영에서 중요한 것은 “보안 기능을 얼마나 많이 추가했는가”가 아니라, 추가된 기능이 최소 권한 원칙과 안전한 신뢰 구조 안에서 동작하는가라고 분석해 보게 되었다. 

 

12. 마무리하며

• 이번 사례를 통해 느낀 점은 보안은 단순히 기능을 더하는 방식으로만 강화될 수 없다는 것이다.
• 취약한 소프트웨어를 찾아 업데이트하도록 돕는 서비스의 취지는 분명히 필요하다. 사용자가 직접 모든 프로그램의 취약 여부를 확인하고 조치하기는 어렵고, 오래된 소프트웨어가 방치되면 실제 침해 사고로 이어질 수 있기 때문이다.
• 하지만 그 문제를 해결하는 방법이 항상 높은 권한의 보안 프로그램 위에 또 다른 기능을 얹는 방식이어야 하는지는 고민이 필요하다.

이번 글을 읽기 전에는 보안 프로그램이나 보안 기능이 추가되면 당연히 더 안전해지는 방향이라고 생각하기 쉬웠다.

그런데 “누적식 보안”이라는 개념을 접하고 나니, 보안을 위해 추가된 기능도 시간이 지나면 관리하기 어려운 구조가 될 수 있고, 경우에 따라서는 공격자가 활용할 수 있는 새로운 통로가 될 수 있다는 점이 인상적이었다.

 

특히 업데이트, 인증서, 디지털 서명, SYSTEM 권한처럼 신뢰와 권한이 함께 작동하는 영역에서는 작은 설계 실수도 큰 위험으로 이어질 수 있다.

 

• 개인적으로는 이 사례가 단순한 취약점 분석이라기보다, 우리가 지금까지 당연하게 받아들였던 보안 프로그램 중심의 보호 방식이 앞으로도 유효한지 질문하게 만든 글이라고 느꼈다.
• 앞으로의 보안은 새로운 기능을 계속 추가하는 것뿐 아니라, 이미 쌓여 있는 보안 구조를 어떻게 단순화하고 검증 가능하게 만들 것인지까지 함께 고민해야 한다. 보안은 더 많이 쌓는 것만큼이나, 무엇을 줄이고 어떻게 신뢰할 수 있게 만들 것인가도 중요하다는 점을 이번 기술 블로그를 통해 배울 수 있었다.