(Study) CloudGoat - iam privesc by key rotation (3)

date

Apr 2, 2024

slug

cloudgoat-iam-privesc-key-rotation

author

status

Public

Index

Introduction

Scenario - Iam Privesc by Key Rotation

Conclusion

Introduction

안녕하세요 Yureutae입니다.

오늘은 iam_privesc_by_key_rotation scenario에 대해 진행해보겠습니다.

scenario size는 small이고 difficulty도 easy인데, 저는 갈수록 어려워지는 것 같습니다..;

Scenario - Iam Privesc by Key Rotation

💡

manger user부터 시작하여 admin user에게 태그를 추가합니다.

admin user에게 액세스 키를 삭제하고 새로 추가합니다.

admin user에게 MFA device 생성 및 연결하기

admin user로 전환하기

Assume secretsmanager role with MFA

Retrieve secret

(저번 scenario에서 느꼈지만, 기존 Assume 영단어의 뜻을 클라우드에선 잊어버려야겠습니다.)

Hands-On

Scenario를 생성해줍시다. start.txt에 manager 계정이 하나 나옵니다. 으레 그렇듯 aws configure에 등록해주세요

aws iam list-users 로 생성된 iam user를 봤습니다. 3개가 나오네요

user policy들의 취약점을 찾아봅시다. aws iam list-user-policies

manager 유저에게 SelfManageAccess, TagResources란 Policy가 할당되어있습니다. 하나씩 뒤져보겠습니다.

aws iam get-user-policy 결과입니다.

대충 추론해보니까, User에게 Tagging 할 수 있는 권한이 Manager에게 있고 “developer=true”인 Tag를 가진 유저에 한해서 AccessKey 및 MFA 관련 권한을 맘대로 할 수 있군요.

그럼 논리상, admin user에게 developer=true tag를 부여하고, AccessKey를 재할당한 후 해당 key로 접근하면 될 것 같습니다. 물론 assume-role에서 2차인증(MFA)가 필요할 것 같습니다.

admin user에게 tag를 해보겠습니다. aws iam tag-user --tags '{"Key":"developer","Value":"true"}'

list-user-tags 를 했을 때 잘 추가되었음을 확인했습니다.

scenario에서 access key를 재할당하라고 한 부분을 진행하겠습니다. 먼저 조회를 list-access-keys 로 수행합니다.

왜 2개가 있는지는 잘 모르겠네요… 여튼 aws iam delete-access-key --access-key-id 로 지웠습니다.

aws iam create-access-key 로 키를 생성해줍니다.

AccessKey랑 SecretAccessKey를 얻었으니 이걸로 admin에 접근할 수 있겠죠? aws configure에 추가하고 접근해봅시다.

admin user에게는 어떤 policy가 있는지 list-user-policies로 봅시다.

그럼 어떤 Role을 공략해야 할지 봐야겠네요. list roles

“Access to view secrets”라고 되어있는 Role이 하나 있네요. MFA 2차 인증 조건이 있지만 일단 AssumeRole 시켜보겠습니다.

aws sts assume-role을 해보니 접근되지 않네요

mfa 2차인증 device를 활성화 시켜보고 다시해봅시다. aws iam create-virtual-mfa-device 로 수행할 수 있습니다. —bootstrap-method 파라미터에 대해 codewhisperer가 qrcode 등을 보여주는 걸 보니 인증방법이 여러가지인 것 같습니다. 전 qrcode를 선택했습니다.

오… qr코드 이미지 나왔습니다.

이걸 admin에 할당해줘야 assume-role 수행이 가능하겠죠? 일단 qr코드를 온라인에서 스캔(https://www.online-qr-scanner.com/ko/)하고 디바이스 내부에 삽입해줬습니다.

그 google authenticator 등의 2차인증에서 주로 사용되는 n초마다 암호 초기화가 나오네요.

해당 code 2개를 가져와서 (min value 6인 걸 보니 2번 대기해야하는둣) enable-mfa-device 명령어의 --authentication-code-1, 2 파라미터에 나누어 넣어주면 되는 것 같습니다.

이제 다시 assume role 해줍시다. 다만 옵션에 mfa 관련 인증 파라미터를 다 붙여야합니다.

이제 공략한 role description에 써져있던 대로 secret을 뽑아봅시다. 윗 부분의 결과로 임시 사용가능한 AccessKey와 SecretKey, SessionToken를 발급받았으니 그걸 활용하면 될 것 같습니다. aws configure에 등록하고(vim으로 SessionToken도 추가) list-secrets 를 수행합시다.

(region 정보를 따로 준적이 없는데, secret이 us-east-1에 할당되어있습니다. 해당 정보 없이는 접근 오류가 나므로 configure 등록할때 us-east-1을 입력해줘야합니다.)

하나의 Secret이 있군요. value를 얻어봅시다.

뭘 얻긴했는데 뭔 의민지는 잘 모르겠네요. 어쨌든 이렇게 Senario가 마무리 되었습니다.

Conclusion

이번 Scenario는 IAM에서 manager user에게 별다른 고려없이 권한을 많이 줬다가는, privilege escalation뿐만 아니라 admin도 다른 하위 계정에 접근 당할 수 있는 것을 보여주는 것 같습니다. tag로 제어하다가는 큰 코 다칠 수 있네요. 저번 lambda 관련 scenario와 방법이 유사한 것 같습니다.

tag를 할당함으로써 admin을 아래 수준의 계정에서 접근할 수 있는 수준으로 끌어내림과 동시에 기존 계정 console 접근 key를 파괴하는 것을 먼저 수행

admin에 새로운 console 접근 key를 할당. multi-factor 인증도 할당

assume role로 aws secretmanager에 임시 접근 가능한 계정 생성 및 해당 생성 계정으로 탈취

💡

Exploit insecure IAM permissions to escalate your access. Start with a role that manages other users credentials and find a weakness in the setup to access the "admin" role. Using the admin role retrieve the flag from secretsmanager.