[Log4j 보안이슈] AWS 보안 서비스를 사용한 Log4j 취약성 보호, 탐지 및 대응 방법

해당 포스팅은 log4j 취약점이 이슈화 됨에 따라 AWS에서 제공된 5단계 예방 조치 계획을 번역한 것으로 원문은

'링크'에서 확인할 수 있다.

---

Overview

이 게시물에서는 최근에 공개된 log4j 취약성에 대응하고 있는 고객을 돕기 위한 지침을 제공할 것이다. 여기에는 취약성의 위험을 제한하기 위해 수행할 수 있는 작업, 문제에 취약한지 여부를 식별하는 방법, 그리고 적절한 패치로 인프라를 업데이트하기 위해 수행할 수 있는 작업이 포함된다.

Log4j 취약성(CVE-2021-44228, CVE-2021-45046)은 유비쿼터스 로깅 플랫폼 Apache Log4j의 중요 취약성(CVSS 3.1 기본점수 10.0)이다. 이 취약성을 통해 공격자는 취약한 플랫폼에서 원격 코드를 실행할 수 있다. 버전 2.0-베타-9와 2.15.0 사이의 Log4j 버전 2가 영향을 받는다.

이 취약성은 Java 프로그램에서 일반적으로 이 취약성의 경우 디렉터리를 통해 데이터를 찾는 데 사용되는 JNDI(Java Naming and Directory Interface)를 사용한다.

아래 그림 1은 Log4j JNDI 공격 흐름을 강조한다.

 

그림 1 Log4j 공격 진행. 출처: GovCERT.ch, 스위스 정부의 컴퓨터 긴급대응팀(GovCERT)

즉시 응답하려면 이 블로그에 따라 Log4j 2.0+를 사용하여 실행 중인 JVM을 핫패치하도록 설계된 도구를 사용하십시오. 

 

Protect

고객은 여러 AWS 서비스를 사용하여 Log4j 취약성에 대한 위험/노출을 제한할 수 있다. 고객은 계층화된 제어 접근방식을 구축하거나 아래에서 식별된 제어장치를 선택하여 노출을 제한할 수 있다.

 

AWS WAF

고객은 AWS WAF에 대한 AWS 관리 규칙에 따라 AWS Web Application Firewall을 사용하여 Amazon CloudFront 배포, Amazon API Gateway REST API, Application Load Balance 또는 AWS AppSync GraphQL API 리소스를 보호할 수 있다.

• AWSManagedRulesKnownBadInputsRuleSet > Log4j 취약성의 존재에 대한 요청을 검사하는 데 도움이 되는 Log4JRCE 규칙. 예시 패턴에는 ${jndi:snd://example.com/}이(가) 있다.
• AWSManagedRulesAnonymousIpList > 익명성 클라이언트 정보를 익명화하는 것으로 알려진 소스의 IP 주소를 검사하는 데 도움이 되는 IPList 규칙.
• AWSManagedRulesCommonRuleSet >사이즈 제한_요청 본문 크기가 최대 8KB(8,192바이트)인지 확인하는 BODE 규칙.

AWS WAF Classic을 사용하는 고객의 경우 AWS WAF로 마이그레이션 하거나 사용자 정의 regex(정규식) 일치 조건을 생성해야 한다.

계정이 여러 개인 고객은 이 지침에따라 AWS Firewall Manager를 AWS 조직 전체에 중앙 집중식으로 AWS WAF 규칙을배포할 수 있다.

 

Amazon Route 53 Resolver DNS Firewall

고객은 AWS Managed Domain Lists에 이어 Route 53 Resolver DNS Firewall을 사용하여 아웃바운드 공개 DNS 확인으로 리소스를 사전 예방적으로 보호할 수 있다. Log4j 취약성과 함께 사용되는 호스팅 악성 프로그램으로 식별된 도메인과 함께 지원되는 모든 AWS 영역에서 업데이트된 AWS의 도메인을 차단하도록 구성된 규칙과 Route 53 Resolver DNS 방화벽을 연결할 것을 권장한다. AWS는 이 목록을 통해 경로 53 확인자 DNS 방화벽에 대한 도메인 업데이트를 계속 제공할 것이다.

또한 고객에게 쿼리 로깅을 사용하도록 권장한다. 쿼리 로깅은 Log4j 취약성 또는 알려진 다른 악의적인 대상으로 인해 차단된 아웃바운드 쿼리가 있는지 로그를 검사하여 고객이 VPC 내에서 잠재적으로 영향을 받는 리소스를 식별하고 감사할 수 있도록 한다.

 

AWS Network Firewall

고객은 AWS Network Firewall에서 Suricata 호환 IDS/IPS 규칙을 사용하여 네트워크 기반 탐지 및 보호를 구현할 수 있다. Log4j를 다루는 오픈 소스 Suricata 규칙은 corelight , NCC Group , ET Labs 및 CrowdStrike 에서 이용할 수 있다. 이러한 규칙은 Log4j 취약성에 대한 사후 공격뿐만 아니라 검색도 식별하는 데 도움이 될 수 있다. 현재 많은 양의 악성 검색이 발생하고 있기 때문에, 고객들은 VPC에서 신뢰할 수 없는 인터넷 목적지에 이르는 아웃바운드 LDAP 트래픽과 같은 잠재적인 공격 후 활동에 우선 시간을 집중할 것을 권장한다.

또한 LDAP와 같은 프로토콜의 인스턴스를 모니터링하거나 53, 80, 123 및 443과 같은 비표준 LDAP 포트를 사용하지 못하도록 하는 아웃바운드 포트/프로토콜 시행 규칙의 구현도 고려할 것을 권장한다. 포트 1389 아웃바운드 사용을 모니터링하거나 방지하는 것은 인터넷 스캐너로 인해 아웃바운드 호출을 명령하고 제어하는 시스템을 식별하는 데 특히 유용할 수 있다. 우리는 또한 합법적인 사업체가 없는 시스템들은 기본적으로 그러한 능력이 주어지지 않도록 인터넷으로 네트워크 호출을 개시할 것을 권고한다. 아웃바운드 네트워크 트래픽 필터링 및 모니터링은 Log4j뿐만 아니라 다른 종류의 취약성에도 큰 도움이 된다.

 

Use IMDSv2

log4j 취약성 연구자들은 초기 JDNI 취약성으로 호스트가 손상되면 공격자가 호스트로부터 자격 증명을 수집하여 LDAP, HTTP 또는 DNS 검색과 같은 메커니즘을 통해 해당 자격 증명을 내보내려고 시도한다는 점에 주목했다. 고객 은 장기 액세스 키 대신 IAM 역할을 사용하고 자격 증명과 같은 민감한 정보를 환경 변수에 저장하지 않는 것것 사용하는 것을 추천한다. 또한 고객은 AWS Secrets Manager를 활용하여 호스트 환경 변수에 장기 데이터베이스 자격 증명을 저장하는 대신 데이터베이스 자격 증명을 자동으로 저장하고 회전시킬 수 있다. 환경에서 Secrets Manager를 구현하는 방법은 여기와 여기를 참조하십시오.

EC2 Roles가 사용 중일 때 AWS의 이러한 공격에 대비하고 모든 IMDS 데이터를 비공개로 유지하기 위해 고객은 인스턴스 MetaData Service 버전 2(IMDSv2)의 사용을 고려해야 한다. IMDSv2는 기본적으로 사용 가능하므로 IMDSv1(기본적으로 사용 가능)을 사용하지 않도록 설정하여 사용하도록 요구할 수 있다. IMDSv2에서 요청은 호출 프로세스가 먼저 HTTP PUT와 세션 토큰을 얻어야 하는 초기 상호작용에 의해 보호되며, 후속 요청은 HTTP 헤더에 토큰을 포함해야 한다. 이로 인해 공격자는 IMDS에서 자격 증명 또는 기타 데이터를 수집하기가 훨씬 더 어려워진다. IMDSv2 사용에 대한 자세한 내용은 이 블로그 및 문서를 참조하십시오. 모든 최신 AWS SDK 및 도구는 잠재적으로 역 호환 가능한 변경사항과 마찬가지로 IMDSv2를 지원하지만, 이러한 변경사항을 광범위하게 배치하기 전에 대표 시스템에서 테스트하십시오.

 

Detect

이 게시물에서는 이 취약성을 이용할 수 있는 능력을 잠재적으로 제한하는 방법을 다뤘다. 다음으로, 우리는 AWS 서비스가 당신의 환경에 이 취약성이 존재하는지 여부를 감지하는 데 도움을 줄 수 있는 것으로 우리의 초점을 바꿀 것이다.

그림 2. Inspector 콘솔에서 Log4j 찾기

 

Amazon Inspector

그림 2와 같이, Amazon Inspector 팀은 Amazon EC2 인스턴스와 Amazon Elastic Container Registry Images(Amazon ECR)에 이 취약성의 존재를 확인하기 위한 커버리지(범위)를 만들었다. 새로운 Amazon Inspector와 함께 스캔은 자동화되고 계속된다. 지속적인 검색은 새로운 소프트웨어 패키지, 새로운 인스턴스, 그리고 새로운 공통 취약성 및 노출(CVE)과 같은 이벤트들에 의해 추진된다.

예를 들어, 한번 오 수사관 팀은 Log4j 취약성(CVE-2021-44228 &, CVE-2021-45046)에 대한 지원이라고 덧붙였다, 경감 즉시 지원되는 모든 AWS시스템 관리자 어디 Log4j OS패키지 관리자들을 통해 어디서 패키지 Maven-compatible 아마존 논문에 있는 설치 하여 인스턴스 관리 이 취약점을 찾기 시작했다 onta영상에 깊이 새겨 넣다 이 취약성이 있는 경우, 수동 조치 없이 결과가 나타나기 시작할 것이다. Inspector Classic을 사용하는 경우 모든 Amazon EC2 인스턴스에 대해 평가를 실행하고 있는지 확인하십시오. 이 설명서에 따라 모든 Amazon EC2 인스턴스에 대한 평가 대상을 생성하십시오. 다음은 Amazon ECR 개인 등록지의 컨테이너 검색 업데이트에 대한 추가 세부사항이다.

 

GuardDuty

Amazon GuardDuty 팀은 Inspector를 통해 이러한 취약성의 존재를 발견하는 것 외에도 Log4j 취약성 이용과 관련된 타협 지표 추가에 착수했으며, 앞으로도 그럴 것이다. GuardDuty는 알려진 불량 IP 주소나 DNS 항목에 도달하려는 시도를 모니터 할 것이며, 이상 징후 기반 행동 소견을 통해 폭발 후 활동도 찾을 수 있다. 예를 들어, Amazon EC2 인스턴스가 비정상적인 포트에서 통신을 시작하는 경우 GuardDuty는 이 활동을 감지하고 Behavior:EC2/NetworkPortUnusual 결과를 생성합니다.

그러나 이 활동은 NetworkPortUnusual 소견에만 국한되지는 않는다. GuardDuty는 손상된 AWS 리소스에 대한 대응에서 볼 수 있는 공격 후 활동과 관련된 여러 가지 다른 발견을 가지고 있다. GuardDuty 결과 목록은 이 GuardDuty 문서를 참조하십시오.

 

Security Hub

오늘날 많은 고객들은 또한 AWS Security Hub와 Inspector 및 GuardDuty를 사용하여 경고를 집계하고 자동 교정 및 대응을 가능하게 한다. 단기적으로 보안 허브를 사용하여 AWS 챗봇, Amazon Simple Notification Service 또는 검사관이 사용자 환경에서 이 취약성을 발견할 때 가시성을 위해 티켓팅 시스템을 통해 경고를 설정할 것을 권장한다. 장기적으로 보안 허브를 사용하여 보안 경고에 대한 자동 업데이트 적용 및 대응을 활성화하십시오. 다음은 Security Hub를 사용하여 자동 교정 및 대응을 설정하는 방법에 대한 아이디어다.

 

VPC flow logs

고객은 VPC 흐름 로그에 대해 Athena 또는 CloudWatch Logs Insights 쿼리를 사용하여 log4j 공격 후 아웃바운드 네트워크 작업과 관련된 VPC 리소스를 식별할 수 있다. VPC 흐름 로그 버전 5는 "흐름 방향" 필드를 포함하므로 특히 유용하다. 목적지 포트 1389를 사용하는 아웃바운드 네트워크 통화는 합법적인 애플리케이션에서 덜 흔하기 때문에 고객들은 먼저 목적지 포트 1389를 사용하는 아웃바운드 네트워크 통화에 특별히 주의를 기울일 것을 권장한다. 고객들은 또한 신뢰할 수 없는 인터넷 목적지 IP 주소에 대한 목적지 포트 389를 사용하는 아웃바운드 네트워크 호출을 조사해야 한다. VirusTotal, GreyNoise, NOC.org, ipinfo.io과 같은 자유 계층 IP 평판 서비스는 로그 활동에서 발견된 공용 IP 주소와 관련된 유용한 통찰력을 제공할 수 있다.

 

참고: 쿼리 중인 캡처된 VPC 흐름 로그에 Microsoft Active Directory 환경이 있는 경우 포트 389 사용으로 인해 가양성이 표시될 수 있음

Respond

처음 두 섹션에서는 잠재적인 공격 시도를 방지하는 데 도움이 되는 방법과 취약성과 잠재적인 공격 시도의 존재를 탐지하는 방법에 대해 논의하였다. 이 섹션에서는 이 취약성을 완화하기 위해 취할 수 있는 조치에 대해 중점적으로 설명하겠다. 개요에서 언급한 바와 같이, 이 블로그를 따라 Log4j 2.0+를 사용하여 실행 중인 JVM을 핫 패치하도록 설계된 도구를 사용하는 것이 권장된다.

 

그림 3 중요한 패치를 즉시 승인하는 시스템 매니저 패치 기준선

 

AWS Patch Manager

AWS Systems Manager Patch Manager를 사용하는 경우 패치 기준선에 즉시 설치하도록 중요한 패치를 설정한 경우 EC2 인스턴스가 이미 패치를 가지고 있는 경우 이 시점에서는 아직 끝나지 않았다는 점을 유념하는 것이 중요하다. 그런 다음 응용 프로그램 코드에서 라이브러리를 사용할 때마다 클래스 경로를 업데이트하여 최신 버전을 사용하십시오. 고객은 AWS Patch Manager를 사용하여 하이브리드 환경에서 관리 노드를 패치할 수 있다. 자세한 구현 정보는 여기를 참조하십시오.

 

Container mitigation

개요에 명시된 핫 패치를 EKS 클러스터 작업자 노드에 설치하기 위해 AWS는 Log4j2 라이브러리에서 JNDI 조회를 비활성화하는 JVM 레벨 핫패치를 수행하는 RPM을 개발했다. 아파치 Log4j2 노드 에이전트는 AWS의 'Kubernetes '팀이 구축한 오픈소스 프로젝트다. 이 노드 에이전트를 설치하는 방법에 대한 자세한 내용은 이 Github 페이지를 참조하십시오.

일단 식별되면 패치가 적용된 Log4j 버전을 사용하도록 ECR 컨테이너 이미지를 업데이트해야 한다. 다운스트림에서는 취약한 ECR 컨테이너 이미지로 제작된 모든 컨테이너가 가능한 한 빨리 새 이미지를 사용하도록 업데이트되었는지 확인해야 한다. 이는 이러한 이미지를 배포하는 데 사용하는 서비스에 따라 달라질 수 있다. 예를 들어 Amazon ECS(Amazon Elastic Container Service)를 사용하는 경우 서비스를 업데이트하여 새 배포를 강제 적용하고 새 Log4j 버전을 사용하여 이미지를 아래로 끌어내리십시오. 컨테이너 배포에 사용하는 방법을 지원하는 문서를 확인하십시오.

Windows 컨테이너에서 Java 기반 애플리케이션을 실행하는 고객은 여기에서 Microsoft의 지침을따르는 것이 좋다.

고객에게 새로운 애플리케이션 자격 증명을 복수하고 패치 적용 후 즉시 기존 자격 증명을 취소하십시오.

 

Mitigation strategies if you can’t upgrade

기본적으로 JDNI에 대한 액세스를 비활성화하는 패치가 적용된 버전으로 업그레이드할 수 없는 경우 또는 환경에 대한 패치 전략을 계속 결정하는 경우 Log4j 구성을 변경하여 이 취약성을 완화할 수 있다. 릴리즈 >=2.10에서 이러한 완화를 구현하려면 zip -q -d log4j-*.jar org/apache/log4j/core/lookup/JndiLookup.class에서 JndiLookup 클래스를 제거해야 한다.

특정 버전에 대한 완화 단계에 대한 보다 포괄적인 목록은 Apache 웹 사이트를 참조하십시오.

 

Conclusion

이 블로그 포스트에서는 고객이 Log4j 취약성으로부터 위험을 보호, 탐지 및 대응할 수 있도록 계층화된 접근 방식을 채택할 수 있도록 지원하는 주요 AWS 보안 서비스에 대해 간략히 설명하였다.