쿠팡 사태를 통해 확인된 웹 시스템 기반의 고객 데이터 유출 위험성 : 공공 및 금융기관도 보안 강화 시급

인증된 접근의 역설

최근 국내 최대 물류·커머스 기업인 쿠팡에서 발생한 초대형 고객 정보 유출 사고는 사회 전반에 큰 충격을 던지고 있습니다.

그동안 수 많은 서비스 사이트들로부터 고객개인정보가 유출되었다는 기사를 접한터라 이제는 대한민국 국민의 개인정보는 더 이상 개인정보가 아니라 공공재라는 말까지 나오고 있는 상황입니다. 그럼에도 불구하고 무려 3,370만 명에 달하는 쿠팡 회원의 개인정보가 유출됐다는 사실은 충격을 넘어 허탈함까지 느끼게 합니다.

혹여나 자신은 쿠팡 회원이 아니기 때문에 또는 이미 탈퇴하였기 때문에 내 정보는 괜찮겠지라고 라고 생각하는 개인이 있다면 오산일 가능성이 매우 높습니다. 이번에 유출된 정보들은 쿠팡 회원들의 그동안의 과거 모든 배송정보를 체계적으로 크롤링 해 간 것으로 추정되기 때문에 자신을 포함한 지인 누군가에 의해 한번이라도 자신의 주소로 배송이 되었다면, 그 모든 주소와 전화번호 및 이름, 심지어는 공동현관비밀번호까지 해커들의 손에 넘어간 상태라고 봐야 합니다. 참고로 「전자상거래 등에서의 소비자보호에 관한 법률」 제6조(거래기록의 보존)에 의해 회원탈퇴 여부와 무관하게 전자상거래 거래기록은 5년을 보존하도록 되어 있습니다.

이러한 사태가 발생되면 정부에서는 부랴부랴 문제의 원인을 파악하고 책임소재를 따져 ‘재발방지’ 대책과 조치를 취합니다. 현재까지 파악된 바로는 쿠팡의 ‘인증키 관리’ 부실이 주된 원인으로 알려지고 있습니다.

그러나 과연 원인으로 파악된 된 ‘인증키 관리’가 철저하게 이루어지면 유사한 사태가 재발하지 않을까요? 안타깝게도 많은 관계자들은 키 관리가 완벽하게 준수되고 있는 정부, 공공기관 및 금융기관을 포함하여 대부분의 웹 시스템에서 언제든지 유사한 해킹이 발생될 수 있다는 가능성에 대해서는 간과하고 있는 듯 합니다.

이 사건의 핵심에는, ‘인증키 관리’ 라기 보다는 정상적인 인증 절차를 거친 접근 권한이 대규모 데이터 유출의 통로가 되었다는 '인증된 접근의 역설(The Paradox of Authenticated Access)'에 있다고 할 수 있습니다. 전통적인 보안 모델을 탑재한 시스템은 인증(Authentication)과 인가(Authorization)를 통과한 주체를 '신뢰할 수 있는 사용자(Trusted Entity)'로 간주하고 데이터를 제공합니다. 그러나 이는 내부자, 또는 권한을 확보한 공격자가 API를 통해 대량의 민감 정보를 손쉽게 수집(크롤링)할 수 있는 근본적인 취약점을 남깁니다.

이처럼 인증된 사용자에게 API를 통해 평문 데이터를 전달하는 보안 위험성은 쿠팡과 같은 민간 기업을 넘어 정부 시스템, 금융 시스템을 포함한 국내 모든 웹 기반 시스템에 보편적으로 상존합니다.

따라서 이 문제의 근본적인 원인은 특정 기업의 시스템 또는 보안 체계의 결함이 아니라, 웹 서비스의 기본 작동 원리인 '브라우저 렌더링을 위한 평문 데이터 노출'이라는 구조적 취약점에 있다고 할 수 있습니다.

본 보고서는 쿠팡 사태의 메커니즘을 분석하고, 기존 보안 기술의 한계를 넘어 브라우저 단에서의 데이터 보호 기술을 포함한 새로운 보안 패러다임의 도입 필요성을 제언하는 것을 목적으로 합니다.

권한 위조를 통한 API 크롤링 공격의 분석

이번에 쿠팡을 통해 개인정보를 탈취해간 해커는 회사를 퇴사한 전직원 이라고 알려지고 있습니다. 언론을 통해서 확인된 ‘크롤링’ 방식으로 개인정보에 접근할 수 있었다고 하니, 다음과 같은 방법이 사용되었을 것으로 추정됩니다.

1.
자체 제작된 크롤링 프로그램을 이용해 임의의 PC에서 서명된 위조토큰을 첨부하여 쿠팡 API서버에 배송정보 데이터 요청
2.
요청정보는 방화벽을 포함한 수 많은 네트워크 보안시스템을 유유히 통과하고 서버에 도착
3.
서버는 이 요청이 정상적으로 로그인된 사용자의 요청으로 처리하고, 내부 데이터베이스로부터 배송 데이터를 조회하여 가져옴
4.
조회된 정보를 요청한 크롤링 프로그램으로 전송

그러면 크롤링 프로그램은 로그인 없이도 서명된 위조토큰을 어떻게 생성할 수 있었을까요?

2.1. 인증 토큰 기반의 API 요청 메커니즘

쿠팡을 포함하여 많은 웹 시스템에서는 로그인을 하게 되면 사용자 인증을 인정하는 일종의 신분증과 같은 토큰을 발행합니다. 이 토큰은 종종 사용자의 편리성을 위해 매번 서버에 정보 요청을 할때 다시 로그인을 해야하는 불편함을 없애기 위해 프리패스 용도로 사용됩니다.

또한 인증토큰은 위/변조를 방지하기 위해 우리가 흔히 금융기관에서 사용했던 ‘공인인증서’와 같이 안전하고 신뢰할 수 있는 전달메커니즘으로 공인된 도장과 같은 ‘전자서명’이 포함되어 있습니다.

인증토큰의 진위여부를 확인해 부는 ‘전자서명’은 구조적으로 서버에서 생성하도록 되어 있습니다. 그런데 어찌된건지 쿠팡사태에서는 이 전자서명을 해커가 자신의 PC에서 맘대로 할 수 있었습니다.

이게 어떻게 가능했을까요?

2.2. 인증토큰 전자서명키 탈취 및 장기 유효 인증 토큰 위조 시나리오

쿠팡 사태에서 확인된 공격은 단순한 토큰 탈취를 넘어 인증 시스템의 핵심 신뢰 요소를 악용한 방식이었습니다. 사고 원인은 다음과 같다고 알려지고 있습니다.

1.
핵심 자산 탈취: 퇴사 직전의 정규직 개발자인 해커는 인증 토큰의 전자서명에 사용되는 전자서명키(Signing Key)를 탈취했습니다.
2.
위조 토큰 생성 및 사용: 해당 개발자는 탈취한 서명키를 이용해 위조된 인증 토큰(Access Token)을 생성했습니다.
3.
장기간의 무단 접속: 공격자는 이 위조 토큰을 사용하여 탈퇴했거나 휴면 상태인 계정을 포함한 약 3,370만 명의 이용자 계정으로 크롤링 기법을 이용하여 주문상세 정보를 수집했습니다.

이러한 방식으로 위조된 인증 토큰 으로 정상적인 접근권한을 만들어냈고, 이 위조된 권한이 정상적인 API 게이트웨이를 통해 대규모 데이터에 접근할 수 있었습니다.

2.3. 네트워크 경계 및 DB 통제의 무력화

기존의 방어 대책은 이러한 공격 벡터 앞에서 근본적인 한계를 드러냅니다.

•

방화벽 및 네트워크 보안 강화 : API 크롤링은 유효한 인증 토큰을 가진 주체가 시스템이 지정한 정상적인 API 게이트웨이를 통해 수행하는 행위이므로, 네트워크 방화벽은 이를 정상 트래픽으로 인식하고 허용할 수밖에 없습니다.

•

내부 DB 접근 통제 : 데이터베이스 자체 접근 통제는 유효하나, API 서버는 인증된 요청을 처리하기 위해 DB 접근이 허가된 시스템입니다. 요청자의 토큰이 유효하다면, 서버는 내부 프로세스에 따라 DB로부터 정보를 조회하고 이를 응답 구조에 맞춰 평문 데이터로 내어 줄 의무가 발생합니다.

즉, 아무리 보안이 철통같다하더라도, 일단 '인증된 것으로 간주되는 사용자'의 요청에 대해서는 기존 보안 장치들이 효과적으로 대규모 데이터 유출을 방어할 수 없는 근본적인 취약점이 드러납니다.

구간보안(E2E Encryption)의 한계와 브라우저 메모리 보안의 필요성

인증의 허점을 보완하기 위해 도입되는 구간보안(End-to-End Security)은 클라이언트에 전달되는 데이터 자체를 암호화하여 통신 구간의 안정성을 높입니다.

그러나 구간보안만으로는 크롤링 위협을 완전히 해소할 수 없습니다. 그 이유는 현존하는 대부분의 웹 시스템들이 전달되는 정보를 웹 브라우저 또는 동종의 웹킷을 통해 보여주는 구조이다 보니, 바로 클라이언트 단말기, 즉 브라우저의 메모리 영역에 그 한계가 존재하기 때문입니다.

[그림 1] 인증된 사용자의 API 호출에 대한 평문 배송정보 응답 현황

사용자가 정보를 화면에서 시각적으로 확인하기 위해서는 구간보안을 통해 암호화된 데이터라 하더라도 반드시 브라우저 내부에서는 암호화 해제 과정을 거쳐야 하며, 이 암호 해제된 데이터는 화면 렌더링을 위해 DOM(Document Object Model)이나 JavaScript 변수, 또는 브라우저의 렌더링 메모리 영역에 평문(Plaintext) 형태로 존재할 수밖에 없습니다.

[그림 2] 배송정보에 주요 개인정보가 메모리 영역에서 텍스트 형태로 노출

이렇게 개인정보가 평문으로 존재하는 순간, 내부자 또는 악성 코드를 통한 메모리 스크래핑(Memory Scraping) 공격, 혹은 브라우저 확장 프로그램 등을 이용한 크롤링 공격의 주요 타겟이 됩니다. 이는 인증된 접근이 성공했을 때 데이터가 최종 소비자에게 전달되는 순간부터의 보안 공백을 의미합니다.

전통적인 구간보안이 적용되어 있는 데이터들에 대해서도 이러한 보안허점이 존재하는데, 쿠팡을 포함한 현존하는 대부분의 웹 서비스 시스템들은 브라우저 메모리 보안은 고사하고 인증된 사용자에게 전달되는 데이터들은 암호화되어 있지 않습니다.

근본적인 보안 대책: 데이터 비가시성 확보와 브라우저 메모리 보안

4.1. 제로 트러스트의 완성: 데이터 표시 직전까지의 비가시성

제로 트러스트(Zero Trust) 기반의 데이터 보안은 인증된 사용자라 하더라도, 사용자에게 보여지는 최종 순간까지 인증이 안되어 있다는 가정으로 데이터를 보호된 형태로 전달해야한다는 원칙을 가지고 있습니다.

즉, 인증의 허점과 클라이언트 단 노출 문제를 근본적으로 방지하기 위해서는 제로 트러스트 원칙을 데이터 최종 표시(Data Presentation) 시점까지 확장해야 한다는 것입니다.

이 개념을 웹 서비스 시스템에 적용하기 위해서는 인증이 완료된 사용자라 하더라도 온전한 평문 데이터를 전달하지 말아야 하며, 브라우저에 데이터를 표시하기 직전까지도 데이터를 평문으로 남겨 놓아서는 안 됩니다. 최종적으로 브라우저만이 내부적으로 인증된 사용자에게 데이터를 화면에 보여주는 순간에만 데이터가 평문으로 존재해야 하며, 브라우저 메모리 내의 다른 영역에서도 평문 형태의 존재를 허용해서는 안 됩니다.

B2C 환경에 적합한 보안 기술

웹 서비스 시스템에서의 제로트러스트 기반의 데이터 유출 방지를 위한 보안 기술들의 종류는 다음과 같습니다.

대규모 웹 시스템 환경에서 인증 허점 공격과 메모리 스크래핑 위협을 방지하기 위한 현실적이고 효율적인 대안은 브라우저 메모리 보안(Browser Memory Security) 기술을 도입하는 것입니다. 이 기술은 최종 사용자 단말기에서 데이터가 화면에 표시되는 순간을 제외하고는 안전하게 보호되도록 보장하는 핵심 방어선 역할을 수행합니다.

제로 트러스트의 심화와 클라이언트 단 보안의 시급성

쿠팡 사태가 보여주듯이, 시스템에 대한 과도한 신뢰(Excessive Trust)와 인증키 관리 부실은 내부자를 가장한 최악의 데이터 유출 공격으로 이어질 수 있습니다. 또한 인증키 관리 원칙 준수만으로는 웹 서비스 데이터 유출의 근본적인 문제점을 해결할 수 없음도 확인하였습니다.

따라서 웹 시스템의 고객 데이터 보호를 위한 보안 패러다임은 현행 강력한 인증체계 관리 방식에서 다음과 같은 방식으로 즉각적으로 전환되어야 합니다.

데이터 비가시성 확보: 제로 트러스트의 최종 단계로서, 클라이언트 단말기에 전달되는 복호화된 민감 데이터가 브라우저 메모리 내에 평문으로 존재하는 시간을 최소화하고,외부의 비정상적인 접근으로부터 해당 메모리 영역을 보호하는 브라우저 메모리 보안 기술의 도입의 의무화.

정부와 금융 시스템을 포함한 국내의 모든 웹 기반 서비스는 이 문제의 시급성을 인지하고, 인증의 성공 여부와 관계없이 데이터를 보호하는 새로운 방어선 구축을 서둘러야 할 것입니다.