AWS 계정 ID는 민감정보일까

들어가며

AWS 계정 ID는 민감정보로 분류될 수 있을까? 결론부터 말하면 '해당하지 않는다.' 이 이슈는 2022년도에 이미 종결된 이슈이며 AWS 공식 문서에도 정확하게 명시하고 있다.
그럼에도 이 포스팅에서는 발생할 수 있는 위협에 다뤄보려고 한다.

 

 

AWS Account ID 정의

AWS 공식 문서(https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html)에서는 계정 ID를 다음과 같이 정의하고 있다. AWS 계정을 고유하게 식별하는 12자리 숫자(예: 012345678901)이다. 많은 AWS 리소스는 ARN(Amazon Resource Name)에 계정 ID를 포함한다. 계정 ID 부분은 한 계정의 리소스와 다른 계정의 리소스를 구분한다. IAM의 경우 계정 ID 또는 계정 별칭을 사용하여 AWS 관리 콘솔에 로그인할 수 있다. 계정 ID는 다른 식별 정보와 마찬가지로 신중하게 사용하고 공유해야 하지만, 비밀이나 민감정보로 간주되지는 않는다.

 

 

공격에서의 계정 ID

AWS 환경에서 계정 획득이나 권한 상승을 시도하려면 거의 모든 공격에서 계정 ID가 필요하다. 다음의 예시를 살펴보자.

• 다른 사람의 계정에서 역할(Role)을 맡으려면 대상 역할 ARN을 지정해야 한다.
• DynamoDB 테이블에서 기밀 데이터를 읽으려면 대상 계정의 ID와 테이블 이름을 알아야 한다.
• 소유자가 아닌 SQS 큐에 메시지를 게시하려면 주제(topic) ARN을 알아야 한다.
• 다른 사람의 볼트 아카이브를 검색하려면 대상 계정 ID와 볼트 이름을 알아야 한다.

위와 같이 대상 계정 ID와 ARN을 알아야 리소스를 식별할 수 있고 공격을 시도할 수 있다.

 

 

계정 ID로부터 ARN 추적

2016년 'dargz'라는 이름의 해커가 대상 AWS 계정에 직접 접근하지 않고도 IAM 주체의 존재 여부나 교차 계정을 확인할 수 있는 방법을 공개했다. 이 방법은 현재까지도 계속 사용되고 있다.

IAM 정책을 생성하거나 적용할 때, AWS 정책 엔진은 주체 요소의 유효성을 검증하며, 존재하지 않는 경우 오류를 반환한다. 공격자는 이 특징을 이용하여 계정 내에서 일반적인 역할 이름과 사용자를 식별할 수 있다.

계정에 대한 로그를 남기지 않기 위해 직접 접근을 하지 않고 존재 여부를 확인하는 방법은 많지 않다. AWS는 이전에 비해 많은 제약 사항들을 추가해왔고 비인가 요청으로 의심되는 경우 "리소스가 존재하지 않습니다."라는 일괄적인 오류 메시지를 응답한다.

하지만 아직까지 유효한 몇가지 방법을 소개한다.

 

 

EC2 인스턴스에서 계정 ID 식별하기

aws 명령줄 도구(cli)를 이용하여 EC2 인스턴스에 접근이 가능하다면 AWS 계정 정보를 식별할 수 있다.

 

 

get-caller-identity

EC2 인스턴스의 프로파일 설정을 확인할 수 있다.

user@host:$ aws sts get-caller-identity
{
   "Account": "000000000000",
   "UserId": "AROAJIWIJQ5KCHMJX4EWI:i-00000000000000000",
   "Arn": "arn:aws:sts::000000000000:assumed-role/AmazonLightsailInstanceRole/i-00000000000000000"
}

 

 

EC2 메타데이터

메타데이터 서비스를 이용하면 계정에 대한 추가 정보, 사용 중인 EC2 인스턴스에 대한 추가 정보를 검색할 수 있다.

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/dynamic/instance-identity/document

요청 결과는 다음과 같다.

{
   "accountId" : "000000000000",
   "architecture" : "x86_64",
   "availabilityZone" : "ap-southeast-2a",
   "billingProducts" : null,
   "devpayProductCodes" : null,
   "marketplaceProductCodes" : null,
   "imageId" : "ami-042c4533fa25c105a",
   "instanceId" : "i-00000000000000000",
   "instanceType" : "t2.nano",
   "kernelId" : null,
   "pendingTime" : "2022-02-27T22:34:30Z",
   "privateIp" : "172.26.6.225",
   "ramdiskId" : null,
   "region" : "ap-southeast-2",
   "version" : "2017-09-30"
}

 

 

S3 버킷

S3 URI에 접근하면 다음 세 가지 응답 중 하나가 반환된다.

• 버킷 내 객체(파일) 목록
• "액세스 거부" 오류
• "버킷이 존재하지 않습니다."오류

 

 

SQS 큐 - SQS ReceiveMessage URI에 접근하면 다음 세 가지 응답 중 하나가 반환된다.

• 메시지 ID
• "액세스 거부" 오류
• "큐가 존재하지 않거나 액세스 권한이 없습니다." 오류

이러한 에러메시지의 차이를 이용하여 리소스가 존재하는지, 권한이 부족한 것인지 확인이 가능하다.

 

 

노출된 계정 ID의 취약성

Github에 공개된 페이지(https://github.com/SummitRoute/aws_exposable_resources)에서는 취약한 설정으로 노출될 수 있는 AWS 리소스를 나열하고 있다. 이는 특정 개인이나 대중에게 노출될 수 있는 AWS 리소스를 포함하고 있다. 그럼 과연 노출된 리소스를 통해 계정 ID를 획득한 경우 취약하다고 할 수 있을까.

실제로 많은 AWS 사용자가 리소스를 의도적으로나 비의도적으로 노출하고 있으며, 이는 클라우드 리소스를 식별하고 사용하는 데 필수적이다. 리소스가 노출되어 있음에도 불구하고 대규모의 해킹 사건이 발생하지 않는 이유는, 단순히 리소스가 노출되었다고 해서 공격자가 쉽게 악용할 수 없기 때문이다.

 

 

결론

• 계정 ID는 내부적으로, 외부적으로 공유 및 사용하는 식별자이다.
• AWS에서 무엇이든 빌드하려면 일반 텍스트로 구성된 계정 ID가 필요하다.
• 계정 ID를 아는 것만으로는 아무것도 해킹할 수 없다.
• AWS 위협 모델은 계정 ID를 알고 있다고 가정한다.
• 계정 ID가 유출되면 공격자가 사용하는 타사 서비스 등 계정에 대한 더 많은 정보를 식별할 수 있다.(Principle Enumeration)
• 계정 ID는 어느 시점에서든 의도치 않게 리소스로 노출될 수 있다.
• AWS에서는 그 아무도 계정 ID를 보안 제어 수단으로 의존하지 않는다.
• 환경 변수와 같은 매개변수를 사용하여 계정 ID와 ARN을 전달한다. 절대 하드코딩하지 않는다.
• 주요 이름과 리소스 이름을 예측할 수 없도록 짓는다. 최소한 기본값은 피한다.

 

 

권고

AWS 계정 ID의 노출이 직접적인 보안 위협으로 이어지지 않는다는 것을 확인했다. 그러나 계정 ID가 노출되는 경우 공격자가 활용할 수 있는 요소임에는 분명하며, 공개되었을 때 발생할 수 있는 잠재적 위협에 대해서는 인지해야 한다. 따라서 AWS의 권장 사항에 따라 계정의 멀티 팩터 인증(MFA)을 활성화하고, 권한 부여시 최소 권한 원칙을 적용하는 등 추가 보안 조치를 고려해야 한다.

 

 

출처

https://blog.plerion.com/aws-account-ids-are-secrets/
https://hackingthe.cloud/