1. 사건 개요
1.1 Capital One Data Breach 소개
Capital One 데이터 유출 사건은 2019년에 발생한 대표적인 클라우드 환경 침해 사고로, Amazon Web Services(AWS)에 구축된 인프라의 취약점을 악용하여 대규모 고객 정보가 유출된 사건이다.
공격자는 웹 애플리케이션의 Server-Side Request Forgery (SSRF) 취약점을 이용하여 클라우드 내부에 존재하는 Instance Metadata Service (IMDS)에 접근했고, 이를 통해 EC2 인스턴스에 부여된 IAM Role의 임시 자격 증명(temporary credentials)을 탈취했고 이 자격 증명을 이용해 공격자는 Amazon S3에 저장된 대규모 고객 데이터를 다운로드할 수 있었다. 당시 수억명에 달하는 규모의 고객 정보가 유출된 굉장히 큰 침해 사고 사례에 해당한다.
이 사건 이후 AWS에서는 IMDSv2를 권장하고 보안 기능을 강화하였다.
1.2 사건 발생 시점과 규모
이 사건은 2019년 3월부터 2019년 7월 사이에 공격이 진행된 것으로 알려져 있으며, 2019년 7월 29일 Capital One이 공식적으로 데이터 유출 사실을 공개하였다.
유출 규모:
- 약 1억 명 이상의 미국 고객
- 약 600만 명 이상의 캐나다 고객
이는 당시 기준으로 미국 금융권에서 발생한 가장 큰 규모의 데이터 유출 사건 중 하나로 평가되었다.
1.3 유출된 데이터 종류
개인 식별 정보 (PII), 금융 관련 정보 및 기타 민감 정보가 유출되었다. 특히 약 14만 명의 미국 고객과 약 100만 명의 캐나다 고객의 Social Security Number(SSN) 또는 유사한 국가 식별번호가 포함된 것으로 알려졌다.
1.4 사건이 클라우드 보안에서 중요한 이유
이 사례에서 주목할 만한 점은 아래와 같다.
- 웹 취약점이 클라우드 권한 탈취로 이어질 수 있음을 보여준 예시
- IAM 권한 최소화(Least Privilege)의 중요성
- IMDS 보안 문제
- 클라우드 공유 책임 모델을 정확히 알아야 한다는 교훈(?)
2. 공격자가 이용한 취약점
이 사건은 ModSecurity 방화벽이 설치된 EC2의 과권한 및 SSRF 취약점을 통해 발생했다.
이제 각 요소들에 대해 조금 더 자세히 알아보려고 한다.
2.1 SSRF(Server-Side Request Forgery) 취약점
- 공격자가 요청을 조작
- 취약한 서버가 요청을 처리
- 서버가 공격자의 요청을 대신 실행
SSRF는 공격자가 서버가 내부적으로 수행하는 HTTP 요청을 조작하여 의도하지 않은 시스템이나 내부 네트워크에 접근하도록 만드는 취약점이다.
예를 들어 웹 애플리케이션은 일반적으로 외부 URL을 입력받아 데이터를 가져오는 기능을 제공하는 경우가 많은데, 이미지 URL을 입력하면 서버가 해당 URL에서 이미지를 다운로드하는 기능이 있을 수 있다.
이때 입력값 검증이 제대로 이루어지지 않으면 공격자는 서버가 요청해야 할 대상 URL을 조작하여 내부 네트워크나 민감한 시스템으로 요청을 보내도록 만들 수 있다.
이 취약점이 Capital One 사례에서 어떻게 발생했는지는 위 이미지에서 더 자세히 확인할 수 있다.
2.2 AWS Metadata Service 악용
IMDS는 Instance Metadata Service의 약자로, EC2가 자신에 대한 메타데이터 정보를 조회할 수 있도록 제공되는 서비스다. AWS에서는 EC2 인스턴스 내부에서 특정 주소(169.254.169.254)로 HTTP 요청을 보내면 인스턴스와 관련된 다양한 정보를 확인할 수 있다.
조회할 수 있는 메타데이터 정보:
- 인스턴스 ID
- 인스턴스 타입
- 리전 및 가용 영역
- 네트워크 정보 (IP 주소 등)
- IAM Role 자격 증명(temporary credentials)
그러니까 해당 인스턴스가 가진 여러 정보에 대해 요청하면 이를 IMDS에서 응답해준다. 이건 인스턴스의 정보를 자동으로 확인할 수 있다(여러 인스턴스의 정보를 일일히 확인하거나 수정할 필요 없이, IMDS를 사용해 관리 가능). 더불어 클라우드에서는 사용자가 직접 인스턴스를 생성하지 않아도 생성/삭제되는(asg처럼) 일이 빈번하기 때문에, 보안이나 운영 측면에서 중요한 역할을 한다.
더 자세한 내용은 '인스턴스 메타데이터 서비스를 사용하여 인스턴스 메타데이터에 액세스' 문서를 참고하자
3. 결론
- 웹 애플리케이션의 취약점이 단순 서버를 넘어 다른 리소스로 영향을 미칠 수 있다는 점
- 최소 권한을 부여하는 것의 중요성
이 케이스의 경우 우선은 취약한 웹 방화벽 서버에서 ssrf가 일어나지 않도록 조치하는 것이 중요했을 것 같다.
또한 당시의 IMDSv1의 경우 http 요청만으로도 메타데이터를 조회할 수 있었으므로, 이 방식의 취약성에도 영향을 많이 받았을 것이다. 따라서 IMDSv2를 사용해, 세션을 통해 조회할 수 있도록 해야 한다.
무엇보다 EC2 자체에 S3를 읽고 sync할 수 있는 권한이 부여되지 않았어야 한다. 이는 PoLP를 지키지 못한 데다, 과권한 + 오권한의 조합이라고 생각한다(도대체 WAF가 왜 고객의 정보를 가지고 있는 S3를 읽는 권한을 가지고 있어야 할까? - 하지만 WAF가 권한 부족으로 동작하지 못하면 서비스가 막힐 수 있기 때문에..)
참고 자료
