📺쿠팡 등 API 인증 키(JWT) 유출 사고, '행위 기반' 탐지로 방어하는 방법 (모의해킹 영상 포함)

2025년 6월 24일부터 약 5개월간, 쿠팡은 정상 로그인 절차 없이도 고객 정보를 조회할 수 있는 인증 취약점을 공격자에게 노출한 채 운영했습니다.

정부 조사와 언론 보도를 종합하면, 사건의 근본 원인은 JWT 서명키 관리 실패 + 내부자(퇴사자)의 지식 악용 가능성으로 좁혀지고 있습니다.

이번 사건은 “내부 지식 및 키 유출이 결합된 외부 공격”이 얼마나 치명적인 결과를 초래할 수 있는지를 보여주는 대표 사례입니다.

특히 국내 대규모 플랫폼 서비스가 요청/응답 본문 기반 관제 부재로 인해, 장기간 진행된 대규모 데이터 유출을 전혀 감지하지 못했다는 점에서 심각한 경고 신호로 받아들여야 합니다.

---

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 : 유출된 키, ‘행위’로 막을 수 있습니다.

PLURA-XDR과 PLURA-WAF는 키 유출 사실 자체를 즉시 알 수는 없더라도, 그 결과로 나타나는 “비정상적인 데이터 접근 행위“를 실시간으로 탐지하고 차단할 수 있습니다.

우리는 언제나 외부의 공격만을 경계하지만, 보안 담당자라면 반드시 아래 두 가지 ‘최악의 시나리오‘에 답할 수 있어야 합니다.

1. “내부 개발자가 악심을 품고 JWT 마스터 키를 가지고 퇴사하여 공격자로 돌변한다면?”
2. “개발자의 실수로 마스터 키가 반출되고, 이를 습득한 해커가 공격해 온다면?”

이 경우 공격자는 ‘정상적인 인증 권한(Master Key)‘을 가지고 들어옵니다. 기존의 방화벽이나 인증 시스템은 이들을 ‘합법적인 관리자’로 인식하기 때문에 속수무책으로 뚫릴 수밖에 없습니다.

이러한 가능성은 늘 상존합니다. 따라서 우리는 ‘누가(Who)’ 들어왔느냐를 넘어, 그들이 ‘무엇을(Behavior)’ 하고 있는지를 감시하는 대응 체계를 구축해야 합니다.

백문이 불여일견, ‘합법적 권한’을 가진 공격자를 PLURA가 어떻게 막아내는지 실제 시연 영상을 확인해 보겠습니다.

🎥 [영상 시연] 유출된 JWT를 이용한 대량 조회 공격 방어

공격자가 탈취한 인증 토큰(JWT)을 이용해 정상 사용자로 위장하고, 짧은 시간 동안 대량의 API 요청을 보내는 상황입니다.

• 📺 탈취된 JWT 토큰의 역습, 3천만 계정은 어떻게 털렸나? | PLURA의 API 브루트포스 탐지 시연

[영상 요약]

1. 공격 발생: 공격자가 탈취한 JWT로 인증을 통과한 후, 스크립트를 이용해 수삽에서 수백 번의 API 요청을 전송합니다. (F12 네트워크 탭 확인)
2. PLURA 탐지: PLURA-XDR은 단일 IP 또는 토큰에서 발생하는 과도한 트래픽을 감지하여 ’[Brute Force] API 과요청’ 로그를 생성합니다.
3. 즉시 차단: 미리 설정된 임계치(예: 10초 20회)를 초과하자마자 즉시 차단(Block)하여 대규모 데이터 유출을 막아냅니다.

핵심 포인트: 왜 일반 방화벽은 못 막을까?

일반적인 보안 장비는 “키가 유효한가?“에 집중합니다. 공격자가 훔친 키도 기술적으로는 ‘유효한 서명‘을 갖고 있기 때문에 정상 사용자로 오인하고 통과시킵니다.

하지만 PLURA-XDR은 인증을 넘어 “인증된 사용자가 동일 IP주소에서 왜 수십 수백번이나 조회를 시도하는가?“라는 행위의 맥락(Context)을 분석합니다. 이것이 바로 키 유출 사고가 발생해도 데이터를 안전하게 지킬 수 있는 핵심 이유입니다.

---

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

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

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

---

📚 참고하기

• AI 보조 WAF 우회: 공격 자동화 시나리오
• Gartner 하이프 사이클로 본 SIEM과 SOAR – 왜 둘 다 한계가 있는가?
• 우리나라 해킹은 정부의 인증 제도 때문이다
• ISMS 인증제도, 왜 지금은 더 이상 유효하지 않은가?
• 롯데카드 해킹 사고 분석 - 왜 웹방화벽은 무용지물이 되었을까
• SKT 해킹 가설: 유심 데이터 탈취와 BPFDoor 설치, 어떻게 이뤄졌나?