RDS_snapshot(Medium) Write up

---

시나리오를 생성하면 EC2 IP주소와 EC2에 SSH로 붙을 수 있는 ssh_command 명령어를 준다.

---

1. EC2 IP 분석

웹을 접속 해보면 Time out이 발생한다.

즉, 보안그룹에 로컬 호스트 IP주소의 인바운드가 허용되어 있지 않다는 것을 알 수 있다.

---

2. ssh_command 분석

ssh_command 명령어를 사용해 직접 EC2에 붙어보자.

※주의!!
Cloudgoat를 pipx를 이용해 다운 받았다면 pem키가 ~/.local/lib/{python버전}/site-packages/cloudgoat/{rds_snapshot_랜덤값}/cloudgoat 경로에 존재한다.

로컬 호스트에서 ssh는 접속이 가능하다.

권한을 확인해보면 root 권한으로 접근이 가능하다.

EC2 권한 확인을 위해 aws cli를 먼저 설치해주자.

메타 데이터에 접근해봤지만 역시 접근이 불가능하다.

---

3. 유저 및 정책 확인

aws sts get-caller-identity 명령어를 이용해 유저 정보를 확인해보자.

※export roleName=cg-ec2-admin-role

다음으로 해당 Role에 할당된 정책을 확인해보자.

Inline 정책 cg-ec2-admin-policy 하나만 존재하는 것을 확인 가능하다.

※export policyName=cg-ec2-admin-policy

cg-ec2-admin-policy 정책 확인 결과 S3에 대한 모든 권한과 Iam 조회 권한이 존재하는 것을 알 수 있다.

---

4. S3 분석

S3 전체 권한을 이용해 S3 버킷 종류를 조회하고 해당 버킷 내부를 확인해보니 access_keys.txt라는 문서가 존재하는 것을 확인할 수 있다.

access_keys.txt 파일 내용을 확인해보면 Access key와 Secret key 가 존재한다.

---

5. 탈취한 유저 정책 및 권한 확인

S3에서 탈취한 키를 이용해 rds라는 이름의 profile을 생성했다.

1. aws sts get-caller-identity --profile rds 명령어로 해당 유저의 정보를 확인했다.

※export userName=cg-rds-instance-user-cgidqon4lohlpv

2. 그룹 확인

3. Managed Policy 확인

4. Inline Policy 확인

※ export userPolicyName=cg-david-policy

5. 확인 결과, cg-david-policy라는 정책만 존재

6. 해당 정책의 권한 확인 결과 rds DB 인스턴스 및 스냅샷 describe 권한, rds 리소스 태그 생성 권한, DB 스냅샷 복구 권한, DB 인스턴스 수정 권한 및 Iam 조회 권한이 존재

---

6. Role 확인

1. aws iam list-roles --profile rds 명령어로 role 확인 시, 기존에 확인했던 cg-ec2-admin-role 외에 다른 role은 無

---

위 권한 확인 과정을 pacu 및 cloudfox로 진행해보자

1. pacu를 이용해 run iam__enum_bruteforce_permissions 명령어 사용 시, 아래와 같은 권한들을 찾아 줬지만 위에서 확인한 결과 값들과 차이가 존재

2. cloudfox를 이용해 all-checks 실행 시, rds 관련 권한을 확인 가능

---

7. RDS 및 Snapshot 분석

rds 프로필이 가진 rds 권한들을 이용해 rds db instance 및 snapshot을 분석해보자.

1. aws rds describe-db-instances --profile rds 명령어를 이용해 기존의 DB 인스턴스 정보 조회(일부만 캡쳐)

2. aws rds describe-db-snapshots --profile rds 명령어를 이용해 DB Snapshot 정보 조회(일부만 캡쳐)

3. cg-rds 의 Snapshot 이라는 것 확인 가능

4. rds profile의 RestoreDBInstanceFromDBSnapshot 권한을 이용해 해당 DB를 복구해 공격자가 조작 가능할 것으로 추정

5. aws rds restore-db-instance-from-db-snapshot --db-instance-identifier {생성할 DB Identifier} --db-snapshot-identifier cg-rds-snapshot --db-subnet-group-name {기존 DB 서브넷 그룹} --vpc-secur
ity-group-ids {기존 DB 보안그룹 ID} --profile rds 명령어를 이용해 Snapshot 복구

6. aws rds describe-db-instances --profile rds --query "DBInstances[].DBInstanceStatus" 명령어 출력 값이 available 이면 생성 완료

생성중

생성 완료

7. 해당 DB에 접근하기 위해선 UserName(cgadmin)외에 Password가 필요

8. rds profile 의 ModifyDBInstance 권한을 활용해 restoreddb의 비밀번호 변경 가능

9. 기존에 접속했던 ubuntu ec2에서 restoreddb 접근 가능

10. DB 내의 FLAG 확인 가능

---

★별첨★ 8. 기존 RDS 분석

기존에 존재하던 rds db도 분석해보자.

1. aws rds describe-db-instances --profile rds 명령어를 이용해 기존의 db 인스턴스 정보 조회

2. PubliclyAccessible 값이 False 이므로 로컬 호스트에서는 해당 DB로 접근이 불가능. 하지만 접근 가능한 EC2가 존재하기 때문에 해당 EC2에서 접근 가능할 것으로 추정(EC2에 대한 권한이 없으므로 직접 확인은 불가)

3. rds profile 의 ModifyDBInstance 권한을 활용해 cg-rds DB의 비밀번호 변경 가능

4. 기존 EC2에서 cg-rds DB 접근 가능

5. DB 접근 및 FLAG 탈취

6. Snapshot을 이용해 풀어야하는 문제인데 왜 기존 DB 접근이 가능한지 모르겠다...

---

추가 분석

EC2 및 RDS VPC 분석(8.2번 추가 분석)

1. EC2 VPC

2. DB VPC

3. 동일한 VPC인 것 확인 가능