AWS 보안 서비스를 사용한 Log4j 취약점으로부터 위험 노출 제한, 감지 및 대응 방법
이 글에서는 최근 공개된 Apache log4j2 취약점에 대응하는 AWS 고객에게 도움이 될 수 있는 대응 방법을 안내해 드리겠습니다. Log4j 취약성의 위험을 제한하기 방법, 문제에 취약한지 식별하는 방법, 적절한 패치로 인프라를 업데이트 방법에 대해 설명합니다.
Apache Log4j 취약점(CVE-2021-44228, CVE-2021-45046)은 치명적인 취약점(CVSS 3.1 유비쿼터스 로깅 플랫폼 점수 10.0)입니다 . 이 취약점을 통해 공격자는 취약한 플랫폼에서 원격 코드 실행을 수행할 수 있습니다. 버전 2.0-beta-9와 2.15.0 사이의 Log4j 버전 2가 이 취약점의 영향을 받습니다.
본 취약점은 일반적으로 디렉토리(LDAP 디렉토리)를 통해 데이터를 찾기 위해 Java 프로그램에서 사용하는 Java Naming and Directory Interface (JNDI)를 사용합니다.
아래 그림 1은 Log4j JNDI 공격 흐름을 보여줍니다.
그림 1. Log4j 공격 진행 상황. 출처: GovCERT.ch, 스위스 정부 컴퓨터 비상 대응팀(GovCERT)
AWS는 즉각적으로 Apache Log4j2 보안 이슈 (CVE-2021-44228) 대응 공지를 주기적으로 업데이트하고, Log4j 2.0+를 사용하여 실행 중인 JVM 핫패치 도구를 제공하고 있습니다. 더 자세한 사항은 한국어 대응 공지를 계속 확인해 주시기 바랍니다.
1. 위험 노출 제한 방법
AWS 고객은 여러 AWS 서비스를 사용하여 Log4j 취약점으로 인한 위험/노출을 제한할 수 있습니다. 고객은 계층화된 제어 접근 방식을 구축하고 노출을 제한하는 데 도움이 되도록 아래에 식별된 제어를 선택하고 선택할 수 있습니다.
AWS WAF
AWS 고객은 AWS Web Application Firewall이 제공하는 WAF용 관리형 규칙을 통해 Amazon CloudFront 배포지점, Amazon API Gateway REST API, Application Load Balancer 또는 AWS AppSync GraphQL API 리소스를 보호할 수 있습니다.
- AWSManagedRulesKnownBadInputsRuleSet – Log4JRCE Log4j 취약점의 존재에 대한 요청을 검사하는 데 도움이 규칙. 예시 패턴에는 ${jndi:ldap://example.com/}이 포함 됩니다.
- AWSManagedRulesAnonymousIpList – AnonymousIPList 클라이언트 정보를 익명화하는 것으로 알려진 소스의 IP 주소를 검사하는 데 도움이 규칙입니다.
- AWSManagedRulesCommonRuleSet – SizeRestrictions_BODY 규칙 요청 본체 크기가 가장 8킬로바이트 (8192 바이트)에있는 것을 확인합니다.
AWS WAF Classic을 사용하는 고객의 경우, AWS WAF로 마이그레이션하거나 사용자 지정 정규식 일치 조건을 생성해야 합니다.
멀티 계정을 가진 AWS 고객은 중앙 집중 관리 지침에 따라, AWS Firewall Manager를 사용 하여 회사 내 전체 계정에 AWS WAF 규칙을 배포할 수 있습니다.
AWS Network Firewall
AWS 고객은 AWS Network Firewall을 사용하여 Suricata 호환 IDS/IPS 규칙을 네트워크 기반 탐지 및 보호를 위해 배포할 수 있습니다. Log4j를 다루는 오픈 소스 Suricata 규칙은 NCC Group, ET Labs 및 CrowdStrike에서 사용할 수 있습니다. 이들 규칙은 Log4j 취약점의 사후 악용뿐만 아니라, 모든 스캐닝을 식별하는 데 도움이 될 수 있습니다. 현재 많은 양의 스캔이 발생하고 있으므로, 고객 여러분은 VPC에서 신뢰할 수 없는 인터넷 대상으로의 아웃바운드 LDAP 트래픽과 같은 잠재적인 악용 활동에 먼저 시간을 집중할 것을 권장합니다.
또한, 고객 여러분께서는 LDAP와 같은 프로토콜의 인스턴스가 53, 80, 123 및 443과 같은 비표준 LDAP 포트를 사용하지 못하도록 모니터링하거나 방지하는 아웃바운드 포트/프로토콜 시행 규칙 시행을 고려하시길 권장합니다. 포트 1389 아웃바운드 사용을 모니터링하거나 방지하는 것은 명령 및 제어 호출을 아웃바운드로 만들기 위해 인터넷 스캐너에 의해 트리거된 시스템을 식별하는 데 유용합니다. 또한, 중요 업무가 아닌 시스템은 기본적으로 인터넷에 대한 네트워크 호출을 하지 않도록 설정하기를 권장합니다. 아웃바운드 네트워크 트래픽 필터링 및 모니터링은 Log4j뿐만 아니라 다른 유형의 취약점에도 매우 유용합니다.
2. 취약점 감지 방법
앞에서는 Log4j 취약점을 악용하는 공격을 잠재적으로 제한하는 방법을 다루었습니다. 다음으로, 고객 서비스 환경에서 이 취약점이 존재하는지 여부를 감지하는 데 도움이 될 수 있는 부분에 대해알아보겠습니다.
그림 2. Inspector 콘솔에서 찾은 Log4j
Amazon Inspector
그림 2에서 볼 수 있듯이 Amazon Inspector 팀은 Amazon EC2 인스턴스 및 Amazon Elastic Container Registry Images(Amazon ECR) 에서 이 취약점의 존재를 식별할 수 있습니다. 신규 Amazon Inspector를 사용하면, 감지 작업이 자동으로 지속적으로 수행됩니다. 지속적인 취약점 검색은 새로운 소프트웨어 패키지, 새로운 인스턴스, 공개되는 새로운 CVE(Common Vulnerability and Exposure)와 같은 이벤트가생길때마다 진행됩니다.
예를 들어, Inspector 팀이 Log4j 취약점(CVE-2021-44228 및 CVE-2021-45046)에 대한 지원을 추가하면, Inspector가 지원하는 모든 AWS Systems Manager상 인스턴스에 대해 즉시 이 취약점을 찾기 시작합니다. 이들 인스턴스는 OS 패키지 관리자를 통해 Log4j가 설치되어 있거나 패키지가 Maven 호환 Amazon ECR 컨테이너 이미지에 있었던 것을 포함합니다. 해당 취약점이 있는 경우, 수동 조치 없이 발견 항목이 바로 나타나기 시작합니다. Inspector Classic을 사용하는 경우, 모든 Amazon EC2 인스턴스에 대해 평가를 실행하고 있는지 확인해야 합니다. 모든 Amazon EC2 인스턴스에 대한 평가 대상을 생성하고 있는지 확인하려면, 가이드 문서를 참고하세요.
Amazon GuardDuty
Inspector를 통해 이 취약점의 존재를 찾는 것 외에도 Amazon GuardDuty 팀은 Log4j 취약점 악용과 관련된 손상 지표를 추가하기 시작했습니다. GuardDuty는 알려진 잘못된 IP 주소 또는 DNS 항목에 도달하려는 시도를 모니터링하고 이상 기반 행동 결과를 통해 악용 후 활동을 찾을 수도 있습니다. 예를 들어 Amazon EC2 인스턴스가 비정상적인 포트에서 통신을 시작하면 GuardDuty는 Behavior:EC2/NetworkPortUnusual 혹은 NetworkPortUnusual 활동을 감지하고 결과를 생성합니다. GuardDuty에는 손상된 AWS 리소스에 대한 응답으로 나타날 수 있는 악용 후 활동과 관련된 다양한 결과도 제공합니다. GuardDuty 결과 목록은 GuardDuty 설명서를 참조하십시오.
AWS Security Hub
AWS Security Hub은 Inspector 및 GuardDuty와 함께 보안 경보를 집계하고 자동 수정 및 대응을 활성화하고 있습니다. 단기적으로는 Security Hub를 사용하여 AWS Chatbot , Amazon Simple Notification Service 또는 Inspector가 환경에서 이 취약점을 발견할 때 가시성을 위한 티켓팅 시스템을 통해 알림을 설정하는 것이 좋습니다. 장기적으로 Security Hub를 사용하여 적절한 경우 보안 경고에 대한 자동 수정 및 대응을 활성화하는 것이 좋습니다. Security Hub로 자동 치료 및 대응을 설정하는 방법을 참고하세요.
3. 취약점 대응 방법
여기서는 해당 취약점을 완화하기 위해 취할 수 있는 대응 방법에 대해 살펴 봅니다. 앞에서 언급했듯이 AWS는 즉각적으로 Apache Log4j2 보안 이슈 (CVE-2021-44228) 대응 공지를 주기적으로 업데이트하고, Log4j 2.0+를 사용하여 실행 중인 JVM 핫패치 도구를 제공하고 있습니다. (더 자세한 사항은 한국어 대응 공지를 계속 확인해 주시기 바랍니다.)
그림 3. 중요한 패치를 즉시 승인하는 Systems Manager Patch Manager 패치
AWS Systems Manager Patch Manager
AWS Systems Manager Patch Manager를 사용하면, 중요한 패치가 즉시 설치되도록 설정한 경우 EC2 인스턴스 패치가 가능합니다. 다만 패치가 완료되려면, 가장 최신 버전을 사용하고 있는지 확인하기 위해 애플리케이션 코드에서 라이브러리가 사용되는 곳마다 클래스 경로를 업데이트해야 합니다.
취약점이 식별되면 Log4j 버전 2.16.0을 사용하도록 ECR 컨테이너 이미지를 업데이트해야 합니다. 취약한 ECR 컨테이너 이미지로 빌드된 모든 컨테이너가 가능한 한 빨리 새 이미지를 사용하도록 업데이트되었는지 확인해야 합니다. 이는 이러한 이미지를 배포하는 데 사용하는 서비스에 따라 다를 수 있습니다. 예를 들어 Amazon ECS를 사용하는 경우, 새 배포를 강제 실행하도록 서비스를 업데이트할 수 있습니다. 그러면 새 Log4j 버전을 사용하여 이미지가 풀다운됩니다. 컨테이너 배포에 사용하는 방법을 지원하는 설명서를 확인하십시오.
업그레이드할 수 없는 경우 완화 전략
기본적으로 JDNI에 대한 액세스를 비활성화하는 버전 2.16.0으로 업그레이드할 수 없거나 환경에 패치를 적용할 전략을 아직 결정하고 있는 경우 Log4j 구성을 변경하여 이 취약점을 완화할 수 있습니다. .2.10 이상 버전에서 구현하려면, 애플리케이션 시작을 위한 JVM 명령에 ‐Dlog4j2.formatMsgNoLookups=True를 추가하여 log4j2.formatMsgNoLookups 설정을 추가합니다.
특정 버전의 완화 단계에 대한 보다 포괄적인 목록은 Apache 웹 사이트를 참조하십시오.
마무리
이 글에서 AWS 고객이 Log4j 취약성으로 인한 위험을 보호, 감지 및 대응하는 데 도움이 되는 계층화된 접근 방식을 채택할 수 있도록 하는 주요 AWS 보안 서비스에 대해 설명했습니다. 저희는 영문 AWS 보안 공지 혹은 한국어 번역을 계속 살펴 보시길 권장드립니다. 공동 책임 모델에 따라, AWS 서비스의 진행 사항을 계속 업데이트할 것입니다.
이 취약성의 중요성을 감안할 때, 고객 여러분께서 해당 취약성에 세심한 주의를 기울이고, 이 글에서 강조한 제어 방식의 구현의 우선 순위를 두실 것 또한 권장드립니다.
– Marshall Jones, AWS Security Specialist Solutions Architect
– Syed Shareef, AWS Senior Security Solutions Architect
이 글은 AWS Security Blog의 Using AWS security services to protect against, detect, and respond to the Log4j vulnerability 한국어 번역입니다.
Source: AWS 보안 서비스를 사용한 Log4j 취약점으로부터 위험 노출 제한, 감지 및 대응 방법
