Amazon Web Services 한국 블로그
Amazon GuardDuty, EC2 인스턴스 자격 증명 유출 탐지 강화
Amazon GuardDuty는 악의적인 활동과 미승인 활동을 지속적으로 모니터링하여 AWS 계정, 워크로드, Amazon Simple Storage Service(Amazon S3)에 저장된 데이터를 보호하는 위협 탐지 서비스입니다. GuardDuty는 기계 학습을 활용해 수많은 공개 및 AWS 생성 데이터 피드에서 수십억 개의 이벤트를 분석하여 문제가 있음을 인식할 수 있는 징후인 추세, 패턴 및 이상 현상을 찾습니다. GuardDuty는 클릭 한 번으로 활성화하여 몇 분 안에 최초 결과를 확인할 수 있습니다.
오늘, GuardDuty에 사용자의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 자격 증명이 다른 AWS 계정에서 사용되는 경우를 탐지하는 기능이 추가되었습니다. EC2 인스턴스 자격 증명은 AWS Identity and Access Management(IAM) 역할이 연결된 경우 EC2 메타데이터 서비스를 통해 인스턴스에서 실행 중인 모든 애플리케이션에 사용할 수 있는 임시 자격 증명입니다.
어떤 위험이 있습니까?
EC2 인스턴스에 배포된 워크로드는 AWS 서비스에 액세스할 때 액세스 키, 비밀 액세스 키 및 세션 토큰을 사용합니다. 워크로드에 액세스 키 자격 증명을 전달하는 보안 메커니즘은 워크로드에 필요한 권한을 정의하고, 권한이 있는 하나 또는 여러 개의 IAM 정책을 생성하고, 정책을 IAM 역할에 연결하고, 마지막으로 역할을 인스턴스에 연결합니다.
역할이 연결된 EC2 인스턴스에서 실행되는 모든 프로세스는 EC2 메타데이터 서비스를 호출하여 보안 자격 증명을 검색할 수 있습니다.
curl 169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
"Code" : "Success",
"LastUpdated" : "2021-09-05T18:24:45Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "AS...J5",
"SecretAccessKey" : "r1...9m",
"Token" : "IQ...z5Q==",
"Expiration" : "2021-09-06T00:44:06Z"
}이러한 자격 증명의 기간 및 범위는 제한되어 있으며, 최대 6시간 동안만 유효합니다. 또한 EC2 인스턴스와 연결된 IAM 역할에 연결된 권한의 범위로 제한됩니다.
모든 AWS SDK는 이러한 자격 증명을 자동으로 검색하고 갱신할 수 있습니다. 애플리케이션에 추가 코드는 필요하지 않습니다.
이제 EC2 인스턴스에서 실행되는 애플리케이션이 손상되어 악의를 가진 공격자가 인스턴스의 메타데이터 서비스에 액세스했다고 가정해 보겠습니다. 악의를 가진 공격자가 자격 증명을 추출합니다. 이러한 자격 증명에는 인스턴스에 연결된 IAM 역할에서 정의한 권한이 있습니다. 애플리케이션에 따라 공격자는 S3 또는 DynamoDB에서 데이터를 유출하거나, EC2 인스턴스를 시작 또는 종료하거나, 심지어 새로운 IAM 사용자 또는 역할까지 생성할 수 있습니다.
GuardDuty는 출시 이후 이러한 자격 증명이 AWS 외부의 IP 주소에서 사용되는 경우를 탐지해 왔습니다. 따라서 교묘한 공격자는 GuardDuty가 감시하지 않는 위치에서 활동하기 위해 다른 AWS 계정으로 자신의 활동을 숨길 수 있습니다. 오늘부터 GuardDuty는 AWS 네트워크 내의 다른 AWS 계정에서 자격 증명이 사용되는 경우도 탐지합니다.
어떤 알림이 생성됩니까?
AWS 서비스 API와 통신하는 소스 IP 주소가 EC2 인스턴스 IP 주소와 다를 수 있는 정당한 이유가 있습니다. 트래픽을 하나 이상의 VPC로 라우팅하는 복잡한 네트워크 토폴로지를 생각해 보겠습니다. AWS Transit Gateway 또는 AWS Direct Connect를 예로 들 수 있겠습니다. 또한 다중 리전 구성에서 또는 AWS Organizations를 사용하지 않는 경우 자격 증명을 사용하는 AWS 계정이 사용자 소유인지 확인하기란 쉽지 않습니다. 대기업은 이러한 보안 침해를 탐지하기 위해 자체 솔루션을 구현하지만 이러한 유형의 솔루션은 구축 및 유지 관리하기가 쉽지 않습니다. 이 문제를 해결하는 데 필요한 리소스를 보유한 조직은 소수에 불과합니다. 또한 그 과정에서 핵심 비즈니스에 집중해야 할 엔지니어링 노력이 분산됩니다. 이것이 바로 AWS가 이 문제를 해결하기로 결정한 이유입니다.
오늘부터 GuardDuty는 EC2 인스턴스 자격 증명의 오용이 탐지되면 알림을 생성합니다. 제휴 계정에서 자격 증명을 사용하는 경우 알림은 보통 심각도로 표시됩니다. 그렇지 않으면 높은 심각도의 알림이 생성됩니다. 제휴 계정은 동일한 GuardDuty 관리자 계정에 의해 모니터링되는 계정으로, GuardDuty 멤버 계정이라고도 합니다. 이러한 계정은 조직의 일부일 수도 있고 그렇지 않을 수도 있습니다.
실제 작동 방식
작동 방식을 알아보기 위해 EC2 인스턴스 중 하나에서 EC2 자격 증명 세트를 캡처하여 유출해 보겠습니다. SSH를 사용하여 인스턴스 중 하나에 연결하고 curl을 사용하여 자격 증명을 검색합니다.
curl 169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
"Code" : "Success",
"LastUpdated" : "2021-09-05T18:24:45Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "AS...J5",
"SecretAccessKey" : "r1...9m",
"Token" : "IQ...z5Q==",
"Expiration" : "2021-09-06T00:44:06Z"
}인스턴스에는 이 AWS 계정의 S3 버킷을 읽을 수 있는 권한이 있는 IAM 역할이 있습니다. 자격 증명을 복사하여 붙여넣습니다. 그런 다음 동일한 GuardDuty 관리자 계정과 제휴되지 않은 다른 AWS 계정에서 실행 중인 다른 EC2 인스턴스에 연결합니다. SSH를 사용하여 이 다른 인스턴스에 연결한 다음 손상된 자격 증명으로 AWS CLI를 구성합니다. 프라이빗 S3 버킷에 액세스를 시도합니다.
# 먼저 액세스 권한이 없음을 확인합니다.
[ec2-user@ip-1-1-0-79 ~]$ aws s3 ls s3://my-private-bucket
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
# 그런 다음 손상된 자격 증명을 사용하여 CLI를 구성합니다.
[ec2-user@ip-1-1-0-79 ~]$ aws configure
AWS Access Key ID [None]: AS...J5
AWS Secret Access Key [None]: r1...9m
Default region name [None]: us-east-1
Default output format [None]:
[ec2-user@ip-1-1-0-79 ~]$ aws configure set aws_session_token IQ...z5Q==
# 마지막으로 다시 S3에 액세스를 시도합니다.
[ec2-user@ip-1-1-0-79 ~]$ aws s3 ls s3://my-private-bucket
PRE folder1/
PRE folder2/
PRE folder3/
2021-01-22 16:37:48 6148 .DS_Store
잠시 후에 자격 증명을 훔친 AWS 계정에서 AWS 관리 콘솔을 사용하여 GuardDuty에 액세스합니다. 높은 심각도의 알림이 생성되었음을 확인할 수 있습니다.
그러면 어떻게 해야 합니까?
공격자는 원격 코드 실행(RCE)이 있거나, 인스턴스 내 로컬 프레젠스를 갖고 있는 경우에, 또는 서버 측 요청 위조(SSRF) 및 XML 외부 엔터티(XXE) 삽입과 같은 애플리케이션 수준 취약성을 악용함으로써 자격 증명을 추출할 수 있습니다. 보안 및 패치가 적용된 AMI에서 인스턴스를 다시 빌드하여 원격 액세스 제거, 액세스 자격 증명 회전 등 RCE 또는 로컬 액세스를 완화하는 방법은 여러 가지가 있습니다. 취약성이 애플리케이션 수준에 있는 경우 사용자 또는 애플리케이션 공급 업체는 애플리케이션 코드를 패치하여 취약성을 제거해야 합니다.
자격 증명 손상 위험이 있다는 알림을 받으면 가장 먼저 계정 ID를 확인해야 합니다. 해당 계정이 회사 계정인가요? 분석 중에 비즈니스 사례에서 허용하는 경우 손상된 인스턴스를 종료하거나 애플리케이션을 종료할 수 있습니다. 이렇게 하면 공격자가 만료 시 갱신된 인스턴스 자격 증명을 추출할 수 없습니다. 의심스러운 경우 Amazon AWS 악용 사례 신고 양식을 사용하여 AWS 신뢰 및 안전 팀에 문의하세요. 요청을 제출하실 때는 의심스러운 AWS 계정 ID, 일반 텍스트로 작성된 로그 등 필요한 모든 정보를 제공하시기 바랍니다.
가용성
이 새로운 기능은 추가 비용 없이 모든 AWS 리전에서 제공됩니다. AWS 계정에서 GuardDuty가 이미 활성화된 경우 이 기능을 기본적으로 사용하도록 설정됩니다.
그렇지 않다면 지금 GuardDuty를 활성화하고 30일 평가판을 시작해 보세요.