SSRF와 Cloud Metadata -2

관련 이전 글 : SSRF와 Cloud Metadata -1

 

'Capital One'에서의 SSRF Cloud Metadata leak을 간단하게 설명했었다.

이와 유사한 취약한 환경을 구축하고 탈취 시나리오를 간단하게 살펴보자

 

취약환경 구축

인스턴스를 생성 후 SSRF에 취약한 Application을 올린 후, S3 bucket에 대해 full_access 권한을 갖는 IAM role을 만들고 이 인스턴스에 연결해준다.

민감정보를 담을 S3 bucket을 생성하고 object를 넣어준다. (해당 bucket은 인터넷 open하지 않음)

 

정말 간단하게 취약환경을 구성해 보았다.

'Capital One'의 Exploit과 동일하게 SSRF로 Metadata를 탈취해 S3 bucket의 object까지 탈취해본다.

 

CVE-2021-21311

SSRF계열의 취약점으로 이전에 해당 취약점에 대해 작성한 내용이 존재한다.

CVE-2021-21311 [adminer]

 

Exploit 로직 자체는 위 글과 동일하게 가져간다.

다만 여기서 Victim이 AWS 인스턴스라는 가정 하에, 임의의 host로 넘겨주는 부분에서 앞서 나왔던 AWS Metadata service 서버로 넘겨준다. 아래는 인스턴스 id를 확인하는 모습을 나타낸 것

해당 결과로 Victim이 AWS Cloud service임을 확인했다.

즉, Attacker 서버로 Victim의 Request가 전송되어 EC2 Metadata Server(169.254.169.254)로 Redirect되는 것을 확인한 것이다.

 

 

해당 인스턴스에 연결된 IAM Role의 이름을 확인

 

해당 인스턴스에 연결된 IAM Role의 Credential 확인

 

이렇게 인스턴스에 연결된 IAM Role Credential을 탈취했다. 다음으로 탈취한 IAM Role의 권한을 확인한다.

 

aws-cli에 credential을 설정하고 권한 확인 중 S3에 대한 Access가 가능한 것을 확인했다.

해당 bucket의 내부 확인과 object 다운로드까지 진행가능함을 확인

 

 

Mitigation 

- EC2 내에 Metadata를 사용중인 프로세스가 없는 경우, 인스턴스 메타데이터에 대한 액세스를 차단
- 인스턴스 메타데이터에 대한 접근이 필요한 경우, IMDSv1 비활성화 (IMDSv2만 이용) 
- 3rd party Application을 사용하는 경우, 지속적인 최신 버전 확인 및 업데이트