쿠팡 해킹 가설: 서버 인증 취약점과 내부자, 3,370만 계정 정보는 어떻게 빠져나갔나?

By PLURA 2025-12-01

핵심 한 줄 요약
2025년 6월 24일부터 수개월간, 공격자는 쿠팡 서버의 인증 취약점을 악용해 정상 로그인 없이 3,370만 개 이상의 고객 계정에서 이름·이메일·전화번호·배송지 주소 등을 유출한 것으로 정부 조사에서 확인되었습니다.

쿠팡 서버 인증 취약점 기반 공격 시퀀스 가설

아래 문서는 “쿠팡 개인정보 유출 사건에서 핵심은 ‘서버 인증 취약점 + 내부자(혹은 내부 지식 악용자)’의 조합이다” 라는 가설을 전제로 작성하였습니다.

정부는 공격자가 쿠팡 서버의 인증 취약점을 악용해 정상 로그인 없이 개인정보를 유출했다고 공식 발표했습니다.
동시에, 중국 국적 전 직원이 핵심 용의자로 지목되고 있으며, 이미 해외로 출국한 상태라 수사가 쉽지 않다는 보도가 이어지고 있습니다.

즉, “내부자가 알고 있던 서버 구조·API·인증 취약점이 외부에서 재활용되었다”는 시나리오가 상당히 설득력을 갖습니다.

물론 실제로는 계정 탈취, 추가 취약점, 기타 내부 통제 실패 등 다른 요소가 복합적으로 작용했을 수 있습니다.
따라서 본 글은 현재까지 공개된 정보 기반의 합리적 가설이며, 향후 수사 결과에 따라 수정될 수 있습니다.

1. 쿠팡 개인정보 유출 사건 개요

1.1 사건 요약

2025년 6월 24일경부터 해외 서버에서 쿠팡 고객정보 DB로 비정상 접근이 시작된 것으로 정부 조사에서 확인되었습니다.
공격자는 쿠팡 서버의 인증 취약점을 악용해 정상적인 로그인 절차 없이 3,000만 개 이상 계정을 대상으로 이름·이메일·전화번호·주소 등을 유출했습니다.
쿠팡은 초기에 “4,500개 계정 노출”이라고 발표했으나, 열흘 뒤 3,370만 계정 유출로 정정했습니다.
일부 언론에서는 쿠팡이 초기에 “유출” 대신 “노출”이라는 표현을 사용해 사고 규모가 축소된 것처럼 보였다고 비판하기도 했습니다.

1.2 유출 정보 범위

확인된 유출 항목:
이름, 이메일 주소, 전화번호, 배송지 주소 등 고객 식별 및 연락에 사용 가능한 정보.
특히, 일부 사용자는 배송지 메모에
공동현관 비밀번호·출입 방법 등을 기록해둔 경우도 있어,
2차 범죄로 이어질 가능성까지 지적되었습니다.
쿠팡 발표: 결제정보·신용카드번호·로그인 정보는 유출되지 않았다고 주장.
정부 입장: “단정할 수 없다”며 결제 정보까지 포함한 정밀 조사를 진행 중.

1.3 내부자 의혹

다수 매체에서 중국 국적 전 쿠팡 인증 시스템 담당자가 핵심 용의자로 보도되었습니다.
이미 해외로 출국한 상태라 수사가 쉽지 않다는 분석도 나왔습니다.
경찰은 쿠팡 측에 협박성 이메일이 도착한 정황 등을 포함해 수사 중입니다.

1.4 악성코드 및 외부 침입 흔적

현재까지 정부·언론 보도에 따르면 악성코드나 외부 침입 흔적은 발견되지 않았습니다.
이는 이번 사건이 “전통적인 서버 해킹(포트 스캔 → 악성코드)”이 아니라,
인증·권한 설계 허점 + 내부 지식 악용에 가까운 공격일 가능성을 높입니다.

2. “서버 인증 취약점”이란 무엇인가 — Broken Authentication / Access Control 관점

정부 발표의 “서버 인증 취약점”은 OWASP·MITRE 기준으로 보면
Broken Authentication / Broken Access Control 계열입니다.

대표적인 유형:

2.1 인증이 빠진 내부용 API가 외부 노출

/internal/api/user-detail?userId=12345 같은 내부용 API가
라우팅/방화벽 설정 오류로 외부에서 직접 호출 가능해진 경우
인증·인가 검증이 없다면, 단순히 userId만 바꿔도 개인정보가 반환될 수 있음

2.2 IDOR (Indirect Object Reference)

/api/user/{userId}/profile과 같이 ID를 직접 조작하면
다른 사용자의 데이터에 접근할 수 있는 취약점

2.3 마스터 계정/토큰 오남용

백오피스나 고객센터에서 사용하는 마스터 API 키가
- 권한 회수 누락
- 권한 과다
- 외부 유출
  등의 문제로 “정상 로그인 없이 전체 DB 접근”이 가능해지는 문제

2.4 서버 간 신뢰 관계 위장

내부 서비스 간 신뢰를 위한 간소한 헤더/토큰을 악용
공격자가 내부 서비스인 척 위조 요청을 보내 민감 API 호출

3. 가설: 내부 지식을 가진 공격자가 서버 인증 취약점을 이용한 흐름

3.1 단계 1 — 내부 구조 및 취약 API 인지

인증 시스템을 실제로 다루던 쿠팡 전직 직원(중국 국적)이
- 내부 API 구조
- 백오피스 엔드포인트
- 마스터 키/관리자 기능
  등에 대해 깊이 이해하고 있었을 가능성이 큼.

3.2 단계 2 — 해외 서버를 이용한 외부 접근 재현

퇴사 후, 공격자는 해외 VPS 여러 대를 준비
내부에서 사용하던 API 호출 패턴을 외부에서 재현
헤더/파라미터/토큰 조합을 조정하며 “로그인 없이도 응답이 나오는 엔드포인트” 탐색

3.3 단계 3 — 인증 우회된 대량 조회 자동화

취약한 API를 찾으면
- ID 범위를 순차/랜덤으로 호출
- 응답에서 이름·이메일·전화번호·주소 등을 자동 수집
몇 달에 걸쳐 3,370만 계정 규모로 축적

3.4 단계 4 — 5개월 동안 탐지되지 않은 이유

모두 HTTP 200 OK 정상 응답
낮은 속도·긴 기간으로 운영해 평시 트래픽과 섞임
해외 IP라도 지속적 모니터링 부재
특히:

3.5 이번 사건 핵심 — “요청/응답 본문 관제”의 부재 🔍➡️🧩

요청/응답 본문(Body)에 어떤 데이터가 오고 갔는지 감시하는 체계가 없다면,
정상 응답처럼 보이는 HTTP 200 트래픽 속에서
수십만 건의 개인정보가 포함된 ‘문제의 응답’을 절대 알아낼 수 없습니다.

쿠팡 사건은 상태코드·용량 기반 관제의 한계를 드러낸 대표 사례
이 부분은 5장에서 PLURA-XDR 기반 해결책으로 연결됩니다

4. 근본적인 문제점: 인증 설계 + 모니터링 실패

4.1 인증·권한 설계 미흡

프런트 로그인 단계만 검증
백엔드 API 단위의 인증·권한 체계 부재
“내부용 API니까 괜찮겠지”라는 설계 관행

4.2 내부자 악용 방지 설계 부재

내부자·전직원의 지식을 가정한 Zero Trust 모델 부족
퇴사자 계정/마스터 권한 회수 미흡
개인정보보호법의 ‘최소 권한·즉시 말소’ 의무 준수 여부가 이번 사건 핵심 쟁점

4.3 대량 조회 탐지 체계 미흡

IP·국가·응답 크기 기반의 통합 시나리오 탐지가 없었음
“5개월간 유출 사실을 몰랐다는 것” 자체가 구조적 문제

4.4 요청·응답 본문 기반 유출 탐지 부재

본문 안의 개인정보 필드 수/패턴을 기준으로 한 경보가 전무
응답 크기가 크더라도, 사용자의 정상 페이지 요청으로 보일 수 있음

5. PLURA-XDR 관점: 요청/응답 본문 기반 데이터 유출 방어 시나리오 🧩

※ 이 장은 3.5에서 제기한 문제를
PLURA-XDR이 어떻게 해결할 수 있는지 설명하는 부분입니다.

5.1 요청/응답 본문 분석으로 잡아낼 수 있는 징후

응답 본문 내 개인정보 패턴 과다
동일 IP/토큰에서 단시간 내 반복되는 개인정보 응답
요청 본문에서 userId/accountKey 대량 포함
해외 IP + 대용량 응답 조합

5.2 PLURA-XDR의 데이터 유출 탐지 흐름 (쿠팡형 시나리오)

이상 응답 탐지
- 응답 크기 + 개인정보 패턴 + 필드 수 기반 스코어링
유출 시나리오 자동 그룹화
- “해외 IP + 반복 조회 + 대용량 응답 + 동일 API” 조합
사고 후 포렌식 자동화
- 최초 시점, 유출 범위, 필드 단위 분석, 타임라인 자동 생성

6. 정리: 쿠팡 사건에서 배우는 교훈

1) 서버 인증 취약점
2) 내부자(내부 지식) 악용
3) 본문 관제 부재로 인한 장기간 탐지 실패

이 세 요소가 합쳐지면
“정상 200 응답” 속에서 수천만 건의 개인정보가 무감지 유출될 수 있다는 것을 보여줌.

7. 최종 제언

이제 보안 전략은 네트워크 경계 방어 중심에서
데이터 사용 관제 중심(요청/응답 본문 분석)으로 이동해야 함
PLURA-XDR은
- 요청/응답 본문 기반 민감정보 탐지
- 시나리오 기반 대량 조회 인시던트 그룹화
- 필드 단위 포렌식
  을 동시에 제공할 수 있음
쿠팡 사건과 같은 유형의 공격도
초기 단계에서 경보 → 차단 → 증적화가 가능해짐

용어 정리

IDOR (Insecure Direct Object Reference)

사용자가 직접 조작 가능한 객체 식별자(userId, fileId 등)에 대하여
적절한 인증·권한 검증 없이 다른 사용자의 객체에 접근할 수 있게 되는 취약점.