(Study) CloudGoat - iam privesc by rollback (1)

date

Mar 12, 2024

slug

cloudgoat-iam-privesc-rollback

author

status

Public

Index

Introduction

CloudGoat

Scenario - IAM Privsec by Rollback

Conclusion

Introduction

안녕하세요 Yureutae입니다. 오늘은 CloudClub에서 참여하고 있는 스터디 주제인 CloudGoat에 대해서 소개드리고, Small/Easy 시나리오에 속하는 iam_privesc_by_rollback 을 실습해보겠습니다.

평소 Cloud 아키텍처나 내부 서비스 개발, Security Group, ACL, IAM 세팅 정도만 진행해서 보안 사고를 방지했을 뿐, 한번도 구체적인 공격 시나리오에 대해 탐구해보지 않았었는데 이번 기회에 클라우드와 보안 분야를 엮어 시야를 넓히는 좋은 경험이 될 것 같습니다. (모르고 세팅하는 것보다는 아는게 나은..)

CloudGoat

CloudGoat란?

CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool.

예전 안랩 공격 예측 모델 개발 프로젝트를 진행할 때 관제 직원분들이 해당 모델 파이프라인에 보안 시나리오들을 모아둔 테스트 모듈을 돌려서 성능 측정을 진행했다는 얘기와, 조성영 님이 자주 포스팅하시는 MITRE ATT&CK이 기억났습니다.

보안 전공에 적을 두지 않아 fully understand는 안 되지만, 개개의 공격을 하나의 Scenario로 두고 “테스트 시스템 자체가 망가지지 않는 선”에서 Scenario를 최대한 동일하게 재현해서 분석하고 실험하는 것이 중요한 것 같습니다.

CloudGoat는 AWS 내 서비스를 활용하여 구조된 아키텍처에서 Cloud Security 관점의 Critical한 Scenario를 모아두고 Terraform과 AWS CLI로 재현할 수 있게 만든 프로젝트입니다. 많은 온프레미스 공격 Scenario에 비해 재현이 매우 쉬운게 장점인 것 같습니다. (사실상 Contribution의 대부분은 Terraform이 가져가지 않나…)

Environment Setting

💡

Docker로 묶어서 제공하길래 써봤는데, aws-cli와 Terraform, Python Docker Image 간에 뭔가 dependency 충돌이 나는 것 같습니다. local-exec 관련인데 직접 DockerFile 빌드해도 오류는 똑같이 납니다.

CloudGoat 소스코드랑 requirements.txt를 좀 들여다봤는데, 굳이 환경 격리를 하지 않아도 되는 python 기반 프로젝트입니다. pip install 굳이 안해도 기본적으로 깔려있는 라이브러리들을 베이스로 돌아갑니다.

Mac이나 Linux면 사용 계정에서 터미널 키고 바로 진행하면 됩니다 (Window는 알아서…WSL 있어야하나). 전 귀찮아서 Mac 로컬 터미널에서 바로 진행하겠습니다.

Terraform 설치 brew install terraform

aws-cli 설치

aws iam configure, credentials 편집

Mac 기준 ~/.aws/configure, credentials
다수 Context 중 CloudGoat 실습 진행할 계정의 Context로 IAM configure, credentials 입력/수정

git clone

README 따라서 세팅

./cloudgoat.py config profile

~/.aws 내 실습 진행할 계정의 context name 입력

./cloudgoat.py config whitelist —auto

실습을 명령하는 로컬 환경의 ip를 따서 whitelist에 추가합니다.

./cloudgoat.py create {scenario name}

시나리오 실행

./cloudgoat.py destroy {scenario name}

시나리오 삭제

Scenario - IAM Privesc by Rollback

💡

Starting with a highly-limited IAM user, the attacker is able to review previous IAM policy versions and restore one which allows full admin privileges, resulting in a privilege escalation exploit. Acquire full admin privileges.

생성한 User의 이전 IAM Policy 버전을 확인하고 admin 권한까지 획득하도록 변경하는게 해당 Scenario의 Goal입니다.

핸즈온 후에 해당 Scenario를 분석해보겠습니다.

Hands-On

Scenario를 생성해줍니다. iam_privesc_by_rollback 만 config로 입력해도 Terraform으로 잘 올라가는 것을 확인할 수 있습니다.

생성 직후 프로젝트 디렉토리에 새로운 디렉토리가 생긴 것을 확인할 수 있습니다. cheet_sheet은 당근 답지일 거 같으니 피합시다.

start.txt를 보면 생성한 IAM User의 정보가 나와있습니다. aws configure로 access key id, secret access key 등록하고, aws sts get-caller-identity —profile {profile name} 으로 등록 정보 확인합시다.

aws iam list-users --profile {profile name} 으로 IAM console 확인해봅시다. start.txt 대로 잘 등록됐네요

Scenario 수행단계에 따라 iam으로부터 list-attached-user-policies를 얻어봅시다.

Scenario 수행단계에 따라 policy version을 얻어봅시다. (codewhisperer가 —policy-arn이 옵션이 있다고 잘 추천해주네요. 여기서 User policyarn을 넣으면 됩니다.)

뭔지는 모르겠는데, version이 있으니까 저거 하나씩 뒤져보면 될 것 같습니다.

iam get-policy-version 결과 다음과 같은 내용이 나왔습니다. 요것도 뭔지 모르겠는데 version이 2012년에 PrivilegeEscalationByRollback이니까 대충 맞게 진행하고 있는 것 같습니다.

사실 뭔 의미인지 모르겠어서 다시 version 별로 내용 좀 보니까 Statement.Action 내용이 다 달랐습니다. v4는 와일드카드 + Effect: Allow여서 얜가 싶습니다. codewhisperer의 힘을 빌어 current iam policy를 조회해보니까 v1이 현재 policy 네요

대충 v4로 policy를 바꿔봅시다. codewhisperer가 set-default-policy-version이 있다고 하고, Scenario 실행 단계에도 있으니 iam set-default-policy-version으로 명령하면 됩니다.

실험에 사용하는 계정은 현재 과금때문에 버린 상태여서 뭐하지 하다가, 그냥 IAM User 생성하면 되지 않을까 싶었습니다. codewhisperer한테 물어보니까 아래처럼 생성하면 된다고하네요. —profile 옵션 넣고 돌리니까 성공했습니다.

혹시나 싶어서 v1으로 다시 바꿔서 create user 해보니까 안되네요. Scenario 완성입니다.

Conclusion

IAM User를 생성했을 때, policy version 관리를 잘해야한다는 교훈을 주는 Scenario인 것 같습니다.사실 aws cli 안쓰고 Web Console로 봐도 버전 잘 보이더라구요. default 버전 바꿔버리면 previlege escalation이 가능하다~를 얘기하는 것 같습니다.