저희는 실제 공개 사고를 단순한 뉴스 재방송이 아니라 "이것을 어떻게 방어할 것인가"의 관점으로 읽습니다. 이 글은 공개 기록(규제 기관, 보도, 학술 분석, 공식 발표)에 근거하며, 출처는 글 끝에 명시합니다.
- 대상
- Capital One(미국 주요 은행)
- 공개
- 2019년 7월 29일(7월 19일 탐지 / 3월 침입)
- 분류
- SSRF로 시작된 클라우드 자격 증명 탈취 및 데이터 유출
- 규모
- 미국/캐나다 약 1억 600만 명(SSN 약 14만 건, 연동된 은행 계좌번호 약 8만 건 포함)
- 근본 원인
- SSRF 결함 + 보호되지 않은 메타데이터 엔드포인트 + 과도한 권한의 IAM 역할
- 주요 대책
- 심층 방어: 목적지 허용 목록, IMDSv2, IAM 최소 권한
무슨 일이 있었나(쉽게 풀이)
Capital One은 신청 처리의 일부를 클라우드에서 운영하고 있었습니다. 그 앞단에 있던 구성 요소(리버스 프록시 / WAF로 동작)에 SSRF 결함이 있었습니다. 즉 외부에서 지정한 목적지로 서버를 대신해 요청을 보내도록 만들 수 있었습니다.
클라우드 VM에는 내부에서만 도달할 수 있는 특별한 메타데이터 엔드포인트가 있는데, 이 엔드포인트는 해당 머신에 부여된 임시 자격 증명을 반환합니다. 공격자는 SSRF를 이용해 이 내부 엔드포인트에 도달해 키를 획득했습니다. 그 뒤에 있던 IAM 역할(공개 기록에서 ISRM-WAF-Role로 보고됨)은 스토리지를 광범위하게 읽을 수 있는 권한을 갖고 있었기 때문에, 약 700개 스토리지 버킷(S3)의 내용이 그대로 복사되어 빠져나갔습니다.
SSRF가 있으면 '내부에서만 도달 가능'한 엔드포인트에도 외부에서 도달할 수 있다
메타데이터 엔드포인트는 "외부에서 도달 불가능"이라는 전제로 보호되고 있었습니다. 그러나 SSRF는 서버 자신이 그 접근을 대리하게 만들어 그 전제를 무너뜨립니다. "내부 전용이므로 안전하다"는 가정은 SSRF 결함 하나만 있어도 성립하지 않습니다.
공격의 각 단계와 막는 방법
중요한 것은 이것이 4단계의 연쇄였고 각 단계마다 멈출 수 있는 지점이 있었다는 점입니다. 공격 레시피가 아니라 "어디서 멈출 수 있었는가"로 읽어 주십시오.
① 출발점: SSRF
결함으로 인해 서버가 임의의 목적지로 요청을 대리한다.
⊘ 멈춤: 목적지 허용 목록
② 내부 메타데이터 엔드포인트에 도달
"내부 전용" 엔드포인트가 SSRF를 통해 도달 가능해진다.
⊘ 멈춤: IMDSv2(토큰 필수 + 홉 제한)
③ IAM 임시 자격 증명 획득
머신의 역할이 임시 키를 반환한다.
⊘ 멈춤: 최소 권한 역할(스토리지 전체 읽기 금지)
④ 스토리지(S3) 일괄 복사
약 700개 버킷이 그대로 복사되어 빠져나간다.
⊘ 멈춤: 이그레스 제어 + 비정상 조회 탐지
공개된 타임라인
2019-03
클라우드 환경에 대한 무단 접근(이후에 확정됨).2019-07-17
외부 제보(GitHub 게시물)가 이상을 알린다.2019-07-19
Capital One이 내부 조사로 유출을 확인.2019-07-29
공개 발표. 전직 AWS 엔지니어가 FBI에 체포됨.2019-11
AWS가 SSRF에 대한 심층 방어책으로 IMDSv2를 발표.2020-08
OCC가 클라우드 이전 전 위험 평가가 미흡했다는 점을 들어 약 8천만 달러의 과징금 부과.
근본 원인: 여러 방어가 동시에 빠져 있었다
이를 "SSRF" 하나로 치부하면 반복됩니다. 실제로는 세 계층이 순서대로 무너졌습니다.
당시의 상태
- 진입점에서 목적지 검증이 없음(임의의 요청 대리가 가능)
- 메타데이터 엔드포인트가 토큰 없이 키를 반환(레거시 모드)
- 머신의 IAM 역할이 스토리지를 광범위하게 읽을 수 있음(과도한 권한)
마땅히 그래야 할 상태(예방)
- 목적지를 허용 목록으로 제한하고 내부 주소로의 대리 접근을 거부
- 메타데이터는 IMDSv2로: 세션 토큰 필수 + 홉 제한이 대리 도달을 차단
- IAM 역할은 최소 권한으로: 실제로 필요한 버킷과 동작만 허용
책임 공유 모델: 클라우드 고객이 지켜야 하는 것
클라우드 제공자는 기반을 보호하지만, SSRF를 고치고, IAM 권한을 설계하고, 메타데이터를 보호하는 것은 고객의 책임입니다. 과징금 자체도 "클라우드 이전 전 위험 평가 미흡"을 지적했습니다. 클라우드를 쓰는 것이 문제가 아니라, 자신이 책임지는 부분을 충분히 설계했는지가 중요합니다.
여러분의 환경에서 막는 법
규모에 상관없이 작동하는, 우선순위 순서의 대책입니다. "URL을 받아서 가져온다"거나 "웹훅/이미지를 전달한다"는 기능이 하나라도 있다면 이것은 여러분의 이야기입니다.
아웃바운드 목적지를 허용 목록으로(첫 단계에서 SSRF 차단)
서버가 사용자가 제공한 URL로 접근을 대리하는 곳에서는 허용된 목적지로만 제한하십시오. 내부 주소(메타데이터 엔드포인트, 사설 네트워크)로의 도달은 기본적으로 거부합니다. SSRF 용어 설명에서 사람들이 놓치기 쉬운 검증의 함정(리다이렉트 추종, DNS 리바인딩)을 다룹니다.
메타데이터에 IMDSv2 강제
클라우드 메타데이터 엔드포인트를 토큰 필수, 홉 제한 모드(AWS의 IMDSv2)로 제한하십시오. 이것만으로도 SSRF를 통한 자격 증명 탈취가 훨씬 어려워집니다. 핵심은 레거시 모드를 비활성화하는 것입니다.
IAM 최소 권한(피해 범위 제한)
키가 유출되더라도 피해가 제한되도록, 머신/서비스의 권한을 필요한 대상과 동작으로만 한정하십시오. "그냥 스토리지 전체 허용"은 하나의 유출을 전면적인 유출로 만듭니다.
이그레스 및 이상 탐지
아웃바운드 트래픽을 필요한 목적지로 제한하고 대량 조회의 급증 같은 이상을 탐지하십시오. 첫 단계를 막지 못하더라도 유출을 알아채는 계층을 남겨 둡니다.
본 사이트의 설계와 겹치는 지점
본 사이트는 URL을 다루는 기능을 검증된 도메인으로만 설계합니다(설계상 SSRF에 안전). 이 사고는 저희가 기반으로 삼는 원칙이 왜 필요한지를 분명히 보여 줍니다: 입력을 검증하고, 최소 권한을 적용하며, "내부"라서 안전하다고 가정하지 않는다. 편리한 클라우드를 쓰더라도, 자신이 책임지는 부분은 스스로 설계해야 합니다.
출처(공개 기록)
여기 담긴 사실은 다음 공개 정보에 근거합니다. 저희는 재현 절차나 페이로드를 다루지 않으며, 방어적 교훈만 다룹니다.
- Krebs on Security, "What We Can Learn from the Capital One Hack" (2019) — krebsonsecurity.com
- ACM Transactions on Privacy and Security, "A Systematic Analysis of the Capital One Data Breach" — dl.acm.org
- CyberScoop, "US financial regulator fines Capital One $80 million over data breach" (2020) — cyberscoop.com
이어서 읽기
- 용어: SSRF란 무엇인가(이 사고의 출발점. 검증의 함정 포함)
- 사고: 방치된 CVSS 10.0에 당하다
- 방어: 최소 권한과 머신 모니터링을 운영에 녹여 넣기