Notice
Recent Posts
Recent Comments
Link
«   2025/07   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
Archives
Today
Total
관리 메뉴

hiris

CloudGoat - iam_privesc_by_key_rotation 본문

AWS

CloudGoat - iam_privesc_by_key_rotation

hiris 2024. 4. 2. 18:57

깃허브 주소는 다음과 같다 .

https://github.com/RhinoSecurityLabs/cloudgoat?tab=readme-ov-file

 

GitHub - RhinoSecurityLabs/cloudgoat: CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool

CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool - RhinoSecurityLabs/cloudgoat

github.com

 

 

./cloudgoat.py create iam_privesc_by_key_rotation

 

 

 

 

=> cg-kerrigan의 이름을 가진 사람의 이름으로 등록을 해준다. 

 

2. 각 user 별 정책과 role을 확인할 수 있다. 

 

 

=> 총 3개의 user (admin / developer / manager)를 확인할 수 있다.

 

 

1. 먼저 각 user 별로 attached된  Managed 된 Policy들을 확인해본다.

 

Admin에 대한 정책
Developer에 대한 정책
manager에 대한 정책

 

2. 먼저 각 user 별로 attached된  Inline 된 Policy들을 확인해본다. 

 

 

Admin에 대한 inline 정책

 

=> 각 role 별로 정리를 하면 다음과 같다. 

 

3. Inline Policy들을 위주로 각 Policy의 document를 확인해본다.

 

manager의 policy의 inline 정책

 

* "StringEquals " : { "aws : ResourceTag/developer" : "true"} 라는 부분이 있다. 

=> 해당 부분을 살펴보면 MFA와 AccessKey를 관리하는 것을 확인할 수 있다. 

그리고 user, role, MFADevice 들에 대해 태그를 관리할 수 있는 statement들도 확인할 수 있다. 

admin / developer 의 inline 정책

 

=> developer는 secretsmanager의 listsecrets를 수행할 수 있지만, 내용을 확인할 수는 없어보인다 

 

=> admin의 경우 cg-secretsmanager는 AssumeRole이 허용되어 있는데 여기서 새롭게 발견한 Role을 더 찾아보면 다음과 같다. 

 

 

새로 발견한 Role에 대한 정보 탐색

 

=> 해당 코드를 해석을 해보면 MFA만 설정되어 있으면 AssumeRole을 해줄 수 있다는 것을 알 수 있다. 

 

 "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true" # MFA가 설정되어있어야 assumerole할 수 있음 
                }
            }

 

 

그리고 특정 role에 attached 된 Managed Policy 목록을 확인해본다. 

cg_view_secrets

 

=> cg_view_secrets라는 policy가 attached된 것도 확인할 수 있다. 

 

policy의 정책 확인

 

=> policy의 버전 정보를 확인하고, 이 버전의 내용을 확인한다.

해당 버전 정보는 v1임을 확인할 수 있다. 

 

그리고 v1에 대한 내용을 살펴보면 secret 목록을 읽고 secretvalue도 읽어 볼 수 있는 것을 확인할 수 있다. 

 

3. 권한 탈취 

 

manager의 정책을 살펴보니 User에게 Tagging 할 수 있는 권한이 dlTrh 

"developer=true" 인 Tag를 가진 유저에 한해서 AccessKey 및 MFA 관련 권한을 맘대로 할 수 있는 것을 확인할 수 있었다. 

 

그럼.. admin에게 developer=true 권한을 주고  accesskey를 재할당을 한다면,  admin 권한을 탈취할 수 있는 거 아닐까 ? 

 

 

1. 태그를 일단 admin에게 준다. 

 aws iam tag-user --user-name admin_iam_privesc_by_key_rotation_cgidem9bx4gxhc --tags '{"Key":"developer", "Value": "true"}' --profile cg-kerrigan

 

 

2. accesskey 를 생성하려고 하니 갯수 제한에 막히게 된다.  그래서 key 목록을 확인한 뒤 accesskey를 지우려고 한다.

 

# user의 AccessKey 삭제 

aws iam delete-access-key --user-name [user명] --access-key-id [AccessKey ID] --profile cg-kerrigan



다음과 같은 명령어를 활용해 키를 지우고 다시 키를 생성했다. 

 

그리고 키를 생성해주었다. 

key 생성

 

그리고 해당 key를 aws configure --profile cg_adim으로 등록을 해주었다. 

 

그다음 MFA로 2차 인증을 해보겠다. 

 

 

MFA 생성하는 명령어
png 파일이 생성됨을 확인

 

엇 코드가 나왔닷 

 

계속 10초마다 바뀌긴 하는데 .. 코드를 넣어서 진행을 해봤지만 잘 안돼서 여기서부터는 블로그를 참고하며 이해를 했다. 

 

 

aws iam enable-mfa-device --user-name admin_iam_privesc_by_key_rotation_cgidem9bx4gxhc --serial-number arn:aws:iam::818703664379:mfa/cg_tempo_mfa --authentication-code1 998470 --authentication-code2 107108 --profile cg-kerrigan

 

그 후 assume role을 통해 권한을 부여하여 assume-role credenital을 획득한다. 

 

이후 crdential을 획득을 한다. 그렇게 하면 secret을 획득한다 .. 

 

해당 명령어는 다음과 같다. 

 

aws sts assume-role --role-arn [role ARN] --role-session-name cg-admin --profile cg-admin \
--serial-number [MFA device serial] --token-code [OTP 코드]

 

 

 

총평 

 

tag를 사용하여 권한 탈취하는 게 가능한지도 그리고 이렇게 쉬울 줄 몰랐다. 

-> tag 관해서 공부도 좀 해봐야겠다. 

'AWS' 카테고리의 다른 글

Cloud9  (0) 2023.10.31
SIEM 구축  (2) 2023.10.23
CIS 벤치 마크  (2) 2023.10.20
AWS를 사용한다면 반드시 알아야 할 네트워크 기초 지식  (0) 2023.10.20
Java Spring과 DB 연결  (0) 2023.10.03