현재는 이전 글(보러 가기)에서 작성한 것처럼 Wazuh 사용을 위한 기본적인 네트워크 뼈대가 구축되어 있다. 하지만, 현재 구성만으로는 Wazuh Dashboard에 접속하여 서비스를 확인하는 것이 전부이고 특별한 Alert를 찾아볼 수는 없다.
최종 목표인 침해 사례를 적용해 공격부터 방어까지의 침해사고 대응과정을 직접 경험하기 위해 우리는 AWS Native 보안 로깅을 활성화하고, 이를 Wazuh Manager와 연동해주어야 한다.
위 과정을 하기 위해서는 우선 로깅을 할 대상이 필요하다. 현재 CloudTrail의 경우에는 AWS 계정을 대상으로 API 호출을 기록하는 것이기 때문에 이미 활성화(Management/Data Events 추적 중) 되어 있다.
VPC Flow Logs는 VPC, Subnet 또는 ENI를 대상으로 활성화 할 수 있는데, 팀 근두운 프로젝트에서는 ALB 및 Victim EC2에서 발생하는 네트워크 흐름을 분석하기 위해 관련 리소스 구축이 선행되어야 한다. 또한 WAF Logs를 수집하기 위해서는 ALB에 연결할 Web ACL 구성이 필요하다.
이번 단계에서는 실제 AWS 환경에서 공격 시뮬레이션 시 로깅 대상이 될 취약한 설정을 가진 EC2를 생성하고, EC2에 Nginx 기반 웹 서버를 설치한 후 ALB와 팀 근두운이 구매한 외부 도메인을 연결하여 외부에 공개하는 것을 목표로 한다.
flowchart TB
INTER("Internet</br>(Client)")
CERT("ACM(HTTPS 인증서)")
SH("AWS Shield")
RT("Route 53</br>service.kintoun.work")
ALB("Internet-facing ALB")
subgraph V["VPC 10.50.0.0/16"]
TG("Target Group</br>Forward HTTP/80")
subgraph AZ1["AZ: ap-northeast-2a"]
subgraph SUB1["Public Subnet 10.50.110.0/24"]
ALBA("ALB Node A")
end
subgraph SUB2["Public Subnet 10.50.40.0/24"]
VIC("Victim EC2</br>Nginx: Port 80")
end
end
subgraph AZ2["AZ: ap-northeast-2b"]
subgraph SUB3["Public Subnet 10.50.120.0/24"]
ALBB("ALB Node B")
end
end
end
INTER --"DNS Query" --> RT -.->|"Alias A 레코드 대상 지정"| ALB
RT -.->|"ALB의 IP주소 응답"| INTER
INTER -- "HTTPS 443" --> ALB
CERT -.->|"TLS 인증서"| ALB
SH -.->|"DDoS 보호"| ALB
ALB -- "Listener로 수신" --> ALBA
ALB -- "Listener로 수신" --> ALBB
ALBA --> TG
ALBB --> TG
TG -- "사설 IP로 통신" --> VIC
취약한 설정을 가진 EC2(이하 “Victim EC2”)는 단순 SSRF를 통해 EC2에 부여된 IAM Role의 임시 자격증명 탈취가 가능하도록 IMDSv1 설정을 채택하였다.
IMDS(Instance Metadata Service)는 EC2 인스턴스 내부에서 자기 자신의 설정 정보를 조회하는 서비스로, IMDSv1의 경우에는 Session-Token 인증 없이 GET 요청만으로 인스턴스의 메타데이터를 조회할 수 있다. 만일 SSRF 취약점이 있는 웹 애플리케이션이라면 공격자가 IMDS를 호출하여 정보를 탈취할 위험이 존재한다.
curl <http://169.254.169.254> # IMDS 호출 명령
# IMDS 경로를 지정하면 해당 경로의 메타데이터를 얻을 수 있음
# ex) EC2 인스턴스 ID 정보 조회
curl <http://169.254.169.254/latest/meta-data/instance-id>
조회할 수 있는 메타데이터는 인스턴스 정보, 네트워크 및 보안 설정 정보, 자격 증명 및 권한 정보 등이 있는데, curl <http://169.254.169.254/latest/meta-data/iam/security-credentials/><ROLE_NAME> 명령으로 자격 증명 및 권한 정보가 공격자에 의해 탈취당하면, 공격자는 해당 임시 자격증명을 통해 다른 AWS 리소스에 접근하여 정보 유출 또는 비용을 발생시키는 서비스를 활성화 하는 등의 악성 행위를 수행할 수 있게 된다.
IMDS로 액세스할 수 있는 메타데이터 - https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-retrieval-examples-imdsv1
실제 운영 환경이라면, Session-Token 인증 기반의 IMDSv2 설정을 권장하고 있다.
# Terraform에서의 IMDS 설정 (EC2 생성 시 결정)
metadata_options {
http_tokens = "optional" # IMDSv1과 IMDSv2 모두 허용
}
metadata_options {
http_tokens = "required" # IMDSv2
}
근두운 인프라에서는 자격증명 탈취 공격 기법을 다루기 때문에, IMDSv1 설정을 적용하되, 의도치 않은 AWS API 악용을 방지하기 위해 Victim EC2의 IAM Role에 가짜 시크릿을 저장하고 있는 S3 버킷에 대한 s3:ListBucket, s3:GetObject만 가능하도록 권한과 리소스를 제한하였다.
[+] 공격자가 침투한 AWS 환경에 어떤 S3 버킷이 있는지 모른다는 상황을 가정하여 s3:ListAllMyBuckets 권한도 부여해 준다. 해당 권한은 AWS 계정 안의 모든 버킷 이름을 조회할 수 있다.(CLI 에서 aws s3 ls 가능)