[ CloudGoat | Easy ] beanstalk_secrets 시나리오 실습

Github 링크

cloudgoat/cloudgoat/scenarios/aws/beanstalk_secrets/README.md at master · RhinoSecurityLabs/cloudgoat

---

README

시나리오 개요

 

이 시나리오는 Elastic Beanstalk의 설정 오류로 노출된 자격 증명을 탈취하고, 최종적으로 IAM 권한 남용을 통해 관리자 권한을 획득하는 과정을 다룬다. 클라우드 환경에서 환경 변수 관리의 중요성과 과도한 IAM 권한 부여가 초래하는 위험성을 학습할 수 있다.

 

Exploitation Route

1. Bruteforce Permissions: 제공된 Low-Privilege User의 AWS 자격 증명을 사용하여 실습을 시작한다. aws sts get-caller-identity 명령어를 통해 현재 자신의 신원과 접근 권한을 가장 먼저 확인하여 공격 가능 범위를 파악한다.
2. Enumerate Elastic Beanstalk: 탐색된 권한을 바탕으로 Pacu의 elasticbeanstalk__enum 모듈을 사용하여 Elastic Beanstalk 애플리케이션 및 환경을 열거합니다. 이 과정에서 환경 변수가 잘못 구성되어 Secondary Credentials의 자격 증명이 노출된 EB 환경을 식별하고 해당 정보를 탈취한다.
3. Check IAM Permissions: 탈취한 보조 자격 증명을 사용하여 IAM 리소스 및 권한을 분석한다. 이 계정이 시스템 내에서 어떤 추가적인 활동을 할 수 있는지 정찰하여 다음 단계로 나아가기 위한 취약점을 찾는다.
4. Identify iam:CreateAccessKey: 권한 분석 중, 특정 관리자 사용자를 위해 새로운 액세스 키를 생성할 수 있는 iam:CreateAccessKey 권한이 있음을 발견한다. 이는 관리자 계정 권한을 획득할 수 있는 결정적인 단서가 된다.
5. Generate Admin Key: 해당 권한을 남용하여 관리자 액세스 키를 생성하고, 이를 통해 대상 계정의 기존 인증 수단을 우회하고 관리자 계정의 제어권을 확보한다.
6. Retrieve Final Flag: 마지막으로 확보한 관리자 권한을 사용하여 AWS Secrets Manager에 접근하고, 최종 플래그(Final Flag)를 획득하며 시나리오 실습을 완료한다.

---

[ 환경 구축 ]

시나리오 생성

먼저 터미널에서 아래 명령어를 입력하여 실습 환경을 구축한다.

cloudgoat create beanstalk_secrets

Apply complete! 메시지가 뜨면 AWS상에 실습 리소스가 성공적으로 생성된 것이다.

 

 

시나리오 리소스 분석

 

• 1 VPC: 실습 환경이 격리된 네트워크 공간. Elastic Beanstalk 환경이 이 내부에서 구동된다.
• 1 Elastic Beanstalk Environment: 애플리케이션 배포 및 관리 서비스입니다. 이 시나리오의 핵심 취약점인 환경 변수 설정 오류가 발생하는 지점이다.
• 1 IAM Low-Privilege User (Start): 우리가 처음 부여받는 계정. 권한이 매우 제한적이지만, Beanstalk 환경을 열거(Enumeration)할 수 있는 최소한의 권한을 가진다.
• 1 IAM Secondary User (Intermediate): Beanstalk 환경 변수 속에 자격 증명이 숨겨져 있는 계정. 이 계정을 탈취해야 관리자 권한으로 가는 다음 관문인 iam:CreateAccessKey 권한을 사용할 수 있다.
• 1 AWS Secrets Manager Secret (Goal): 최종 목적지. 관리자 권한을 획득해야만 이 시크릿에 접근하여 Final Flag를 읽을 수 있다.

---

AWS CLI 프로필 설정 (자격 증명 등록)

시나리오에서 발급받은 access_key_id와 secret_access_key를 사용하여 내 로컬 환경에 사용자의 프로필을 등록하고 정상적으로 접속되는지 확인한다.

# 프로필 등록
aws configure --profile [프로필명]

시나리오에서 생성된 사용자인 Low-Privilege User와 Secondary User 프로필을 등록한다. 

 

현재 사용자 정보 확인

# 현재 신분 확인
aws sts get-caller-identity --profile [프로필명]

프로필 등록 후, 각 계정으로 정상 접속되는지 UserId와 Arn을 확인한다. secondary_user의 비밀키를 알아내야 한다.

---

[ Elastic Beanstalk 환경 조사 ]

정석대로라면 IAM을 가장 먼저 확인하는 게 순서이지만 이 시나리오에서는 Low-Privilege User로 접속했기 때문에 직접 내 권한을 조회할 수 있는지 확인하는 것이 먼저이다. 이 계정은 특정 작업(Beanstalk 관련)만 가능하도록 만들어졌기 때문에 지금 가지고 있는 low_priv_user의 키로 본인의 권한을 조회해 보면 Access Denied가 뜬다. 

 

애플리케이션 및 환경 목록 확인

low_priv_user 권한으로 어떤 자원(Resource)에 접근할 수 있는지 먼저 파악해야 한다. 이 시나리오에서는 Elastic Beanstalk이 주 타겟이므로 어떤 Beanstalk 애플리케이션이 구동 중인지 확인한다.

# 애플리케이션 목록 확인
aws elasticbeanstalk describe-applications --profile [프로필명]

# 환경(Environment) 목록 확인
aws elasticbeanstalk describe-environments --profile [프로필명]

ApplicationName은 이후 모든 Beanstalk 관련 명령어의 필수 파라미터가 된다.

 

애플리케이션 안에는 여러 개의 실행 환경(운영, 테스트 등)이 있을 수 있다. 실제로 코드가 돌아가고 설정값이 들어있는 환경의 이름을 찾는 명령어이다. 

 

확보된 타겟 정보

• ApplicationName: cgidvhcic4piwh-app
• EnvironmentName: cgidvhcic4piwh-env

---

[ 자격 증명 탈취 및 권한 상승 ]

확보한 ApplicationName과 EnvironmentName을 바탕으로 이 환경의 상세 설정값을 확인하여 환경 변수에 숨겨진 Secondary User의 자격 증명을 찾아낼 차례이다.

 

환경 설정(Configuration Settings)에서 자격 증명 탈취

Beanstalk 환경 설정 속에는 개발자가 실수로 남겨둔 Secondary User의 Access Key가 숨겨져 있다.

- AWS CLI

# 모든 설정값을 출력한 뒤, 'KEY'가 포함된 줄만 골라내기
aws elasticbeanstalk describe-configuration-settings \
    --application-name [앱이름] \
    --environment-name [환경이름] \
    --profile low_priv_user \
    | grep -i "KEY"

grep을 활용해 수많은 설정값 중 우리가 필요한 'KEY'라는 단어가 포함된 줄만 빠르게 골라낸다.

 

- Pacu (elasticbeanstalk__enum 모듈)

Pacu는 데이터가 너무 많거나, 명령어를 일일이 치기 귀찮을 때 쓰는 자동화 공격 프레임워크다.

 

시작점 등록

set_keys

먼저 CloudGoat에서 처음 발급받은 low_priv_user의 키를 set_keys명령어로 등록하여 Pacu 세션을 시작한다.

 

모듈 실행 및 데이터 추출

# 실행 시 리전을 us-east-1로 설정하면 자동으로 환경 변수를 추출한다
Pacu (set-keys:low_priv) > run elasticbeanstalk__enum

JSON 데이터 중 특정 키값만 필터링해서 SECONDARY_ACCESS_KEY와 SECONDARY_SECRET_KEY를 확보한다.

 

보조 계정 권한 분석 및 공격 수행

Secondary User로 전환

방금 탈취한 보조 계정(secondary)의 키를 Pacu에 다시 등록한다.

Pacu (set-keys:low_priv) > set_keys

whoami 명령어로 키가 잘 바뀌었는지 확인한다. 성공하면 프롬프트가 Pacu (set-keys:secondary) > 로 바뀌며 이제부터 모든 명령은 보조 계정의 권한으로 실행된다.

 

Pacu에서 set_keys를 두 번 사용하는 이유는 공격 단계에 따라 필요한 권한이 다르기 때문이다. 첫 번째 키(low_priv)로 정보를 획득했다면, 두 번째 키(secondary)는 그 정보를 이용해 관리자 권한으로 가는 역할을 한다.

 

권한 분석

Secondary 키를 얻은 직후, 이 계정이 무엇을 할 수 있는지 확인하는 단계이다.

 

 

 

- AWS CLI

aws configure --profile secondary 등록 후 aws sts get-caller-identity 확인

 

 - Pacu

Pacu (set-keys:secondary) > run iam__enum_permissions

Pacu가 FAILURE라고 띄운 이유는 이 secondary_user 역시 자기 자신의 권한을 조회(List/Get)할 권한은 없기 때문이다.

 

이번에도 whoami 명령어를 입력하여 14개의 권한이 무엇인지 확인해 본다.

"iam:createaccesskey": {
        "Resources": [
          "*"
        ]
      }

출력된 권한 목록을 보면 가장 위에 iam:createaccesskey가 있고, 대상(Resources)이 *로 되어 있다. 이건 이 secondary_user가 이 AWS 계정 내의 그 누구의 것이든 새로운 Access Key를 발급할 수 있다는 뜻이다.

 

[ 관리자(Admin) 권한 탈취 ]

이제 secondary_user가 가진 iam:CreateAccessKey 권한을 남용하여 이 계정의 관리자(Admin) 권한을 뺏어올 차례다.

 

• 관리자 유저의 이름 찾기
• 그 관리자의 새 키 발급하기

관리자(Target) 유저 식별

권한 상승을 하기 위해서는 누구의 키를 새로 만들지 타겟을 정해야 한다. 

# CLI 명령어
aws iam list-users --profile secondary

# Pacu 명령어
Pacu (set-keys:secondary) > aws iam list-users

현재 계정은 iam:ListUsers 권한도 가지고 있으므로 전체 유저 목록을 조회해 본다.

출력된 리스트에서 관리자 계정인 cgidvhcic4piwh_admin_user 의 이름을 식별했다.

 

관리자 권한 탈취

식별한 관리자 유저의 새로운 액세스 키를 강제로 발급받는다. 이 단계가 성공하면 기존 관리자의 동의 없이도 관리자 권한을 가진 키를 가지게 된다.

# CLI 명령어
aws iam create-access-key --user-name [찾은_관리자_이름] --profile secondary

# Pacu 명령어
Pacu (set-keys:secondary) > aws iam create-access-key --user-name [찾은_관리자_이름]

관리자의 AccessKeyId와 SecretAccessKey가 출력됐다. 이 키를 admin_user라는 이름의 프로필로 등록 후 관리자 권한이 있는지 확인해 본다. 

 

AWS CLI 프로필 설정 

aws configure --profile admin_user
aws sts get-caller-identity --profile admin_user

ARN이 ...user/cgidvhcic4piwh_admin_user로 나오면 성공이다. low_priv_user로는 볼 수 없었던 모든 유저의 정보를 다시 한번 확인해 보겠다. 

 

이번 시나리오의 최종 목적지는 AWS Secrets Manager이므로 관리자(admin_user)의 권한을 가졌으니 플래그를 획득하면 된다.

---

공격 단계별 명령어 비교

공격 단계	도구 (Pacu) 명령어	수동 (AWS CLI) 명령어	핵심 목표
1. 키 설정	set_keys	aws configure --profile [명]	획득한 자격 증명을 시스템에 등록
2. 환경 열거	run elasticbeanstalk__enum	aws elasticbeanstalk describe-configuration-settings	Beanstalk 설정값 내 숨겨진 키 탈취
3. 권한 분석	run iam__enum_permissions	aws iam list-user-policies / get-account-summary	탈취한 계정이 가진 '폭탄' 권한 확인
4. 타겟 조사	aws iam list-users	aws iam list-users --profile [명]	권한을 뺏을 대상(Admin)의 정확한 이름 식별
5. 권한 상승	aws iam create-access-key	aws iam create-access-key --user-name [관리자]	타겟의 새로운 마스터 키를 강제로 발급
6. 최종 탈취	aws secretsmanager ...	aws secretsmanager get-secret-value	관리자 권한으로 최종 Flag(Secret) 획득

---

[ Secrets Manager에서 플래그 탈취 ]

시크릿(Secret) 목록 확인

# 시크릿 매니저 목록 확인
aws secretsmanager list-secrets --profile admin_user

먼저 어떤 이름의 비밀 데이터가 저장되어 있는지 리스트를 확인한다.  출력 결과에서 Name 항목에서 cgidvhcic4piwh_final_flag라는 이름을 확인했다.

 

플래그 내용 읽기

찾아낸 시크릿 이름을 사용하여 실제 플래그 값을 가져온다.

# 플래그 내용 읽기
aws secretsmanager get-secret-value --secret-id [SecretName] --profile admin_user

SecretString 항목에 들어있는 FLAG{...} 형태의 문자열을 확인하면 시나리오 성공!

 

낮은 권한의 유저로 시작해서 Elastic Beanstalk의 설정 오류를 파고들고, IAM 권한 상승을 거쳐 관리자가 된 후, 결국 Secrets Manager까지 탈취하는 공격 시나리오를 완수했다.

 

[ 실습 종료 및 리소스 삭제 ]

생성한 리소스들을 지우지 않으면 비용이 발생하므로 실습이 끝난 후 리소스를 지우면 된다.

cloudgoat destroy beanstalk_secrets

---

취약점 분석 (Vulnerability Analysis)

이번 시나리오에서 발생한 보안 사고의 핵심 원인은 설정 오류를 통한 자격 증명 노출과 IAM 권한 관리 미흡의 결합이다.

 

• 환경 변수 내 민감 정보 노출: Elastic Beanstalk 설정(Environment Variables)에 SECONDARY_ACCESS_KEY를 평문으로 포함했습니다. 이는 공격자가 설정 조회 권한만 가져도 시스템의 다음 단계로 진입할 수 있는 경로를 넘겨주는 결과를 초래했다.
• 과도한 IAM 권한 부여: 보조 계정(secondary_user)에 iam:CreateAccessKey 권한이 부여되어 있었으며, 대상(Resource)이 *(모든 사용자)로 설정되어 있었다. 이는 외부인이 관리자 계정의 새로운 키를 마음대로 발급받아 제어권을 탈취할 수 있는 결정적인 취약점이 되었다.
• 정찰 방어 인증 미흡: iam:ListUsers 권한이 열려 있어, 공격자가 어떤 계정을 타겟으로 삼아 키를 생성할지(Admin 계정 식별) 손쉽게 파악할 수 있었다.

 

대응 방안

• 최소 권한 원칙(Least Privilege) 엄격 준수
  • 사용자에게 필요한 최소한의 권한만 부여하며, 특히 타인의 액세스 키를 생성하거나 활성화할 수 있는 iam:CreateAccessKey 권한은 관리자 외에는 엄격히 제한해야 한다.
  • 키 관리 권한이 불가피하게 필요한 경우, Resource 조건을 활용하여 자신의 액세스 키(${aws:username})만 제어할 수 있도록 정책 범위를 한정해야 한다.
  위험한 권한 조합 및 환경 변수 관리 강화
  • Elastic Beanstalk과 같은 서비스 설정 시, API Key나 자격 증명을 환경 변수에 평문으로 노출하지 않도록 주의해야 한다. 민감 정보는 AWS Secrets Manager나 Parameter Store를 통해 관리하고 IAM Role을 통해 호출하는 방식을 지향해야 한다.
  • 권한 상승의 징검다리가 될 수 있는 특정 API 권한들의 조합(설정 조회 + 키 생성 + 시크릿 접근)이 단일 사용자에게 몰리지 않도록 직무 분리를 실시해야 한다.
  중요 보안 이벤트에 대한 모니터링 및 알림 강화
  • 관리자급 계정에서 새로운 액세스 키가 생성되거나 환경 설정이 변경되는 것과 같이 보안에 직접적인 영향을 주는 API 호출이 발생할 경우, CloudWatch Alarms나 SNS 알림을 통해 관리자가 즉각 인지할 수 있는 체계를 갖춰야 한다.
  • Amazon GuardDuty를 활용하여 비정상적인 위치나 환경에서 관리자 권한을 행사하려는 패턴을 실시간으로 감시해야 한다.
  정기적인 IAM 감사 및 자격 증명 관리
  • AWS Config 또는 IAM Access Analyzer와 같은 도구를 활용하여 과도한 권한(Resource: *)이 부여된 정책이나 오랫동안 사용되지 않은 액세스 키가 있는지 정기적으로 감사해야 한다.
  • 실습에서 노출된 액세스 키와 같은 자격 증명은 즉시 무효화하고, 정기적으로 키를 Rotation 시켜 유출 시 발생할 수 있는 피해를 최소화해야 한다.