쿠팡 해킹 사건: JWT 서명키 유출과 내부자 악용으로 발생한 3,370만 계정 대규모 정보 유출

By PLURA

2025년 6월 24일부터 약 5개월간, 쿠팡은 정상 로그인 절차 없이도 고객 정보를 조회할 수 있는 인증 취약점을 공격자에게 노출한 채 운영했습니다.
정부 조사와 언론 보도를 종합하면, 사건의 근본 원인은 JWT 서명키 관리 실패 + 내부자(퇴사자)의 지식 악용 가능성으로 좁혀지고 있습니다.

이번 사건은 “내부 지식 및 키 유출이 결합된 외부 공격”이 얼마나 치명적인 결과를 초래할 수 있는지를 보여주는 대표 사례입니다.
특히 국내 대규모 플랫폼 서비스가 요청/응답 본문 기반 관제 부재로 인해, 장기간 진행된 대규모 데이터 유출을 전혀 감지하지 못했다는 점에서 심각한 경고 신호로 받아들여야 합니다.

coupang_authkey

1. 사건 개요

🧩 정상 로그인 없이 3,370만 계정 정보 유출

  • 정부 발표: 공격자는 쿠팡 내부 인증에 사용되던 JWT 서명키(signing key)를 이용하여
    “정상 로그인 절차 없이도” 서버가 신뢰하는 JWT 토큰을 직접 생성한 것으로 파악됩니다.
  • 이 토큰을 대량 발급한 뒤 순차적으로 API를 호출해
    이름·전화번호·주소·이메일·주문 정보 등 개인정보를 유출한 것으로 조사되었습니다.
  • 초기에는 “4,500개 계정 노출”이라고 발표했으나,
    이후 실제 피해가 3,370만 계정 유출임이 확인되었습니다.
  • 일부 배송지 메모에는 공동현관 비밀번호까지 포함되어 있어,
    주거 침입·택배 사칭 등 2차 범죄로 이어질 수 있는 위험도 지적되었습니다.

🧩 악성코드 흔적 없음 → 키 유출·내부 지식 악용 중심 사고

  • 서버 내부에서 악성코드나 웹셸은 발견되지 않았습니다.
  • 이번 공격은 “취약점 스캔 → 악성코드 설치”와 같은 전통적 침투가 아니라,
    내부 지식 및 JWT 서명키 유출을 기반으로 한 외부 API 남용 공격에 가깝습니다.

2. 공격에 사용된 핵심 취약점

🔐 JWT 서명키 유출: 인증 체계가 그대로 붕괴

JWT 서명키는 “서버가 발급한 토큰인지 확인하는 비밀키”입니다.
이 키가 유출되면 공격자는:

  1. 임의의 계정(sub)에 대한 토큰을 마음대로 생성할 수 있고,
  2. 만료 시간(exp)을 임의로 늘리거나 조작할 수 있으며,
  3. 권한(role)이나 스코프 정보까지 조작할 수 있으며,
  4. 로그인 서버·인증 서버를 완전히 우회하여 곧바로 API 서버를 호출할 수 있습니다.

결국, JWT 서명키 유출 = 인증 시스템 붕괴에 가깝습니다.
서명키를 회수·교체하지 않는 한, 공격자는 반영구적으로 “합법 사용자인 척” 시스템을 악용할 수 있습니다.

🚨 퇴사자 계정과 연동된 서명키가 폐기되지 않음

  • 언론 보도에 따르면 관련 서명키는
    쿠팡 인증 시스템 담당자(중국 국적 전직원)와 연동된 것으로 추정됩니다.
  • 퇴사 이후에도 이 키가 갱신·폐기되지 않은 채 서비스에 남아 있었던 정황이 제기되었습니다.
  • 공격자는 해외 VPS에서 이 키를 이용해 쿠팡이 발급한 것처럼 보이는 JWT를 무제한 생성하며 API를 호출할 수 있는 상태였습니다.

3. 공격 흐름 분석

🧭 공격 시나리오(가설)

3.1 JWT 서명키 유출 또는 사전 지식 획득

  • 인증 담당자로 근무했던 전직원은
    • JWT 서명키 자체 또는
    • 해당 키를 재구성할 수 있는 환경·설계 정보에 접근할 수 있는 위치에 있었습니다.
  • 퇴사 전·후 과정에서 이 정보가 유출되었고,
    퇴사 이후에도 키가 교체·폐기되지 않아 공격 가능 상태가 유지되었다고 볼 수 있습니다.

3.2 해외 VPS에서 JWT 위조 토큰 생성

  • 공격자는 해외 VPS 여러 대를 준비한 뒤,
  • 유출된 서명키를 이용해 쿠팡 서버가 신뢰하는 형식의 JWT를 대량 생성합니다.
    • Header: 쿠팡 서비스에서 사용하는 알고리즘(예: HS256)과 동일
    • Payload:
      • sub: 내부 사용자 ID (1, 2, 3, …)
      • exp: 충분히 긴 만료 시간
    • Signature: 유출된 서명키를 사용해 생성

3.3 사용자 ID가 정수 기반(1,2,3…)이었다는 점이 큰 취약점

  • 쿠팡의 사용자 ID가 난수형 UUID가 아닌 정수 기반 식별자였다는 점이 지적되고 있습니다.

  • 이 경우 공격자는:

    • sub = 1 토큰 → 사용자 1 데이터,
    • sub = 2 토큰 → 사용자 2 데이터,
    • … 와 같이 정수를 1씩 증가시키며 전체 고객을 순회할 수 있게 됩니다.

  • 결과적으로,

    “JWT 서명키 = 만능 도장”
    “정수 ID = 누구를 찍을지만 정하면 되는 번호표”

    가 되어, 수천만 계정을 대상으로 한 전수 조회 공격이 가능해졌습니다.

3.4 5개월 동안 탐지되지 않은 이유

  • 모든 호출이 HTTP 200 OK 정상 응답이었고,
  • JWT 서명도 완전히 정상 → WAF·API 서버에서 “위조 토큰”으로 구분 불가,
  • 해외 IP라 하더라도 속도를 조절하면,
    “트래픽이 조금 많은 정상이용자”처럼 보일 수 있습니다.
  • 가장 큰 문제는:

    “요청과 응답 본문에 어떤 데이터가 오고 갔는지”를
    어느 시스템도 제대로 관제하지 않았다는 점    입니다.

4. “왜 5개월 동안 몰랐는가?” — 구조적 보안 실패

❌ 4.1 JWT 서명키 관리 실패

  • 퇴사자와 연관된 서명키를 즉시 폐기 or 교체하지 않음.
  • 서명키 하나가 전체 인증 체계의 단일 실패 지점(SPOF)이 됨.

❌ 4.2 사용자 ID 설계 취약

  • 정수 기반 식별자 사용으로,
    공격자가 1,2,3… 순서대로 사용자 정보를 조회하기 매우 쉬운 구조.
  • 최소한 외부 노출 영역에서는 난수형 ID·토큰 사용이 필요했으나, 이 부분이 미흡했습니다.

❌ 4.3 대량 조회 이상행위 탐지 부재

  • “해외 IP + 반복 호출 + 특정 민감 API + 응답 크기 증가”
    이 조합을 하나의 시나리오로 탐지하는 체계가 없었습니다.
  • 단순한 “분당 호출 수” 기준으로만 보면
    속도 조절이 들어간 공격을 실시간 탐지하기 어렵습니다.

❌ 4.4 요청/응답 본문 기반 데이터 유출 관제 부재

핵심 문제

  • 응답 본문에 포함된 이름·전화번호·주소·이메일·주문내역·공동현관 비밀번호 등
    정황상 개인정보 덩어리로 보이는 패턴을
    아무도 “유출 징후”로 보지 않았다는 점입니다.

요청/응답 본문을 보지 않는 한,
“정상 200 응답”과 “대량 데이터 덤프 응답”을
기계적으로 구분할 방법이 없습니다.

5. PLURA-XDR / WAF 관점: 무엇을 막을 수 있었는가?

PLURA-XDR과 PLURA-WAF는 JWT 서명키 유출 사실 자체를 직접 알아내기는 어렵지만,
그 결과로 나타나는 “행위 패턴”과 “데이터 유출 패턴”을 감지할 수 있습니다.

🔍 5.1 JWT 클레임 기반 이상행위 탐지

  • JWT를 디코딩하여 sub, exp, iss, aud 등의 클레임을 분석:
    • 짧은 시간 동안 sub가 1,2,3… 순차 증가
    • 비정상적으로 먼 미래의 exp,
    • 정책 상 존재할 수 없는 권한 조합

이런 특징을 “이상 JWT 사용 패턴”으로 탐지할 수 있습니다.

📦 5.2 요청/응답 본문 결합

  • 요청:
    • 특정 민감 API (/user/profile, /orders, /address)에 대한 반복 호출
  • 응답:
    • 이름·전화번호·주소·주문내역·공동현관 비밀번호 등이
      일정 형식으로 반복되는 응답,
    • 응답 크기 및 레코드 수 증가

이 두 가지를 조합하면:

“JWT sub를 순차 변경하면서,
개인정보 밀도가 높은 응답을 대량 수집하는 패턴”

을 데이터 유출 시나리오로 인식할 수 있습니다.

📊 5.3 시나리오 기반 대량 조회 인시던트 구성

PLURA-XDR 시나리오 예:

  • 조건 예시:
    • 조건 1: 해외 IP / VPS 패턴
    • 조건 2: 일정 기간 내 동일 IP에서 수만~수십만 건 API 호출
    • 조건 3: JWT sub 다양성 급증 (다수 계정 대상으로 사용)
    • 조건 4: 응답 본문 내 개인정보 필드 반복 + 응답 크기 증가

→ 이 네 가지를 충족하는 흐름을
“데이터 유출 인시던트”로 자동 묶어 경보·차단할 수 있습니다.

🛑 5.4 PLURA-WAF 자동 차단 시나리오

가능한 조치:

  • JWT 클레임 기반 WAF 룰:
    • 정책 범위를 넘는 exp 값,
    • 짧은 시간 동안 sub가 연속 증가할 때 경보/차단
  • 응답 본문 기반 WAF 룰:
    • 특정 패턴(이름/전화번호/주소 필드 조합)이
      “대량 반복”될 때 데이터 유출로 판단
  • 자동화된 대응:
    • IP/토큰 단위 차단,
    • Shadow 모드에서 먼저 기록 후 차단 정책 전환,
    • PLURA-XDR와 연계해 인시던트 단위 조사 수행

6. 위협 인사이트: “키 하나로 플랫폼 전체가 털릴 수 있다”

이번 쿠팡 사건이 보여주는 핵심 교훈은 다음과 같습니다.

  1. 내부 지식 및 키 유출이 야기하는 외부 공격의 심각성
    • 전형적인 악성코드/취약점 공격이 아니더라도,
      서명키·내부 설계 정보가 유출되면
      외부에서 “합법 인증 토큰”을 만들 수 있습니다.
  2. 인증 체계와 데이터 사용 관제의 결합이 필수
    • 인증 로그만 보는 것으로는 부족합니다.
    • “어떤 데이터가 실제로 응답으로 나갔는지”를 봐야 합니다.
  3. 내부자·퇴사자 위협 모델링 필요
    • 키·계정·권한 회수 프로세스 없이,
      외부 방화벽/IPS만 강화해도 소용이 없습니다.
  4. 플랫폼 규모가 클수록 “단일 키 실패”의 피해가 기하급수적으로 증가
    • JWT 서명키 하나가
      3,370만 계정 전체 유출로 직결될 수 있음을 보여줍니다.

📚 참고하기

Tags