SSRF
Server Side Request Forgery의 약자로, 직역하면 서버측 요청 위조
서버 측에서 위조된 요청을 발생시켜 직접적인 접근이 제한된 내부 서버의 자원 등에 간접적으로 접근해 데이터 유출 및 오동작을 유발하는 공격이다.
외부로 공개된 서버와 내부망에 존재하는 서비스(DB 등)로 이루어진 구조에서 외부서버가 내부서버로 보내는 요청을 외부 사용자가 임의로 변조하는데, 이때 내부서버는 신뢰할 수 있는 위치에서 전달된 Request로 확인하기 때문에 변조된 Request에 대한 응답값을 반환해준다.
주로 내부 서버에 저장된 이미지와 같은 자원에 접근하거나 외부로 Request를 발생시키는 구간에서 자주 발생하고, 사용자가 제공한 데이터(입력값, 쿠키 등등)을 서버 측에서 별다른 검증 로직없이 그대로 처리해주는 경우 발생한다.
자주 발생되는 취약점은 아니나, 해가 지남에 따라 발생빈도가 꾸준하게 증가하고, 파급력도 커져 2021 OWASP TOP 10의 10위에 새롭게 등재된 것을 확인할 수 있다.
Cloud Metadata
클라우드 환경에서 실행중인 서비스 객체들에 대한 키-값 쌍의 데이터 집합으로 각 퍼블릭 클라우드 서비스(CSP)별로 접근할 수 있는 별도의 URL이 지정되어 있다.
Metadata URL은 보통 169.254.169.254를 사용하며 일부 클라우드 서비스의 경우만 다른 것을 볼 수 있다.
| 클라우드 서비스 | Metadata URL |
| AWS | http://169.254.169.254/latest/meta-data/ |
| GCP | http://metadata.google.internal/computeMetadata/v1/ |
| Azure | http://169.254.169.254/metadata/ |
| Oracle | http://169.254.169.254/opc/ |
| Alibaba Cloud | http://100.100.100.200/latest/metadata |
위 표에 적힌 퍼블릭 클라우드 서비스 이외에도 다양한 서비스가 존재하나, 이번 정리에서는 AWS를 중심으로 진행하고자 한다.
AWS 인스턴스에는 각각 Instance Metadata라 하는 실행 중인 인스턴스를 구성하거나 관리하는데 사용되는 메타데이터가 존재한다. 이러한 메타데이터 관리 서비스를 통틀어 IMDS(Instance Metadata Service)라고 칭한다.
AWS EC2에서 Instance Metadata를 조회하는 URL은 169.254.169.254이며 HTTP 통신을 이용해 메타데이터를 가져온다.
curl http://169.254.169.254/latest/meta-data/단순한 GET요청을 통해 메타데이터를 가져올 수 있으며, 이를 IMDSv1 (버전 1)이라 칭한다.
해당 조회 결과는 아래와 같다.
각 엔드포인트로 접근 시 현재 인스턴스에 대한 메타데이터를 가져올 수 있다.
확인할 수 있는 메타데이터는 인스턴스 id부터 퍼블릭/프라이빗 ip, 인스턴스의 IAM Role 설정에 따라 credential 정보까지 볼 수 있다.
+) IAM Role : 클라우드 인프라 내에서 AWS 서비스에 간편하게 접근할 수 있도록 부여된 임시 보안 자격증명
기본적으로 메타데이터를 호출하는 URL은 Link-local address라는 인스턴스 내부에서만 접근가능한 주소(169.254.169.254)로 설정되어있다.
즉, 기본적으로 인스턴스 외부에서 메타데이터 정보를 열람할 수는 없는 것이다.
호출한 메타데이터는 암호화 방법으로 보호되지 않기 때문에 인스턴스에 직접 액세스할 수 있는 모든 사람은 메타데이터를 확인할 수 있다.
그리고 IMDS v1은 별도의 IAM Role 설정 없이 모든 EC2 인스턴스가 조회 가능해 현재는 IMDSv2 사용을 권장하고 있다.
인스턴스 메타데이터 서비스 버전 2 작동 방식 - Amazon Elastic Compute Cloud
토큰이 유효하지 않고, 토큰을 만드는 데 오류가 발생하면 오류 메시지가 변수에 저장되고 명령이 작동하지 않습니다.
docs.aws.amazon.com
IMDSv1의 경우 단순 요청/응답 형식을 지원하는 반면, IMDSv2는 세션 지향 요청을 이용한다.
GET 방식의 요청만으로 메타데이터 접근이 가능했던 IMDSv1의 문제점을 어느정도 완화시킨 IMDSv2는 PUT요청을 세션 토큰을 이용해 할당받고, 그 토큰을 이용해 토큰이 살아있는 시간 동안만 메타데이터 요청을 할 수 있게 한 것이다.
IMDSv2 사용 - Amazon Elastic Compute Cloud
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
토큰 생성을 PUT메소드를 통해 요청하고, 변수에 세션 토큰 헤더를 저장한 뒤에 저장한 토큰을 이용하여 메타데이터를 요청하는 방식을 통해 기존 IMDSv1의 취약한 보안성을 개선시켰다.
인스턴스를 생성할 당시, 고급 세부정보 탭에서 메타데이터에 대한 설정이 가능하며, 이 옵션들은 모두 디폴트 값으로 ‘선택’에 놓여져 있다.
메타데이터에 대한 별도의 옵션 수정이 없는 경우 IMDS v1과 v2를 모두 사용하게 된다.
SSRF를 이용해 Cloud Metadata를 탈취한 뒤 공격 벡터를 확장시킨 실제 사례를 알아보자
2019년 7월에 발생한 미국 대형은행 'Capital One'에서 고객 개인정보 1억600만 건의 유출이 발생한 사실이 언론에 공개되었다. 이후 Hacker의 개인정보 탈취까지의 Exploit이 공개되었는데, 크게 3가지 포인트로 정리가 된다.
1. WAF(웹 방화벽)에서 SSRF 공격 차단이 이루어지지 않음
2. SSRF 공격으로 인스턴스 Metadata 탈취 및 해당 인스턴스에 연결된 IAM Role Credential 탈취
3. 탈취한 Credential이 S3 버킷 object 데이터에 접근가능한 권한이라, 버킷 내부의 고객정보에 접근
다음 글에서 위 사례와 유사한 환경 구축 후 Exploit을 실습하고 Mitigation을 확인해본다.
